Диагностика пикселя сигналы: читаем сторону данных

Под любой диагностикой пикселя сигналы-разбор лежит неудобное правило: когда пиксель выглядит мёртвым или сообщение упоминает ограничения, гадание - самый дорогой следующий шаг. Собственные инструменты площадки способны доказать большинство важного - доходят ли события, несут ли они пригодные данные, какой текст политики показывает интерфейс, - а логи трекера доказывают остальную цепочку. Этот гайд проводит диагностику по стороне данных в порядке: что показывает каждый инструмент и чего не показывает, как отделить отказ доставки от проблемы качества, какие документированные фиксы восстанавливают отправку и что записывать, чтобы починка была проверяемой.

Граница скоупа важна и идёт первой: это гайд «прочитай данные и почини свою отправку». Рекламные ограничения на уровне аккаунта - политические решения площадки; диагностическая задача здесь - понять, что делает ваш собственный поток событий, а не обойти что-либо.

Что способны доказать инструменты диагностики

Три площадки-поверхности делают большую часть диагностической работы:

1. Test Events (Events Manager, ваш датасет, Test Events): приложите показанный код как test_event_code и наблюдайте прибытие событий в момент отправки - самое быстрое доказательство работоспособности трубы от начала до конца.
2. Обзор Events Manager: события становятся видны примерно через 20 минут после отправки (get started with the Conversions API); график объёма, счётчики событий и диагностические сообщения интерфейса - авторитетная картина того, что датасет получил.
3. Event Match Quality и индикаторы данных: по-событийные сигналы качества оценивают, насколько полно события идентифицируют пользователей (About Event Match Quality), - разница между «события приходят, но оптимизируются плохо» и «события приходят отлично».

Чего эти инструменты не делают: не объясняют политическую логику сообщения об ограничении, не предсказывают решение и не заменяют собственные политические тексты интерфейса. Когда площадка показывает сообщение политики, диагностический шаг - прочитать его как написано и сверить свои данные с ним, а не теоретизировать поверх. Эта граница держит остальную диагностику фактической.

Шаг один: отделить отказ доставки от проблемы качества

Развилка решает всё дальнейшее:

Для строк отказа доставки следующим инструментом становятся собственные логи трекера: лог постбеков Keitaro показывает, что пришло и почему строка провалилась - отсутствующий статус, неизвестный статус, не сматченный subid, неверный postback key, - каждое документированное и исправимое состояние (postback troubleshooting). Отказ слоя доставки виден в его собственных записях доставки; молчащий слой - регрессия конфигурации, а не платформенная тайна. Полный трекерный проход - в чеклисте поиска неисправностей постбеков, а транспортная цепочка, которую он кормит, собрана в гайде от постбека до CAPI.

Документированные фиксы, восстанавливающие отправку

Регулярные отказы доставки и их документированные исправления:

1. Проблемы токена. Истёкший или отозванный access token валит каждый вызов. Перегенерируйте токен в инструментах площадки, обновите слой доставки, подтвердите одним тестовым событием.
2. Нарушения таймстампов. event_time глубже семи дней в прошлое валит весь запрос - одно протухшее событие убивает батч (using the API). Чините источник протухших данных, а не только батч.
3. Отсутствующие обязательные поля. Website-событиям нужны action_source, event_source_url и client_user_agent (parameters). События без них отклоняются или слабеют - восстановите поля в источнике.
4. Дыры в идентификаторах. События без fbp/fbc и других ключей матчинга приходят тощими; Meta документирует сборку fbc из fbclid, снятого в момент клика (fbp and fbc parameters).
5. Дрейф идентичности. Та же конверсия, пересланная под меняющимися event ID, считается многократно; стабильные ID, выводимые из строки конверсии, чинят это - территория дедупликации со статусными правилами из гайда про холд.

Ни один из этих фиксов не касается платформенной политики - они восстанавливают то, что шлёт ваша сторона, что и есть самый быстрый путь к работающей доставке и полностью под вашим контролем.

Что фиксировать во время диагностики

Диагностика без записей непроверяема: по памяти невозможно отличить «проверили после фикса» от «кажется, заработало». Во время работы фиксируйте:

1. Таймлайн симптома: когда события остановились, когда возобновились, что менялось между.
2. Выводы инструментов: счётчики и скриншоты Test Events, диагностические сообщения Events Manager как написано, строки лога постбеков.
3. Один тестовый аргумент на гипотезу: меняйте одно, шлите одно тестовое событие, наблюдайте - та же одно-переменная дисциплина, что в любой отладке.
4. Финальное доказательство: реальная конверсия через всю цепочку плюс площадка, показывающая её в документированном окне видимости. Воспроизводимость - вот зачем это: следующий человек или вы сами через месяц) повторит путь по фактам, а не по впечатлениям.

Такая запись превращает «мы починили пиксель» в проверяемое утверждение - для команды, для разговора с сетью или для треда поддержки площадки.

Диагностика пикселя сигналы: частые вопросы

Источники