Под любой диагностикой пикселя сигналы-разбор лежит неудобное правило: когда пиксель выглядит мёртвым или сообщение упоминает ограничения, гадание - самый дорогой следующий шаг. Собственные инструменты площадки способны доказать большинство важного - доходят ли события, несут ли они пригодные данные, какой текст политики показывает интерфейс, - а логи трекера доказывают остальную цепочку. Этот гайд проводит диагностику по стороне данных в порядке: что показывает каждый инструмент и чего не показывает, как отделить отказ доставки от проблемы качества, какие документированные фиксы восстанавливают отправку и что записывать, чтобы починка была проверяемой.
Граница скоупа важна и идёт первой: это гайд «прочитай данные и почини свою отправку». Рекламные ограничения на уровне аккаунта - политические решения площадки; диагностическая задача здесь - понять, что делает ваш собственный поток событий, а не обойти что-либо.
Что способны доказать инструменты диагностики
Три площадки-поверхности делают большую часть диагностической работы:
- Test Events (Events Manager, ваш датасет, Test Events): приложите показанный код как
test_event_codeи наблюдайте прибытие событий в момент отправки - самое быстрое доказательство работоспособности трубы от начала до конца. - Обзор Events Manager: события становятся видны примерно через 20 минут после отправки (get started with the Conversions API); график объёма, счётчики событий и диагностические сообщения интерфейса - авторитетная картина того, что датасет получил.
- Event Match Quality и индикаторы данных: по-событийные сигналы качества оценивают, насколько полно события идентифицируют пользователей (About Event Match Quality), - разница между «события приходят, но оптимизируются плохо» и «события приходят отлично»; практический разбор - в оценке качества событий Facebook.
Чего эти инструменты не делают: не объясняют политическую логику сообщения об ограничении, не предсказывают решение и не заменяют собственные политические тексты интерфейса. Когда площадка показывает сообщение политики, диагностический шаг - прочитать его как написано и сверить свои данные с ним, а не теоретизировать поверх. Эта граница держит остальную диагностику фактической.
Шаг один: отделить отказ доставки от проблемы качества
Развилка решает всё дальнейшее:
| Симптом | Показывает Test Events | Вероятный класс | Первая проверка |
|---|---|---|---|
| Ничего не приходит | Пусто | Отказ доставки | Шлёт ли кто-то вообще - очередь трекера, автоматизация, логи сервера |
| Часть событий доходит | Частично | Частичный отказ | Какой источник остановился; какая ветка или оффер умер |
| События приходят, качество низкое | Заполнено, слабые сигналы | Качество данных | оценка качества событий, ключи матчинга, идентификаторы, поля value |
| Счётчики выглядят удвоенными | Заполнено, завышено | Проблема идентичности | Стабильность event_id, параллельные пути доставки |
Для строк отказа доставки следующим инструментом становятся собственные логи трекера: лог постбеков Keitaro показывает, что пришло и почему строка провалилась - отсутствующий статус, неизвестный статус, не сматченный subid, неверный postback key, - каждое документированное и исправимое состояние (postback troubleshooting). Отказ слоя доставки виден в его собственных записях доставки; молчащий слой - регрессия конфигурации, а не платформенная тайна. Полный трекерный проход - в чеклисте поиска неисправностей постбеков, а транспортная цепочка, которую он кормит, собрана в гайде от постбека до CAPI.
Документированные фиксы, восстанавливающие отправку
Регулярные отказы доставки и их документированные исправления:
- Проблемы токена. Истёкший или отозванный access token валит каждый вызов. Перегенерируйте токен в инструментах площадки, обновите слой доставки, подтвердите одним тестовым событием.
- Нарушения таймстампов.
event_timeглубже семи дней в прошлое валит весь запрос - одно протухшее событие убивает батч (using the API). Чините источник протухших данных, а не только батч. - Отсутствующие обязательные поля. Website-событиям нужны
action_source,event_source_urlиclient_user_agent(parameters). События без них отклоняются или слабеют - восстановите поля в источнике. - Дыры в идентификаторах. События без
fbp/fbcи других ключей матчинга приходят тощими; Meta документирует сборкуfbcизfbclid, снятого в момент клика (fbp and fbc parameters). - Дрейф идентичности. Та же конверсия, пересланная под меняющимися event ID, считается многократно; стабильные ID, выводимые из строки конверсии, чинят это - территория дедупликации со статусными правилами из гайда про холд.
Ни один из этих фиксов не касается платформенной политики - они восстанавливают то, что шлёт ваша сторона, что и есть самый быстрый путь к работающей доставке и полностью под вашим контролем.
Что фиксировать во время диагностики
Диагностика без записей непроверяема: по памяти невозможно отличить «проверили после фикса» от «кажется, заработало». Во время работы фиксируйте:
- Таймлайн симптома: когда события остановились, когда возобновились, что менялось между.
- Выводы инструментов: счётчики и скриншоты Test Events, диагностические сообщения Events Manager как написано, строки лога постбеков.
- Одно тестовое событие на гипотезу: меняйте одно, шлите ровно его, наблюдайте - та же одно-переменная дисциплина, что в любой отладке.
- Финальное доказательство: реальная конверсия через всю цепочку плюс площадка, показывающая её в документированном окне видимости. Воспроизводимость - вот зачем это: следующий человек или вы сами через месяц повторит путь по фактам, а не по впечатлениям.
Такая запись превращает «мы починили пиксель» в проверяемое утверждение - для команды, для разговора с сетью или для треда поддержки площадки.
Диагностика пикселя сигналы: частые вопросы
Frequently asked questions
Источники
Sources
- Бесплатное доказательство доставки: Pixel Activator стреляет идентифицируемыми тестовыми событиями в момент нужды.
- Работающая доставка навсегда: Most держит токены, таймстампы и поля корректными круглосуточно.