Задержки Meta CAPI: что проверить, прежде чем считать интеграцию сломанной

Задержки Meta CAPI редко означают единую проблему на стороне платформы. Успешный ответ Conversions API доказывает только одно: Meta приняла запрос. Он не доказывает, что событие уже видно в каждом отчёте Events Manager, получило атрибуцию кампании или попало в выбранную колонку Ads Manager. Это разные проверки. Если их смешать, можно сломать рабочую интеграцию в попытке починить задержку отчёта.

Какому экрану Meta верить для конкретного вопроса?

Эти инструменты смотрят на разные этапы конверсии. Test Events нужен для запроса с test event code. Events Manager показывает активность источника и диагностику. Ads Manager показывает конверсии после того, как Meta применила настройки атрибуции к рекламным взаимодействиям.

Не используйте итог Ads Manager как тест транспорта. Реальная покупка может быть в бэкенде, но взаимодействие с рекламой не попало в выбранную настройку атрибуции. Это вопрос отчёта, а не автоматический сбой CAPI.

Когда задержка нормальна, а когда пора разбираться?

Не ставьте в статью или в регламент выдуманное SLA вроде «Events Manager всегда обновляется за 20 минут». Интерфейсы и обработка Meta меняются. Рабочая граница проще: пока обычная аналитика догоняет, проверяйте доставку через Test Events; timestamp при этом должен оставаться внутри допустимого окна Meta.

Для web-событий Meta документирует предел: event_time может отставать от момента отправки максимум на семь дней. Если он старше, Meta отклоняет весь запрос, как указано в руководстве API. Ошибка payload, который действительно слишком стар, разобрана отдельно в Facebook CAPI error 2804003. Это правило приёма, а не целевое время доставки. Здоровый поток отправляет событие в момент бизнес-действия и хранит логи, по которым видно, где возникло ожидание.

Как отделить задержку доставки от задержки отчёта?

Начните с одной известной покупки или лида. Дайте ей стабильный внутренний номер заказа или лида. Затем пройдите путь через трекер, очередь воркера и HTTP-лог. Скриншот агрегированного графика здесь почти бесполезен.

1. Подтвердите конверсию в трекере, CRM или платёжной системе.
2. Подтвердите, что воркер создал ровно один исходящий CAPI-запрос.
3. Сохраните время запроса, HTTP-ответ и ответ Meta без access token и персональных данных.
4. Найдите то же контролируемое событие в Test Events и Events Manager.
5. Только после этого сравнивайте атрибуцию в Ads Manager с настройкой кампании и диапазоном дат.

Если трекер создал событие в 10:00, а воркер отправил его в 14:00, проблема в свежести очереди. Если воркер отправил его сразу и Meta приняла запрос, переходите к payload, дедупликации и отчётности.

Какие поля делают задержавшееся CAPI-событие бесполезным?

Параметры CAPI отделяют момент бизнес-события от момента отправки сервером. Передавайте event_time как реальное время конверсии в Unix-секундах, а не как время, когда воркер добрался до задачи. Выберите корректный action_source; для событий сайта сохраняйте исходный URL, если он есть.

Для матчинга передавайте только разрешённые идентификаторы, которые вы действительно собрали и можете законно использовать. Meta описывает хешированные email и телефон, external_id, fbp, fbc, IP клиента и user agent. Не выдумывайте click ID и не хешируйте уже хешированное значение. Такие «улучшения» превращают диагностику в туман.

Могут ли Pixel и CAPI описывать одну конверсию дважды?

Meta документирует дедупликацию Pixel и server events. Сгенерируйте идентификатор один раз на границе конверсии и передайте то же значение в оба канала. Если браузер создаёт один случайный ID, а сервер другой, пара не попадёт под рекомендованный Meta метод по event ID и имени. У Meta есть отдельный fallback по одинаковым event_name и fbp и/или external_id.

Временную ошибку воркера обрабатывайте записью идемпотентности на своей стороне. Не считайте повтор серверного события с тем же event_id безопасным: Meta не дедуплицирует два последовательных server-only события. Повторяйте отправку только когда ваш статус доставки доказывает, что исходный запрос не был принят. Держите одинаковыми имя и ID браузерного и серверного события, затем проверяйте их пару в Test Events.

Что сначала проверить в Test Events?

Meta даёт Test Events именно для проверки server events. Test event code используйте только для контролируемого теста и убирайте из продового payload, как предписывает Meta. События с таким кодом не отбрасываются: они тоже попадают в Events Manager и могут использоваться для таргетинга и измерения рекламы, поэтому это не чистая проверка продового потока.

Для проверки Pixel плюс CAPI используйте одинаковое бизнес-действие и один event_id в обеих копиях. Зафиксируйте результат, затем уберите test code и повторите путь через обычный продовый сценарий. В статье Facebook CAPI через Keitaro разобраны типовые поломки на серверной передаче.

Что проверить в Events Manager после приёма?

Откройте нужный источник и сузьте просмотр до точного event_name. Изучите Diagnostics до того, как менять теги или права токена. При симптомах авторизации сначала проверьте Pixel ID и access token. Затем сопоставьте контролируемое событие с исходящим логом: ID источника, event_name, event_time, URL и идентичность события должны совпасть.

Event Match Quality и coverage используйте как сигналы диагностики. Накручивать красивый балл выдуманными идентификаторами бессмысленно. Цель - событие, которое честно описывает конверсию и несёт валидные данные, разрешённые политиками Meta.

Почему Ads Manager может отличаться, если Events Manager уже здоров?

Проверьте выбранное в кампании conversion location и событие оптимизации. Затем посмотрите настройку атрибуции и точный диапазон дат. Конверсия может быть записана в дату бизнес-действия, а отчёт сгруппирован или отфильтрован иначе.

Держите рядом число заказов из бэкенда и отчёт платформы. Они отвечают на разные вопросы. Бэкенд фиксирует завершённые заказы; Meta показывает то, что зачла по своим правилам атрибуции. Требование постоянного равенства между ними - ошибка категории.

Чего не стоит делать, пока вы разбираете задержку?

Не делайте эти дорогие «фиксы»:

• Не переигрывайте все недавние конверсии с новыми event ID. Так легко создать дубли.
• Не заменяйте настоящий event_time текущим временем сервера. Вы потеряете возможность измерить свежесть.
• Не добавляйте выдуманные fbc и user identifiers. Правдоподобный payload всё равно содержит плохие данные.
• Не оптимизируйте UI-балл, если неверно определено само бизнес-событие.
• Не режьте бюджеты по отчёту того же дня, не сверив одинаковую настройку атрибуции и стабильное окно отчёта.

Когда ручной аудит пройден, Most помогает сделать передачу конверсий из трекера в пиксель повторяемой, сохранить mapping и не гонять случайные ретраи. Для проверки одного payload начните с бесплатного Pixel Activator.

Какие доказательства приложить к тикету Meta?

Соберите пакет:

1. ID источника данных и затронутое имя события.
2. Обезличенный event ID или внутренний номер, но никогда не access token.
3. Четыре времени: конверсия, очередь, исходящий запрос и ответ Meta.
4. HTTP-статус и релевантные поля ответа Meta.
5. Результат Test Events и Diagnostics Events Manager для того же кейса.
6. Кампания, ad set, настройка атрибуции, диапазон отчёта и часовой пояс, если вопрос про Ads Manager.

Такой пакет отделяет сбой обработки на стороне Meta от задержанной задачи, отклонённого timestamp или несовпадения атрибуции. Поддержке не придётся просить повторную отправку клиентских данных.

Как выглядит короткая повторяемая диагностика?

1. Выберите один канонический Lead или Purchase и найдите его в бэкенде.
2. Пройдите времена очереди и CAPI-запроса.
3. Проверьте свежую контролируемую копию через Test Events.
4. Проверьте event_name, event_time, action_source, user data и event_id.
5. Откройте диагностику Events Manager и дедупликацию.
6. Прочитайте соответствующий отчёт Ads Manager с его атрибуцией, диапазоном и часовым поясом.
7. Эскалируйте только тот случай, где сохранённые доказательства указывают на проблему вне вашего конвейера.

Если CAPI проходит эту последовательность один раз, автоматизируйте её. Most держит передачу конверсий и mapping в одном месте; Pixel Activator остаётся быстрым ручным пробником.

Источники