Deduplication в CAPI ломается не из-за Facebook, а из-за event_id и тайминга
Когда Pixel и CAPI шлют один и тот же Purchase, платформа должна склеить их по event_name + event_id. Если event_id генерится на клиенте, а на сервере уходит другая строка, дедупликации не будет вообще. Если ID общий, но событие прилетает с задержкой и окно склейки уже прошло, получите дубль в отчёте и искажённый ROAS.
Что проверять первым:
— event_id должен создаваться один раз и жить от браузера до сервера;
— один и тот же event_name на обеих сторонах;
— одинаковые параметры value/currency для диагностики, иначе искать проблему сложнее;
— не пересоздавать ID при ретраях, редиректах и SPA-навигации.
Частая ошибка — отправлять CAPI без Pixel и потом пытаться оценить deduplication rate. Склейка видна только там, где есть пара. Вторая проблема — отправка Purchase из нескольких триггеров: thank-you page, dataLayer event и серверный fallback одновременно.
Если нужна стабильная дедупликация, делайте event_id детерминированным, логируйте его на обеих сторонах и тестируйте на одном сценарии покупки. Иначе вы оптимизируете не рекламу, а статистический шум.
Server Attribution — sGTM, CAPI, Privacy Sandbox
@server_attribution
Deduplication в CAPI ломается не из-за Facebook, а из-за event_id и тайминга
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.