Meta Pixel і Conversions API: щоб події доходили повністю

Прозорі етапи з погодженням на кожному кроці

Загальний строк:3–12 днів

1. 1

   Безкоштовна перевірка передачі подій

   2–3 робочих дні, до кошторису

   Дивимось, скільки пікселів на сторінці, які події доходять, чи є серверний канал і чи не рахується купівля двічі. На виході — карта подій і рекомендований спосіб передачі для вашої платформи.

2. 2

   Браузерні події: ревізія й повний ланцюжок

   1–3 робочих дні

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

3. 3

   Серверний канал і дедуплікація

   1–5 робочих днів

   Піднімаємо передачу через Conversions API обраним способом, переносимо _fbp і _fbc з браузера, зводимо обидва канали за спільним ідентифікатором. Спершу вмикаємо одну подію — купівлю.

4. 4

   Тестові події, звірка й документ

   1–4 робочих дні

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

5. 5

   Тиждень спостереження за якістю зіставлення

   7 календарних днів, робочих днів не забирає

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

Повний перелік робіт і того, що ви отримуєте на виході

• Ревізія піксела: один ідентифікатор на сайт замість двох-трьох, що лишились від різних підрядників — інакше події діляться між кабінетами
• Повний ланцюжок стандартних подій — перегляд товару, кошик, початок оформлення, купівля: видно, на якому кроці губиться покупець
• Параметри товару, сума й валюта в події купівлі — без них у звіті лишається кількість, але не віддача з реклами
• Серверна передача через Conversions API з вашого боку: подія доходить і тоді, коли браузер її не відправив
• Спільний ідентифікатор події для обох каналів і перенесення _fbp та _fbc на сервер — купівля рахується один раз і має за чим зіставитись
• Узгодження подій із банером згоди: відмова людини зупиняє передачу, а не лише запис cookie
• Тестові події й прогін реального замовлення від кошика до підтвердження — перевіряємо, що приходить, а не що мало б приходити
• Звірка купівель у кабінеті з замовленнями у вашій обліковій системі за той самий період
• Перевірка оцінки якості зіставлення в диспетчері подій через тиждень роботи, коли набереться статистика
• Схема подій одним документом: назви, параметри, звідки береться кожне значення — щоб її підтримували без нас
• Гарантія 30 календарних днів на виконані роботи

Ситуації, у яких ця послуга дає результат

Безкоштовна перевірка передачі подій у Meta

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

Що міряємо

• Чи стоїть піксел і чи він одинДва піксели на сторінці — не рідкість після зміни підрядника. У виміряній нами вибірці траплялись сайти, де Meta Pixel був єдиним лічильником узагалі, без будь-якої іншої аналітики.
• Повнота ланцюжка подійПерегляд товару, додавання в кошик, початок оформлення, купівля. Найчастіше бракує саме середини, і воронка стає непридатною до аналізу.
• Передача вартості замовленняБез суми й валюти в події купівлі неможливо порахувати віддачу з реклами — лишається тільки кількість.
• Наявність серверного каналуЧи передаються події з вашого боку, а не лише з браузера. Браузерні події частково не доходять через блокувальники й налаштування приватності.
• ДедуплікаціяЯкщо ту саму купівлю шле і браузер, і сервер без спільного ідентифікатора події, вона порахується двічі. Це найтихіший з усіх дефектів: цифри стають кращими.
• Стан згоди на збір данихЯкщо на сайті є банер згоди, події мають підкорятись вибору користувача. Перевіряємо, чи так це зараз.

Чому дві однакові на вигляд задачі рахуються по-різному — і що саме ми міряємо на аудиті

• Спосіб передачі серверних подійГотова інтеграція платформи — кілька днів. Серверний контейнер тегів — це ще й окремий хостинг, який комусь треба оплачувати й оновлювати. Власний обробник на бекенді дає найточніші дані й забирає найбільше часу. Тут і сидить різниця між нижньою та верхньою межею.
• Скільки подій зводимоОдна купівля — це один ідентифікатор і одна звірка. Повний ланцюжок від перегляду до оформлення — чотири події, у кожної свої параметри товару, і кожну треба перевірити окремо в обох каналах.
• Що вже стоїть на сайтіЧистий сайт налаштувати швидше, ніж розібрати спадок. Два піксели, події з теми й з диспетчера тегів одночасно, модуль, який шле своє — розбір чужого налаштування йде окремим рядком кошторису.
• Є банер згоди чи немаєЯкщо немає — події просто йдуть. Якщо є — обидва канали треба підкорити вибору людини й перевірити два стани, згоду й відмову. Тестування на цьому подвоюється.
• Чия черга на бекендіПравки в диспетчері тегів робимо самі. Обробник на боці сайту вносить той, у кого є доступ до коду: якщо це ваш розробник, строк починає залежати від його черги, а не від нашої.

Без цього не почнемо — краще підготувати заздалегідь

1. 1Доступ до бізнес-акаунта й диспетчера подій — без нього не видно, що приходить зараз.
2. 2Доступ до сайту або до диспетчера тегів для впровадження браузерної частини.
3. 3Рішення, які параметри ви готові передавати, і правова підстава для цього — це ваше рішення, не наше.
4. 4Доступ до серверної частини, якщо обираємо пряму передачу з бекенда.
5. 5Опис того, що у вашій системі вважається успішним замовленням: оплата, підтвердження менеджером чи відвантаження.
6. 6Наявний банер згоди й правила його роботи, якщо він уже стоїть.

Якщо чогось із цього немає — скажіть, підкажемо, як зібрати або зробимо самі окремою задачею.

Що зазвичай беруть разом із цією задачею

• події на відправку форми
• запустити рекламу у Facebook для інтернет-магазину
• налаштувати динамічні оголошення Facebook
• банер згоди на cookie налаштування
• навести лад у контейнері тегів