Одна конверсия может попасть в аналитику дважды: сначала из браузера, затем с сервера или после повторной доставки запроса. Без дедупликации отчёт завышает результат, алгоритм получает неправильный сигнал, а команда принимает решение по несуществующим событиям.
Откуда появляются дубли
Типичный случай — параллельная отправка одного действия браузерным пикселем и серверной интеграцией. Повтор также возникает при обновлении страницы успеха, повторной попытке postback после тайм-аута или обработке одного webhook несколькими сервисами.
Не каждое похожее событие является дублем. Два разных действия одного пользователя должны сохраняться отдельно, если они имеют разные бизнес-идентификаторы и действительно произошли дважды.
Выберите устойчивый идентификатор
Для каждого бизнес-события создайте event ID в момент, когда действие впервые зафиксировано. Тот же ID должен передаваться по всем каналам доставки. Нельзя генерировать новый идентификатор отдельно в браузере и на сервере — система не поймёт, что это две копии.
Идентификатор не должен содержать email, телефон или другие персональные данные. Используйте случайное или внутреннее техническое значение, которое стабильно связано только с конкретным событием.
Правило обработки повтора
Получатель хранит event ID в течение заранее установленного окна. Если повтор приходит с тем же типом события и идентификатором, он отмечается как повторная доставка, но не увеличивает счётчик конверсий.
Окно должно учитывать реальную задержку систем. Слишком короткое пропустит поздний серверный дубль, а чрезмерно длинное усложнит хранение. Решение принимают по наблюдаемому времени доставки, а не по универсальному числу.
Какой источник считать основным
Заранее определите, какие поля берутся из первой версии события, а какие может дополнить серверная. Например, первоначальная метка кампании сохраняется, а подтверждённый статус и сумма обновляются из более надёжного источника.
Не заменяйте заполненное значение без журнала изменений. Иначе исчезнет возможность понять, почему итоговый отчёт отличается от первичной отправки.
Повторная доставка без повторной конверсии
Сетевой тайм-аут не означает, что получатель не обработал запрос. Отправитель должен повторить доставку с тем же event ID. Новый ID при каждой попытке превращает безопасный retry в несколько конверсий.
Получатель возвращает понятный статус: событие принято, уже обработано или отклонено. Эти ответы сохраняются в логе вместе со временем и номером попытки.
Как найти существующие дубли
Сгруппируйте события по типу, event ID и близкому времени. Затем проверьте совпадения по сумме, статусу, click ID и техническому источнику. Полное совпадение нескольких полей — сигнал для проверки, но не основание автоматически удалять данные.
Для старой истории сначала оцените масштаб и период проблемы. Массовое исправление без резервной копии может удалить реальные повторные действия.
Контрольный тест перед запуском
- отправьте одно тестовое событие из браузера и сервера с одинаковым ID;
- повторите серверный запрос после искусственного тайм-аута;
- убедитесь, что в итоговом отчёте осталась одна конверсия;
- проверьте, что повтор отмечен в техническом логе;
- отправьте второе реальное событие с новым ID и убедитесь, что оно посчитано отдельно.
Как подготовлен материал и где его границы
Редакция 1win Partners построила материал как практическую схему контроля событий. Конкретные имена полей, сроки хранения и ответы API зависят от используемого трекера и интеграции; их нужно сверять с документацией соответствующей системы.
При работе с 1win partners ориентируйтесь на официальные статусы партнёрской программы и согласованный способ передачи данных. Дедупликация делает измерение точнее, но не заменяет проверку качества источника и подтверждение конверсий.