event_id и дедупликация

Если одна и та же конверсия дойдёт до пикселя дважды, Meta засчитает её дважды - и оптимизация, отчёты и аудитории поплывут. Решение - стабильный event_id: отпечаток, по которому Meta узнаёт и отбрасывает дубли.

Как устроен event_id

Идентичность каждого события Most строит так:

event_id = {sub_id}_{имя_события}_{время конверсии в UTC}

где ключ времени - YYYYMMDDTHHMMSSffffffZ, то есть таймстемп конверсии в UTC с точностью до микросекунды. Поскольку превью, воркер отправки и дедуп на стороне Meta используют ровно этот ключ, у одной конверсии - одна идентичность везде.

UTC - везде Конверсии грузятся из Keitaro в UTC и сравниваются в UTC. Смешение часовых поясов - классический способ случайно создать две идентичности для одного события. Most его избегает, оставаясь в UTC от начала до конца.

Три слоя защиты от дублей

1. В базе - конверсия уникальна по (click_id, status, datetime), поэтому одна конверсия Keitaro хранится один раз.
2. Перед отправкой - воркер проверяет (pixel_id, conversion_id, event_name) и пропускает уже записанные пары, так что повторный запуск не задваивает локально.
3. На стороне Meta - уже успешно отправленные события (sent или partial) исключаются по их event_id перед следующим батчем, а Meta дедуплицирует по event_id как финальная страховка.

Упавшие события - намеренное исключение: записи об ошибке не блокируют повтор, поэтому конверсия, что один раз ошиблась, уйдёт снова в следующий запуск.

Почему время клампится, а id - нет

Meta отклоняет события старше 7 дней - та же ошибка 2804003, что видна в Events Manager, - поэтому Most клампит исходящее event_time в безопасное окно. А event_id всегда строится из исходного времени конверсии - кламп времени доставки не меняет идентичность события, и дедупликация остаётся корректной. Подробнее об окне - в статье прогрев пикселя.

Что это значит для вас

Можно перезапускать загрузки, делать инкрементальный синк и прогревать пиксель многократно без страха: одна конверсия уйдёт один раз. В Most это автоматически.

Sources