Meta Pixel стоїть, а подій немає: порядок перевірки

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

Коротко:

• Базовий код пікселя має стояти в head до будь-якого виклику fbq, інакше подія йде в нікуди без помилки в консолі.
• Швидка перевірка живої події - Test Events в Events Manager, там вона з'являється за секунди.
• Порожній Test Events при статусі 200 на запит до facebook.com/tr означає, що проблема не в браузері, а в обробці на боці акаунта.
• Блокувальники реклами та режим приватності Safari ріжуть частину запитів, тому кількість подій у кабінеті завжди менша за реальні дії.
• Розбіжність між Test Events і звітом найчастіше дає вікно атрибуції, а не помилка в коді.

Що саме ламається, коли піксель стоїть, а подій немає

Подія не доходить, коли ланцюжок «сторінка → fbq → запит до facebook.com/tr → обробка в кабінеті» розривається на будь-якому з чотирьох етапів. Сторінкові перегляди при цьому можуть фіксуватися, бо вони спрацьовують від базового коду, а не від вашого виклику події.

Через це «піксель стоїть» і «події немає» - дві різні діагнози. Базовий код завантажився і надіслав PageView. Ваш код події або не виконався, або виконався до того, як fbq став доступним, або виконався в контексті, де піксель не ініціалізовано. Кожен варіант має свою ознаку, і плутати їх означає витрачати години на пошук не там.

Перше, що варто зробити - відкрити консоль браузера на сторінці, де має спрацювати подія, і подивитися, чи є помилка про fbq is not defined або про невідомий метод. Якщо помилки немає, а події немає, дивимося мережеві запити.

Порядок перевірки від коду до кабінету

Перевірку ведуть зверху вниз, від сторінки до звіту, і зупиняються на першому етапі, де ланцюжок рветься. Немає сенсу дивитися звіти, поки подія не з'являється в Test Events: у звіті ви побачите лише наслідок.

Ось послідовність, яка закриває більшість випадків:

1. Відкрийте HTML сторінки та переконайтеся, що базовий код пікселя стоїть у head, а код події - після нього.
2. У консолі перевірте, що window.fbq існує до моменту виклику події.
3. У вкладці Network відфільтруйте запити до facebook.com/tr і подивіться, чи йде запит при виконанні дії.
4. Відкрийте Events Manager, розділ Test Events, введіть URL і повторіть дію на сайті.
5. Якщо в Test Events подія є, а в звіті немає - переходьте до перевірки атрибуції та фільтрів.

Кожен крок відсіює свій клас причин. Далі розберемо їх по черзі.

Крок 1. Порядок скриптів на сторінці

Подія йде в нікуди, якщо код її виклику стоїть у розмітці раніше за базовий код fbq. Браузер виконує скрипти зверху вниз, і виклик fbq('track',...) до ініціалізації просто не має чого виконувати.

Найчастіші місця, де це трапляється:

• Код події вставлено в head вище за базовий сніпет пікселя.
• Подію додано через тег менеджер, який завантажується паралельно з базовим кодом.
• Код події підключено окремим скриптом без очікування завантаження основного.

Правильний порядок: базовий сніпет у head, виклик події - після нього. Якщо подія прив'язана до кліку або відправки форми, виклик має бути в обробнику цієї дії, а не в загальному скрипті ініціалізації.

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

Крок 2. Контекст, у якому спрацьовує подія

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

iframe - окремий документ зі своїм JavaScript. Якщо форма або віджет вбудовані через iframe, виклик fbq усередині нього не бачить піксель батьківської сторінки. Подію треба викликати з батьківської сторінки, а не зсередини вбудованого блоку.

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

Ознака цієї проблеми - подія з'являється в Test Events при тестуванні основної сторінки і не з'являється при тестуванні вбудованої форми чи піддомену. Це найшвидший спосіб відрізнити проблему контексту від проблеми коду.

Крок 3. Перевірка в Test Events

Test Events в Events Manager показує події з вашого браузера в реальному часі. Це перше місце, куди дивляться, коли є сумнів, чи доходить подія взагалі.

Порядок дій простий:

1. Відкрийте Events Manager і перейдіть у розділ Test Events.
2. Введіть URL сторінки, яку тестуєте, у полі тестування.
3. Виконайте дію на сайті в тому ж браузері.
4. Подивіться, чи з'явилася подія у списку.

Подія має з'явитися протягом приблизно 20 секунд. Якщо вона там є, код працює, і подальші питання стосуються звітів, а не передачі.

Якщо Test Events порожній, а запит до facebook.com/tr у вкладці Network повертає статус 200, проблема не в браузері. Запит пішов і був прийнятий. Причину тоді шукають у серверній обробці або у фільтрах акаунта.

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

Крок 4. Блокувальники та режим приватності

Частина подій не доходить, бо браузер користувача блокує запити до facebook.com/tr. Це не помилка налаштування, а особливість середовища, з якою доводиться рахуватися.

Рекламні блокувальники ріжуть запити до домену Meta. Режим приватності Safari з обмеженнями на сторонні cookie робить те саме для частини аудиторії. У результаті в кабінеті завжди менше подій, ніж було реальних дій.

Як перевірити, чи це ваш випадок:

• Відкрийте сторінку в режимі інкогніто без розширень і повторіть дію.
• Порівняйте, чи з'явилася подія в Test Events у цьому режимі.
• Якщо в інкогніто подія є, а у звичайному браузері з розширеннями немає - справа в блокувальнику.

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

Крок 5. Подія в Test Events є, а в звітах немає

Розбіжність між Test Events і звітом майже завжди пояснюється налаштуваннями атрибуції, а не втратою події. Дані дійшли, але не потрапили у вибране вікно звіту.

Що перевірити:

• Вікно атрибуції у стовпцях звіту. За замовчуванням стоїть 7 днів після кліку і 1 день після перегляду.
• Прив'язку події до правильного пікселя. Якщо в акаунті кілька пікселів, подія могла піти не в той.
• Фільтри за якістю даних. Подія з низькою якістю може не відображатися так, як ви очікуєте.

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

Якщо в Test Events подія є, а у звіті її немає за 48 годин, варто писати в підтримку Meta через Business Help Center.

Таблиця: де шукати причину за ознакою

Скільки чекати появи події

У Test Events подія відображається майже одразу, зазвичай до 30 секунд. Це інструмент реального часу, і затримка тут означає проблему з передачею, а не з обробкою.

У звітах Events Manager і Ads Manager дані з'являються протягом 15-60 хвилин, іноді до кількох годин. Точний час залежить від навантаження на систему і від того, як часто оновлюється конкретний звіт.

Якщо минуло більше 24 годин і події немає ні в Test Events, ні у звіті, шукайте помилку в коді, а не в затримці. Затримка не буває такою довгою.

Як звірити дані пікселя з обліком

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

Щоб зрозуміти реальну картину, потрібна наскрізна розмітка: джерело має дожити до картки клієнта. Про те, як це зробити, є окремий розбір UTM-розмітки, яка доживає до картки в CRM. Для побудови самих посилань використовують конструктор UTM-міток.

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

Наступний крок

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

FAQ

Чому піксель фіксує відвідування, але не передає події?

Найчастіше подія спрацьовує до завантаження базового коду fbq, тому запит іде в нікуди. Перевірте порядок скриптів: код пікселя має стояти в head до коду самої події. Друга причина - подія викликається всередині iframe або на піддомені, де піксель не встановлено.

Як перевірити, чи подія Meta Pixel дійшла до Facebook?

Відкрийте Events Manager, розділ Test Events, і введіть URL сторінки у полі тестування. Виконайте дію на сайті: подія має з'явитися в списку протягом 20 секунд. Якщо в Test Events порожньо, а в браузері запит до facebook.com/tr повертає статус 200, проблема на боці серверної обробки або фільтрів акаунта.

Скільки часу потрібно, щоб подія з'явилася в статистиці пікселя?

У Test Events подія відображається майже одразу, зазвичай до 30 секунд. У звітах Events Manager і Ads Manager дані з'являються протягом 15-60 хвилин, іноді до кількох годин. Якщо минуло більше 24 годин і події немає, шукайте помилку в коді, а не в затримці.

Що робити, якщо браузер блокує запити Meta Pixel?

Рекламні блокувальники та режим приватності Safari ріжуть запити до facebook.com/tr, тому частина подій не доходить. Перевірте сторінку в режимі інкогніто без розширень і порівняйте кількість подій. Для стабільного трекінгу налаштуйте Conversions API: він передає події з сервера і не залежить від блокувальників.

Де шукати помилку, якщо подія є в Test Events, але не в звітах?

Перевірте налаштування атрибуції та вікна конверсій у стовпцях звіту: за замовчуванням стоїть 7 днів після кліку і 1 день після перегляду. Також переконайтеся, що подія прив'язана до правильного пікселя і не потрапила під фільтр за якістю даних. Якщо в Test Events є, а в звіті немає за 48 годин, напишіть у підтримку Meta через Business Help Center.