Расхождение не всегда означает потерю конверсий
Две системы могут показывать разные числа, потому что используют разные правила. Перед тем как искать «пропавшие FTD», нужно проверить определения событий и период отчёта.
Начните с одинакового окна
Самая банальная причина — разные часовые пояса. Если одна система закрывает день по UTC, а другая по локальному времени, события вокруг полуночи окажутся в разных датах. Сравнивайте один и тот же период вплоть до часов.
Чек-лист
| Проверка | Вопрос |
|---|---|
| Время | одинаковый ли часовой пояс и период? |
| Событие | одинаково ли определяется registration/FTD? |
| Дедупликация | может ли одна система удалять повторы? |
| Редиректы | сохраняется ли click_id на всей цепочке? |
| Атрибуция | одинаковое ли окно и правило последнего клика? |
| Статус | сравниваете ли raw FTD с confirmed FTD? |
Ищите не общую разницу, а конкретные строки
Фраза «у меня 120, у вас 108» почти бесполезна. Гораздо сильнее список из двенадцати идентификаторов, которые есть в одной системе и отсутствуют в другой. Это позволяет проверить каждый кейс.
Разделите техническую и бизнес-логику
Если событие не дошло вообще, это техническая задача. Если оно дошло, но получило другой статус, нужно смотреть правила подтверждения. Смешивание этих причин растягивает диагностику.
Нормальный процесс сверки
- Выбрать один день и один источник.
- Экспортировать события из обеих систем.
- Нормализовать время.
- Сопоставить по click_id/SubID.
- Отдельно разобрать отсутствующие и статусные расхождения.
- Только после этого делать вывод о масштабе проблемы.
Профилактика
Стабильная схема SubID и протестированный postback уменьшают количество ситуаций, когда данные приходится восстанавливать задним числом.
Допустимый уровень расхождения нужно понимать заранее
Абсолютное совпадение разных систем бывает не всегда: одна может учитывать блокировщики, другая — только серверные события, третья — собственное окно атрибуции. Важно не игнорировать разницу, а знать её обычный диапазон. Резкий выход за этот диапазон является более сильным сигналом, чем постоянные небольшие отличия.
Сверяйте «воронку событий», а не одно число
Если клики совпадают, регистрации расходятся, а FTD снова близки, проблема находится не там же, где ситуация «клики расходятся с самого начала». Сопоставление нескольких этапов помогает локализовать источник расхождения.
После исправления сделайте контрольный день
Не закрывайте задачу сразу после изменения. Выберите следующий полный день, где обе системы работают с новой настройкой, и повторите сверку. Иначе исправление может выглядеть успешным только потому, что часть старых событий ещё не обработана.
Заводите incident-note
Коротко фиксируйте дату, причину, затронутые кампании и решение. Если похожее расхождение появится снова, история позволит проверить известную причину первой.
Создайте таблицу источников истины
Для каждой метрики определите систему, которую вы считаете основной. Например, расходы — рекламный кабинет, подтверждённый FTD — партнёрская система, внутренние переходы — веб-аналитика. Тогда команда не выбирает удобную цифру из трёх разных интерфейсов.
Разница в определениях важнее интерфейса
Два dashboard могут одинаково называть метрику «конверсия», но считать её по разным датам: один по дате клика, другой по дате события. В документации к отчёту фиксируйте именно определение, а не только название столбца.
Эскалация менеджеру
Передавайте конкретный файл с идентификаторами, периодом, часовым поясом и ожидаемым статусом. Чем лучше подготовлена сверка на вашей стороне, тем быстрее другая сторона может проверить свой лог.