CAPI event отклонён Meta

Введение

Используйте этот гайд, когда сервер точно отправляет событие и Meta отвечает, но в ответе появляются validation errors, тяжелые warnings или тихие дропы, из-за которых событие не попадает в ожидаемый reporting path. Это другой сценарий, чем Facebook CAPI Not Firing, где главный вопрос — уходит ли запрос из вашего стека вообще.

Практическая задача здесь — превратить размытое отклонение в один воспроизводимый evidence pack: raw response Meta, final landing URL, browser-side proof и точные идентификаторы или поля, которые ломают валидацию. Когда эти артефакты лежат рядом, владелец payload чинит конкретный разрыв вместо спора по скриншотам.

Симптомы

Проблемы с отклонением Meta часто маскируются под частичный успех. API-запрос получает ответ, кто-то считает событие принятым, а позже выясняется, что Events Manager, match quality или downstream optimization так и не отражают конверсию.

Начинайте с controlled replay в Facebook CAPI Tester, затем сравните его с browser-side доказательством из Pixel Scanner, а для эскалаций держите под рукой Tracking Audit, если redirects, click IDs и payload ownership разбросаны по разным командам.

• Meta отвечает на API-запрос, но событие не появляется там, где команда ожидает его увидеть в Events Manager или диагностике.
• В ответе есть сообщения о missing user data, invalid event_name, malformed event_time, конфликтах action_source или проблемах deduplication.
• Browser-side pixel доказательство есть, но server event считается слабым, unmatched или invalid.
• Интеграция работала до изменения формы, CRM, consent-логики или routing, а теперь отклоняется только часть событий.

Типовые причины

Большинство отклонений связано с качеством payload, а не с transport. Meta может получить запрос, но не доверять событию, если обязательные поля сломаны, идентификаторы не совпадают с landing-page evidence, consent state расходится, или deduplication data конфликтует с browser events.

Смотрите на инцидент как на chain-of-custody для event data. Final landing URL, browser event, captured click ID, CRM или middleware transform и outgoing server payload должны рассказывать одну и ту же историю о пользователе и конверсии.

• Поля event_name, event_time, action_source, event_source_url или custom_data отсутствуют, устарели или неправильно отформатированы.
• fbclid, fbc, external_id, email hashes или phone hashes отсутствуют, не захешированы, захешированы дважды или положены не в те ключи.
• Browser event и server event используют неправильный event_id, повторяют stale ID или не могут дедуплицироваться, потому что одна из сторон не получила тот же идентификатор.
• Consent-логика, GEO routing или middleware убирают user_data для части трафика, пока другие сегменты ещё отправляются корректно.
• Лендинг или CRM-ветка захватывает click ID, но payload builder отправляет fallback-значение или пустое поле.

Как подтвердить отклонение

Нужны доказательства с обеих сторон стека: что видел браузер и что именно отклонила Meta. Не начинайте с слепого редактирования кода. Сначала докажите final page, browser event, identifiers и server response для одного и того же тестового пути.

Полезная проверка заканчивается одним sample event, у которого задокументированы все слои: final URL, browser-side pixel state, click-ID capture, outbound payload и прямой response body Meta.

1. Сохраните raw response Meta

   Повторите событие в Facebook CAPI Tester и сохраните полный response body, а не только зелёный статус.

2. Подтвердите browser-side reference event

   Используйте Pixel Scanner на той же final landing page, чтобы подтвердить browser-side Meta signal и ожидаемый deduplication context.

3. Проверьте, что идентификаторы переживают путь

   Прогоните live URL через Redirect Checker и проверьте финальную query string в Click ID Extractor, чтобы понять, дошёл ли fbclid и другие идентификаторы до страницы.

4. Сравните payload с evidence

   Сопоставьте event_name, event_time, action_source, event_id, user_data и custom_data с тем, что вы только что зафиксировали на лендинге.

5. Выберите правильную ветку до правок

   Если запрос вообще не выходит из вашего стека, вернитесь к Facebook CAPI Not Firing. Если landing page видит fbclid, но формы, CRM rows или middleware теряют его до сборки payload, переходите в FBCLID Not Stored in CRM.

Как исправить

Чините именно тот validation gap, на который указывает Meta, а затем заново прогоняйте то же controlled event, пока browser evidence, server payload и ответ Meta не начнут совпадать. Не делайте сразу три несвязанных изменения, иначе вы не поймёте, что именно вернуло acceptance.

Если отклонение вскрывает более широкую launch-quality проблему, используйте How to validate click ID capture before launch и How to validate UTM links before launch, чтобы усилить страницу до новой подачи трафика.

Эскалируйте через Tracking Audit, когда владелец сломанного поля неочевиден между media buying, CRM и backend-командами.

1. Нормализуйте обязательные event fields

   Почините формат event_name, event_time, action_source, event_source_url и критичных custom_data-полей, чтобы Meta получала payload в валидной форме.

2. Исправьте захват идентификаторов и hashing

   Убедитесь, что fbclid, fbc, external_id, email, phone и другие identifiers захватываются один раз, преобразуются корректно и хешируются именно там, где ждёт Meta.

3. Синхронизируйте deduplication между browser и server

   Генерируйте event_id последовательно и проверьте, что browser и server events используют одну deduplication-логику без переиспользования stale ID.

4. Уберите пустые fallback и конфликтующие defaults

   Удалите middleware-логику, которая отправляет blank placeholders, test values или старые schema fields, когда реального identifier нет.

5. Перепроверьте exact production path

   Повторите тот же live landing URL, сохраните новый ответ Meta и оставьте принятый payload вместе с final redirect trace для будущего QA.

Инструменты, которые сокращают цикл отклонения

Самый быстрый workflow начинается с одного direct replay и одной browser-side проверки. Эта пара быстро показывает, проблема ли это слабого payload, слабого landing path или слабого capture layer между ними.

Не отправляйте скриншоты payload без доказательств по path. Если final landing page вообще не получила те же identifiers, Meta rejection часто оказывается только последним видимым симптомом.

Держите эти инструменты в одном runbook, чтобы reviewer мог перейти от raw API response к URL evidence без перезапуска инцидента с нуля.

Выводы

Отклонённое Meta-событие почти всегда означает проблему качества данных, а не мистику. Как только вы совмещаете ответ Meta с landing-page evidence и точным payload, путь к ремонту становится конкретным.

После фикса храните один accepted sample payload, один matching browser event и один final landing URL в launch checklist. Тогда будущая CAPI-отладка превращается в быструю сверку, а не в новый инцидент.

Похожие проблемы

• Facebook CAPI не срабатывает
• FBCLID не сохраняется в CRM
• Pixel missing after redirect
• Google Tag not detected on landing page

Материалы базы знаний

• How to check if fbclid reaches the landing page
• Как проверить capture click ID до запуска
• Как сравнить Pixel и CAPI событие
• Как проверять UTM-ссылки перед запуском