Дедупликация по transaction_id: где ломается учёт и как не потерять лиды

Дедупликация по transaction_id: где ломается учёт и как не потерять лиды

Если transaction_id в связке не уникален, не стабилен или меняется по пути от формы до CRM, дедупликация превращается в лотерею. В итоге один лид может уйти в учёт дважды, а повторный отправится как новый.

Базовые правила:
— transaction_id создаётся один раз и живёт до финального постбэка;
— не смешивайте его с click_id, если у них разная роль;
— одинаковый ID должен означать один и тот же источник события, а не «похожий заказ»;
— повторная отправка с тем же ID должна обновлять запись, а не создавать новую.

Типовые ошибки:
— генерация ID на каждом шаге воронки;
— обрезание строки при передаче через разные системы;
— смена регистра, пробелов или разделителей;
— попытка дедуплицировать по телефону, почте или имени вместо технического ключа;
— хранение ID только в браузере без серверной фиксации.

Проверка простая: один и тот же transaction_id должен пройти путь от клика до подтверждения без изменений, а при повторном постбэке система должна распознать его как дубль и не удваивать конверсию.

Сделайте ID стабильным, а логику обработки дублей — явной: тогда учёт не поплывёт, а разбор споров с партнёрами станет заметно проще.