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

Связанные материалы: event_id и дедупликация, прогрев пикселя, Facebook CAPI через Keitaro. Связка Meta Pixel + Conversions API (CAPI) дает устойчивость данных: если браузерное событие потерялось, серверное подстрахует. Но без корректной дедупликации каждая конверсия учитывается дважды. ROAS выглядит раздутым, оптимизация получает шумные сигналы, а бюджетные решения опираются на фантомные цифры.

Разберем, как именно Meta склеивает дубли, что ломает процесс и как проверить настройку в Events Manager.

Почему возникает задвоение

Pixel отправляет событие из браузера. CAPI отправляет то же событие с сервера. Если у пары нет общего идентификатора, Meta регистрирует две независимые конверсии. Последствия:

• Количество конверсий примерно вдвое выше реального.
• Стоимость за результат кажется вдвое ниже.
• Алгоритм оптимизации обучается на дублях.

Meta рассчитывает на избыточную конфигурацию и предоставляет слой дедупликации. Он активируется только при совпадении заданных параметров с обеих сторон.

Механика дедупликации Meta

Платформа сравнивает входящие события и объединяет дубли двумя способами.

Основной способ: event_id + event_name

Браузерный Pixel передает eventID и event. Серверный CAPI передает event_id и event_name. Когда оба значения совпадают между источниками, Meta оставляет одно событие и отбрасывает дубль.

Совпасть должны оба поля. Расхождение в любом из них блокирует склейку.

Резервный способ: event_name + идентификатор пользователя

Если передать уникальный ID события невозможно, Meta сопоставляет event_name в паре с fbp (браузерный идентификатор) или external_id (хеш пользователя). У этого подхода есть ограничения:

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

Поэтому основной способ надежнее.

Окно в 48 часов

Склейка возможна только в пределах 48 часов. Серверное событие, пришедшее позже этого окна, учитывается как отдельное. Отправляйте серверные события практически в реальном времени.

Пошаговое исправление

Шаг 1. Сгенерируйте уникальный ID на клиенте

Создайте UUID в момент совершения действия и сохраните в data layer.

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

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

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

Шаг 3. Передайте тот же ID в CAPI

В серверном payload укажите идентичное значение:

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

Шаг 4. Соблюдайте регистр event_name

Сопоставление чувствительно к регистру. Purchase и purchase - разные события для механизма дедупликации. Выберите один вариант написания и закрепите его в конфигурации тегов.

Шаг 5. Отправляйте серверные события быстро

Целевая задержка - до 1 минуты. Пакетная отправка или очередь с большим лагом рискует выйти за 48-часовое окно и ухудшить качество атрибуции.

Частые ошибки

Проверка в Events Manager

1. Откройте Events Manager, выберите источник данных.
2. На вкладке Overview найдите карточку Deduplication.
3. Оцените процент дедупликации. Здоровая связка Pixel + CAPI показывает 80-95% для массовых событий вроде PageView и Purchase.
4. При показателе ниже 50% откройте Test Events и проверьте последние события на предмет отсутствующих или несовпадающих event_id.
5. В режиме Payload убедитесь, что браузерное и серверное события несут одинаковые event_id и event_name.

Нулевой процент дедупликации почти всегда означает, что event_id просто не передается.

Чек-лист диагностики

• Убедитесь, что event_id присутствует и в параметре eventID пикселя, и в поле event_id серверного запроса.
• Проверьте, что значения идентичны как строки (без лишних пробелов и приведения типов).
• Сравните регистр event_name / event с обеих сторон.
• Убедитесь, что серверное событие приходит в пределах 48 часов от браузерного.
• При использовании резервного способа проверьте консистентность fbp или external_id.
• Загляните на вкладку Diagnostics в Events Manager: предупреждения о дублях видны там.

Что происходит с несклеенными событиями

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

Главные выводы

• Передавайте общий event_id (UUID) с клиента в оба канала: Pixel и CAPI.
• Держите регистр event_name одинаковым во всех источниках.
• Отправляйте серверные события в реальном времени, чтобы уложиться в 48-часовое окно.
• Еженедельно проверяйте процент дедупликации в Events Manager.
• Показатель ниже 80% - сигнал о проблеме в конфигурации.

Отслеживайте воронки и конверсионные события в едином интерфейсе с MOST. Если перед автоматизацией нужен бесплатный ручной чек, используйте Pixel Activator, чтобы активировать пиксель и проверить поток событий.

Источники