Meta Ads

Спершу перевіряємо рекламний кабінет, сторінку, піксель, каталог і події. Налаштовуємо або виправляємо передачу ключових дій: перегляд товару, додавання в кошик, початок оформлення, покупка або заявка. Коли можливо, підключаємо серверну передачу конверсій, щоб зменшити втрати даних.

Далі створюємо структуру кампаній, запускаємо оголошення, контролюємо бюджет, аудиторії, частоту показів і вартість результату. Вимикаємо звʼязки, які витрачають гроші без цільової дії, і перерозподіляємо бюджет на ті, що підтверджуються заявками чи замовленнями.

Раз на тиждень даємо зрозумілий звіт: скільки витрачено, скільки отримано цільових дій, яка їхня вартість, що змінили і що будемо перевіряти далі.

Структура залежить від задачі і кількості даних. Зазвичай окремо розділяємо залучення нової аудиторії, повернення відвідувачів сайту і динамічну рекламу товарів з каталогу. Це дозволяє бачити, звідки прийшов результат, і не змішувати людей, які вперше побачили бренд, з тими, хто вже вибирав товар.

На старті перевіряємо події і вибираємо дію, на якій справді має навчатися Meta: покупка, оформлена заявка або інша підтверджена дія. Потім запускаємо обмежену кількість зрозумілих тестів, щоб бюджет не розпорошувався між десятками груп.

Зміни вносимо за накопиченими даними. Часті безсистемні правки перезапускають навчання і заважають зрозуміти, що спрацювало.

Клієнт або його контент-команда передає готові фотографії, відео, банери, інформацію про товар і чинні пропозиції. Ми добираємо матеріали під конкретну аудиторію та етап воронки, поєднуємо їх з рекламним текстом, заголовком і закликом до дії і запускаємо кілька перевірюваних варіантів.

Оцінюємо не особистий смак, а дані: чи привертає оголошення увагу, чи переходять люди на сайт і чи виконують цільову дію. Слабкі варіанти зупиняємо, сильні лишаємо і масштабуємо в межах доступного бюджету.

Коли матеріал вигорає або для тесту не вистачає потрібного ракурсу, формату чи пропозиції, даємо конкретну рекомендацію для наступного рекламного матеріалу. Саму зйомку робить клієнт, а решту виробництва можемо взяти на себе: про це в розділі «Ведення соцмереж» вище.

Вартість ведення — від $400 на місяць за один погоджений напрям. Фінальна ціна залежить від кількості ринків, рекламних кабінетів, товарів, мов, воронок і обсягу робіт з аналітикою.

Рекламний бюджет не входить у вартість ведення. Клієнт привʼязує свою картку й оплачує покази напряму Meta. Ми не приймаємо рекламний бюджет на свій рахунок і не додаємо до нього прихованої комісії.

До запуску погоджуємо місячний бюджет і допустимий темп витрат. Збільшення бюджету обговорюємо окремо, особливо поки кампанія проходить навчання.

Кабінет, піксель і сторінка лишаються вашими — навіть якщо розійдемось.

Зйомку робите ви: фото й відео знімає клієнт або його контент-команда. Ми працюємо з готовими вихідними — монтаж, субтитри, озвучка за погодженням і підготовка форматів під заливку в Meta.

Якщо потрібна регулярна підготовка матеріалів, є окремий пакет креативів — $350 на місяць. У пакет входить:

• сценарний хук, пропозиція і рекламний текст;
• три коротких ролики на місяць;
• дві статики або каруселі на місяць;
• монтаж, субтитри й озвучка за погодженням;
• підготовка форматів до запуску в Meta;
• один погоджений раунд правок.

Понад пакет рахуємо поштучно: ролик — $100, каруселя — $60, статика — $40.

Ведення разом із пакетом креативів — від $750 на місяць. Рекламний бюджет у цю суму, як і раніше, не входить.

Знадобляться доступи до сторінки Facebook, рекламного кабінету, Business Manager, пікселя і сайту. Якщо інфраструктури ще немає, створюємо її на боці клієнта і передаємо власнику всі права. Для оплати реклами потрібна привʼязана картка.

Також потрібні актуальні ціни, наявність товару, географія продажів, маржинальність або допустима вартість замовлення, умови доставки і готові рекламні матеріали. Важливо швидко повідомляти про зміну залишків і пропозицій: реклама товару, якого немає, витрачає бюджет і псує статистику.

З боку клієнта потрібна людина, яка підтверджує пропозиції й оперативно повідомляє про якість заявок і фактичні продажі.

Лічильник Meta може показувати події, але не звʼязувати їх з реальними замовленнями. Причинами бувають неправильно встановлений піксель, дублі подій, відсутність події Purchase після оплати, блокувальники, обмеження браузерів, відмова від cookies, покупка з іншого пристрою або замовлення телефоном чи в месенджері.

Окремо перевіряємо, чи не передається покупка до успішного оформлення. Інакше Meta вчиться на людях, які лише дійшли до форми, але замовлення не завершили. Зіставляємо події кабінету із замовленнями сайту або CRM і знаходимо, які дії губляться чи рахуються двічі.

Абсолютного збігу між Meta й обліковою системою зазвичай не буває через різні правила атрибуції. Наша задача — зробити розбіжність зрозумілою і достатньо малою для ухвалення рішень.

Перші дні потрібні для перевірки передачі даних і первинного навчання. Перші два тижні показують напрям, але невелика вибірка ще може сильно мінятися від кількох замовлень. Обґрунтованішу оцінку зазвичай робимо після трьох-чотирьох тижнів або раніше, якщо кампанія вже зібрала достатню кількість цільових дій.

Дивимось не тільки на кліки й повідомлення. Враховуємо реальні замовлення, їхню вартість, виручку, скасування і якість заявок. Якщо даних мало, прямо кажемо, що висновок поки попередній.

Зупиняти очевидно неробочу звʼязку можна раніше. Чекати місяць заради формального строку, коли реклама витрачає бюджет без ознак попиту, не будемо.

Ми не називаємо гарантований ROAS, кількість продажів або точну ціну заявки до запуску. На ці показники впливають продукт, ціна, сезон, конкуренція, сайт, наявність товару, швидкість обробки звернень і обсяг даних у кабінеті.

Ми можемо назвати орієнтири по ринку, визначити контрольні показники і заздалегідь домовитися, за яких цифр кампанію міняємо або зупиняємо. Рішення підтверджуємо даними, а не обіцянкою «налаштувати один раз і отримувати результат».

Meta може відхиляти оголошення, обмежувати категорії і міняти роботу алгоритмів. Ми дотримуємось правил, виправляємо доступні причини й подаємо матеріали на повторну перевірку, але фінальне рішення ухвалює платформа.