Миграция трекера без потери истории: чеклист, который спасает аналитику

Миграция трекера без потери истории: чеклист, который спасает аналитику

Перенос — это не «переехать в новый интерфейс», а сохранить цепочку атрибуции. До старта зафиксируй: схему кампаний, naming convention, источники трафика, список потоков, postback-URL, токены, параметры sub1–sub5. Без этого исторические срезы превращаются в мусор, а сравнение ROI между старым и новым стеком ломается.

Дальше проверь 4 слоя:
— события и их маппинг: лид, апрув, отказ, рефанд;
— дедупликацию: click_id, external_id, fingerprint;
— таймзону и валюту отчётов;
— окна атрибуции и логику редиректов.
Если хотя бы один слой отличается, цифры в отчётах будут «плавать» даже при одинаковом трафике.

Историю не тащат руками — её экспортируют. Нужны: сырые логи кликов, конверсий и ошибок API; бэкапы постбэков; выгрузка по офферам и потокам; архив правил сплита. Для долгой аналитики лучше хранить данные отдельно от трекера: в CSV/JSON или в своей БД, чтобы потом строить отчёты без зависимости от UI.

После миграции делай параллельный прогон: один и тот же поток ведёшь через старый и новый контур, сравниваешь postback success rate, расхождения по конверсиям и задержки в передаче событий. Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.