Дубли конверсий трекер: три системы, три цифры

Под расследованием «дубли конверсий трекер» лежит неудобная истина: когда трекер показывает 80 конверсий, баланс сети - 74, а Ads Manager - 92, ни одна из трёх систем не сломана. Каждая считает по собственным документированным правилам, в собственных окнах, с собственной точки зрения на цепочку. Настоящие продублированные конверсии прячутся внутри этого определяющего шума - одна и та же продажа, засчитанная площадкой дважды, или постбек, перерегистрированный после смены статуса, - и найти их можно, только отделив различия подсчёта от реальных двойников. Этот гайд разбирает именно это: что документирует каждая система о дедупликации, как дубли реально возникают в цепочке и как устроена процедура сверки, дающая один из двух ответов.

Полный гайд по арбитражному трекингу вводит картину трёх систем; здесь ей достаётся форензика.

Сначала примите, что три гроссбуха расходятся

Прежде чем охотиться за дублями, посчитайте расхождение, которое каждая система документирует как задуманное поведение:

Дублем является только последняя строка. Всё остальное - сверочный шум, мимикрирующий под дубль, поэтому «продедуплицировать всё» - недостижимая цель: три гроссбуха не сойдутся, потому что считают не одно и то же.

Какой дедуп реально даёт каждая система

У каждого слоя есть документированный механизм, и это не один и тот же механизм:

1. Площадка дедуплицирует по идентичности события. Meta хранит первую принятую копию события с теми же event_id и event_name, пришедшую в 48-часовом окне, и отбрасывает поздние копии - причём внутри одного канала ничего не дедуплицируется (документация дедупликации). Reddit сводит пиксельные и серверные события по conversion ID по своим правилам (event deduplication). Работает это всё только на дисциплине event ID: нет общей идентичности - нет дедупа.
2. Трекер дедуплицирует перезаписью. Постбек-контракт Keitaro: новый постбек с тем же subid и изменёнными параметрами перезаписывает предыдущую конверсию; идентичный повтор не перезапускает исходящую S2S-очередь, которая тоже исключает дубли (postback URL, S2S постбеки). Мультиконверсионные офферы уходят от перезаписи через транзакционный параметр класса tid - «уникальное значение на постбек записывает отдельные конверсии».
3. Сеть дедуплицирует как скажет её спека - часто никак, поэтому дублирующие постбеки по одному subid приходят с разными параметрами и законно перезаписывают друг друга в трекере, оставаясь одной реальной продажей.

Ловушка сидит между слоями: перезапись трекера консолидирует строку конверсии, но если первая версия уже уехала на площадку, площадка хранит первое событие - коррекция опаздывает по замыслу.

Как настоящие дубли возникают в цепочке

Реальные двойники приходят из горстки паттернов:

1. Дрейф идентичности. Та же конверсия, пересланная дважды с разными event_id - как правило, после переимпорта в трекере, перемапленного постбека или ретрая доставки, пересоздавшего ID. Для площадки это два разных события; никакое окно дедупа их не склеит.
2. Параллельные пути доставки. Конверсию отправляет интеграция трекера - и тот же конверт отправляет скрипт или CRM - обе с валидными идентичностями. Платформенный дедуп помогает, только когда идентичность совпадает; два по-разному собранных события об одной продаже считаются оба.
3. Повторы по смене статуса. Сеть переобъявляет конверсию после выхода из холда. Трекер перезаписывает свою строку, но слой доставки, настроенный стрелять по нескольким статусам, может отправить и лид, и purchase как две продажи. С разными именами событий и ID приземлятся оба.
4. Путаница с ребиллами. Регулярные платежи, отправленные как новые конверсии без транзакционной идентичности, - корректно для настоящих ребиллов, катастрофично, когда сеть переотчитывает тот же первый платёж.

Заметьте, чего в списке нет: площадки, считающей правильно идентифицированное событие дважды. Документированные окна делают свою работу - дубли рождаются выше по течению - в идентичности и обвязке, а не в самой логике дедупа.

Процедура сверки

Агрегированные тоталы не могут локализовать дубль - одна конверсия может. Процедура:

1. Выберите подозрительный интервал и образец - одну конверсию, которую трекер считает и которую вы подозреваете в удвоении на площадке.
2. Проведите её цепочку идентичности: запись клика в трекере, постбек-записи сети (логи Keitaro показывают, что приходило и что уходило - логи), и event ID площадки, который она должна нести.
3. Классифицируйте каждый зазор. Постбек пришёл после отправки лид-события - определённое поведение (ваша статусная политика). Два события площадки с разными event ID об одной продаже - настоящий дубль с дрейфом идентичности. Тот же ID внутри окна для пары «пиксель плюс сервер» - не дубль; площадка уже отбросила копию. Два серверных события с одним ID не склеиваются: документированный дедуп - только межканальный.
4. Чините в точке происхождения: один путь доставки на конверсию, стабильные event ID, выводимые из идентичности конверсии, и статусная маршрутизация, не способная выстрелить дважды, - правила обвязки из гайда про цепочку постбеков.
5. Повторяйте образец ежемесячно. Чеклист поиска неисправностей постбеков покрывает механические отказы доставки, которые эта процедура тоже вымывает.

Когда расхождение - определение, а не баг

После сверки большинство расхождений разрешается в документированные корзины: события, которые вы выбрали слать и которые сеть не подтвердила; окна атрибуции, склеивающие клики по-разному; холды, сжимающие баланс постфактум. Вариант пиксель-против-CAPI конкретно для Meta разобран отдельно в дедупликации событий Facebook Pixel и CAPI, а денежный взгляд на то же расхождение - в гайде о расхождении трекера с Ads Manager.

В корзине багов остаются конкретные устранимые проблемы: дрейф идентичности, параллельные пути и дважды стреляющие статусные маршруты - каждый чинится в точке происхождения, а не «зачисткой» площадочной стороны постфактум.

Дубли конверсий: частые вопросы

Источники