Дедупликация событий Facebook Pixel и CAPI: проверка идентификаторов

Для подготовки интеграции пригодятся материалы про event_id и дедупликацию, прогрев пикселя и Facebook CAPI через Keitaro. Когда браузерный Pixel и серверный CAPI сообщают об одной покупке, нужно связать эти сообщения с одним действием. Дедупликация событий Facebook Pixel помогает избежать повторного учёта, но её работу нужно проверять на фактически отправленных данных.

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

Откуда берутся повторные события

Pixel передаёт событие из браузера, CAPI передаёт его с сервера. Если оба сообщения описывают одно действие, интеграция должна сохранить согласованные данные для их сопоставления. Отдельно проверьте, не запускается ли браузерный тег дважды и не создаёт ли сервер новый ID при повторном запросе.

Meta документирует эту границу прямо: дедупликация сопоставляет событие Pixel с событием Conversions API. Два подряд серверных события с одинаковыми данными не отбрасываются, как и два подряд браузерных. Повторные серверные запросы контролируйте по собственному журналу доставки. Общий event ID не обеспечивает их дедупликацию.

Повторы могут исказить количество событий и связанные показатели, но не означают, что все конверсии обязательно удвоились, а CPA уменьшился ровно вдвое. Сравните отчёт с реальными действиями и журналами отправки.

Какие данные сопоставлять

Имя события и общий идентификатор

В вызове Pixel идентификатор передаётся как eventID, а в CAPI используется event_id. Имя действия в браузерном вызове должно соответствовать серверному event_name.

В строке event таблица обозначает имя браузерного события: в примере вызова fbq это Purchase. Не добавляйте в запрос произвольное поле только потому, что оно так подписано в таблице.

Отрицательный пример: браузер отправил eventID: "a1b2c3d4", а сервер event_id: "e5f6a7b8". Пары ключей не совпали, поэтому Meta не отбрасывает ни одну копию; обе остаются в источнике данных. При появлении дубля сначала проверьте, что одно и то же значение действительно проходит через оба канала.

Данные пользователя не заменяют ID события

fbp описывает браузерную куки, а external_id относится к идентификатору пользователя в вашей системе. Они не обозначают конкретную покупку. Если ваша интеграция использует дополнительные способы сопоставления, сверяйте их условия с актуальной документацией Meta; не рассчитывайте на них как на гарантированную замену общему ID события.

Время доставки

Передавайте данные без лишней задержки и сохраняйте фактическое время действия. Meta документирует: события дедуплицируются, только если получены в течение 48 часов после того, как Meta приняла первое событие с данным event_id. Запасной способ по fbp/external_id работает для пары «сначала браузер, потом сервер»; серверное событие не отбрасывается, если браузерного не было последние 48 часов. Допустимый возраст серверного события и окно рекламной атрибуции решают другие задачи; не подменяйте одну проверку другой.

Как передать общий идентификатор

Шаг 1. Создайте ID действия

Пример генерирует UUID и помещает его в data layer. Само добавление в data layer ещё не отправляет значение в CAPI: настройте его передачу серверной части.

const eventId = crypto.randomUUID();
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ event: 'purchase', eventId: eventId });

Генерируйте ID при регистрации нового действия, а не заново для каждой попытки доставки того же события. Если у заказа уже есть подходящий стабильный идентификатор, согласуйте его использование в обоих каналах.

Шаг 2. Передайте ID в Pixel

Значение eventId из предыдущего шага передаётся в параметре eventID:

fbq('track', 'Purchase', {
  value: 49.99,
  currency: 'USD'
}, { eventID: eventId });

Шаг 3. Используйте то же значение в CAPI

Ниже показан фрагмент данных события, а не полный готовый запрос. Добавьте обязательные для вашей схемы поля, включая action_source, и подставьте фактические время, сумму, валюту и доступные данные пользователя.

{
  "event_name": "Purchase",
  "event_time": 1721650000,
  "event_id": "<тот же uuid из шага 1>",
  "user_data": { "fbp": "<original_fbp_cookie_value>" },
  "custom_data": { "value": 49.99, "currency": "USD" }
}

В fbp передавайте сохранённое значение куки без хеширования. Пример event_time нельзя копировать в рабочее событие: он иллюстрирует формат поля.

Шаг 4. Сверьте имя события

Используйте одно и то же написание в обоих каналах, включая регистр. Для пары Purchase и purchase нельзя предполагать совпадение; проверьте конфигурацию тегов и фактические запросы.

Шаг 5. Проверьте задержки и повторы

Сопоставьте время действия с моментами отправки и получения. Если очередь задерживается или повторяет запросы, выясните причину и проверьте, сохраняется ли исходный ID при повторе.

Какие ошибки искать

Таблица перечисляет типичные направления диагностики. Процент и поведение резервного способа в ней нельзя считать универсальным результатом для любой интеграции: проверяйте конкретные события и действующие требования платформы.

Как проверить результат в Events Manager

1. Откройте Events Manager и выберите нужный источник данных.
2. Изучите доступную информацию о дедупликации в Overview.
3. Выполните контролируемое действие и найдите связанные события в Test Events, если этот способ проверки доступен в вашей интеграции.
4. Сравните браузерный eventID с серверным event_id и проверьте имя действия.
5. Сверьте полученные данные с журналами: оба канала должны описывать одну конверсию, а не два разных заказа.

Низкая доля дедупликации может потребовать расследования, но не доказывает, что ID отсутствует. Сначала выясните, какие события действительно отправляются по обоим каналам.

Что включить в проверку интеграции

• Сверьте значение eventID в Pixel и event_id в CAPI.
• Проверьте, что ID не меняется из-за лишних пробелов, преобразования типа или повторной генерации.
• Сравните event_name с именем браузерного события event.
• Проверьте время доставки и ответы API отдельно от рекламной атрибуции.
• Убедитесь, что fbp и external_id поступают из корректных источников данных.
• Просмотрите доступные сообщения Diagnostics и свяжите их с конкретными запросами.

Как трактовать события без подтверждённой дедупликации

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

Что проверить перед регулярной отправкой

• Определите, где создаётся event_id и как он попадает в оба канала.
• Закрепите одно написание event_name для каждого действия.
• Сохраняйте исходный идентификатор при повторной отправке той же конверсии.
• Следите за задержками и доступной диагностикой Events Manager.
• Повторяйте проверку после изменений тегов или серверного обработчика.

Источники