Как проверить отсутствие дублирования событий в аналитике?

Что проверяют

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

Как отвечать

Сначала договоритесь, что считать дублем. У события должен быть ключ: event_id (UUID, который клиент генерирует один раз), плюс пользователь, сессия и время. Без ключа два честных клика от одного задвоенного события не отличить.

Дальше проверки по слоям:

• клиент: сниффер (Charles, Proxyman, вкладка Network в DevTools) или отладочный режим SDK. Делаете действие один раз и считаете запросы. Частые причины дублей: обработчик подписан дважды, компонент рендерится повторно, событие шлётся и из кода, и из тег-менеджера;
• ретраи и офлайн: включаете авиарежим, выполняете действие, возвращаете сеть. Событие из очереди должно уйти один раз, а не при каждой попытке;
• хранилище: SELECT event_id, count(*) FROM events GROUP BY event_id HAVING count(*) > 1, а для событий без ID группировка по пользователю, имени события и окну в пару секунд;
• автотест: в UI-тесте перехватываете запросы к эндпоинту аналитики (например, через page.route в Playwright) и проверяете, что после действия ушло ровно одно событие с нужными параметрами.

Сильный ход: сказать, что при доставке «хотя бы один раз» дубли неизбежны, поэтому приёмная сторона дедуплицирует по event_id. Это тоже проверяется: отправьте один payload дважды и убедитесь, что в отчёт попала одна запись.

Где спотыкаются

Смотрят только итоговый отчёт в интерфейсе аналитики. Там данные агрегированы и приходят с задержкой, дубль теряется в общей цифре.

Забывают про повторную отправку после обрыва сети и перезапуска приложения, хотя дубли чаще всего рождаются именно там.

Считают любое повторение багом. Два быстрых клика по «В корзину» могут быть реальным поведением, это решается с аналитиком, а не заведением дефекта.