Дубли событий: почему одна заявка считается несколько раз

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

Аналитический дубль отличается от повторно созданной заявки. Приложение может сохранить одну запись и отправить три события, а может сохранить три записи, каждая из которых будет честно измерена. В первом случае чинят измерение, во втором — бизнес-операцию. Бывают оба дефекта одновременно.

Проверьте показатель прежде, чем код

В терминах Метрики достижение цели, целевой визит и целевой посетитель — разные величины. В рамках одного визита возможно несколько достижений. Несовпадение этих чисел само по себе нормально.

Затем проверьте, не суммируются ли цели разного смысла. Автоматическая отправка формы и программная цель подтверждённого приёма могут описывать близкие участки одного сценария. Наличие обоих сигналов допустимо для диагностики, но их сумма не равна числу заявок.

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

Постройте трассу одной тестовой операции

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

Внутреннему журналу подходят идентификатор операции, тип события, версия приложения и техническое место вызова. Не используйте email и телефон как ключи отладки. Идентификатор операции также не становится автоматически анонимным: храните связь с заявкой внутри защищённого контура и не передавайте её во все сторонние системы без необходимости.

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

Где чаще появляется повторная отправка

• Два владельца события. Вызов есть в коде формы и в менеджере тегов.
• Несколько обработчиков. Повторное открытие модального окна добавляет подписку, но старая не снимается.
• Два технических сигнала одного результата. Успех фиксируется после ответа сервера и повторно при показе страницы благодарности.
• Повторная отрисовка. Событие привязано к созданию компонента, хотя создание компонента не означает новую заявку.
• Повтор доставки. Отложенная очередь или интеграция заново отправляет тот же логический факт без согласованной защиты.
• Перекрывающиеся цели. Слишком широкое условие идентификатора подходит к нескольким разным исходам.

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

Учебный пример: два события после одного ответа

Предположим, тестовая заявка получила внутренний номер test-operation-17. Серверный журнал показывает одно сохранение. Прикладной журнал содержит один вызов из обработчика успешного ответа и второй из обработчика события формы в менеджере тегов. Оба отправляют lead_accepted в один счётчик.

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

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

Выберите границу защиты от повторного учёта

Для уникальной операции защита должна опираться на её устойчивую идентичность, а не на произвольные пять секунд. Повтор в соседней вкладке может случиться позже, а две самостоятельные заявки — почти одновременно. Временное подавление всех событий по имени скрывает часть законных действий.

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

Для серверной очереди обычно задают уникальную пару «операция + смысл события» и состояние доставки. Но получение ответа транспортом не следует автоматически считать появлением события в аналитическом отчёте. Если сервис не поддерживает требуемую идемпотентность, компромисс между пропуском и повтором нужно описать, а не обещать абсолютную гарантию.

У целевых событий Метрики есть ограничение частоты регистрации одной цели. Его нельзя использовать как собственную защиту: оно не понимает, относится ли следующий вызов к прежней или новой бизнес-операции.

Не создайте пропуски во время исправления

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

Для каждого решения запишите, что произойдёт при перезагрузке, неопределённом ответе, повторном запуске обработчика и новой самостоятельной операции. Если браузерная аналитика заблокирована, заявка всё равно должна приниматься. Надёжность бизнес-процесса не должна зависеть от доступности счётчика.

Не добавляйте второй независимый канал отправки «для надёжности», пока не определены правила совместной дедупликации. Дубли часто появляются именно после такого полезного по замыслу улучшения.

Регрессионная проверка

1. Одна успешная заявка создаёт один согласованный факт и одну предусмотренную отправку события.
2. Ошибки валидации и отказ сервера не порождают событие успеха.
3. Обновление благодарности, повторное открытие окна и возврат назад не создают новый факт той же операции.
4. Повторная доставка и задержанный ответ обрабатываются по записанным правилам.
5. Вторая законная заявка учитывается отдельно, в том числе в том же визите.
6. Проверены разные формы, способы отправки и рабочая сборка приложения.

Для контроля используйте отладчик Метрики вместе с журналом приложения. Один лишь итоговый график не показывает, какой обработчик сработал и почему.

Что делать с уже искажённой историей

Отметьте интервал дефекта и перечислите затронутые события. Если есть достоверный внутренний журнал уникальных операций, можно построить отдельный исправленный бизнес-ряд с описанной методикой. Если его нет, прошлое число заявок из завышенной цели точно не восстановить.

Не склеивайте исправленную метрику со старой без отметки о разрыве. После ремонта снижение конверсий может отражать устранение двойного счёта, а не ухудшение сайта. Главный результат работы — восстановленный смысл показателя и тест, который не даст тому же дефекту вернуться незаметно.