Задержки Meta CAPI: как найти причину до изменения интеграции

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

Где проверять доставку, обработку и атрибуцию?

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

Сумма в Ads Manager сама по себе не проверяет доставку. Покупка может быть записана в вашей системе, но не засчитана рекламе по выбранным настройкам атрибуции. Такое расхождение ещё не доказывает сбой CAPI.

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

Не ориентируйтесь на неподтверждённое обещание вроде «Events Manager всегда обновляется за 20 минут». Время обработки и обновления интерфейсов Meta может различаться. Пока отчёты обновляются, проверяйте доставку через Test Events и следите, чтобы время события оставалось в допустимом окне Meta.

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

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

Выберите известную покупку или лид со стабильным внутренним номером. Найдите эту запись в трекере, очереди отправки и журнале HTTP-запросов. Общий график не покажет, что произошло с конкретной конверсией.

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

Обезличенный пример такой записи (значения условные, это не SLA платформы):

Задержки после ответа Meta относятся к обработке и отчёту, а не к доставке.

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

Какие поля проверить у задержавшегося CAPI-события?

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

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

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

Meta описывает дедупликацию браузерной и серверной копий события. Создайте идентификатор при конверсии и передайте его в оба канала. Если браузер и сервер создадут разные ID, метод сопоставления по event ID и имени не сработает. Документация также описывает запасной способ по совпадающим event_name и fbp и/или external_id.

При временной ошибке обработчика опирайтесь на собственный журнал доставки и защиту от повторов. Повторная отправка серверного события с тем же event_id не становится безопасной автоматически: механизм Pixel/CAPI не предназначен для последовательных отправок только с сервера. Повторяйте запрос, когда состояние доставки подтверждает, что исходный запрос не принят. Совпадение имени и ID браузерной и серверной копий проверьте в Test Events.

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

В Test Events проверяют серверные события. Используйте test event code для отдельного теста, затем удаляйте его из рабочих запросов. По результату отдельного теста нельзя судить о том, как рабочие события будут использоваться для таргетинга, измерения рекламы и отчётности.

При проверке 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 и покрытие идентификаторов помогают диагностике. Добавление вымышленных идентификаторов ради балла ухудшает данные. Событие должно точно описывать конверсию и содержать сведения, которые разрешено использовать по правилам Meta.

Почему отчёт Ads Manager отличается при успешной доставке?

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

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

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

Следующие действия могут ухудшить ситуацию:

• Повторная отправка недавних конверсий с новыми event ID создаёт риск дублей.
• Замена настоящего event_time текущим временем сервера мешает измерить задержку.
• Вымышленные fbc и идентификаторы пользователей ухудшают данные, даже если запрос выглядит корректным.
• Работа над баллом в интерфейсе не исправит неверное определение бизнес-события.
• Сокращение бюджета по отчёту за текущий день требует предварительной проверки настроек атрибуции и сопоставимого периода.

После ручной проверки храните правила сопоставления событий и состояние доставки в одном месте. Решение о повторе должно опираться на результат отправки, а не только на цифры в отчёте.

Какие данные приложить к обращению в 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 от задержки задачи, отклонённого времени события или расхождения атрибуции. Они помогут поддержке разобраться в пути события без передачи лишних данных клиентов.

В каком порядке повторять проверку?

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. Обращайтесь в поддержку Meta, когда сохранённые данные указывают на проблему за пределами вашей системы отправки.

При автоматизации сохраните этот порядок проверок и возможность отправить отдельное тестовое событие. Это поможет разбирать расхождения после изменений.

Источники