<b>Миграция трекера без потери истории: что сохранить до переключения потоков</b>

<b>Миграция трекера без потери истории: что сохранить до переключения потоков</b>

Перед переездом снимай слепок всей связки: офферы, кампании, источники, таргеты, postback-параметры, naming convention, часовой пояс, валюту, дедуп-ключи. Если не зафиксировать схему данных до переноса, после миграции ты получишь не аналитику, а набор несопоставимых таблиц.

Критичные точки:
— mapping всех ID: click_id, sub_id, lead_id, transaction_id;
— статусы конверсий и правила их изменения;
— UTM/extra-параметры, которые реально участвуют в атрибуции;
— правила фильтрации ботов, IP-исключения, blacklist/whitelist;
— окна атрибуции и логика повторных конверсий.

Исторические отчеты лучше не «перетаскивать» как есть, а замораживать: выгрузи raw-логи, своди их в CSV/JSON и сохрани в отдельном хранилище с версионированием. В новом трекере настрой зеркальный набор полей и проверь, чтобы S2S-postback, пиксель и API-гейт возвращали одинаковый payload. Иначе отчеты по ROI начнут расходиться уже на первом сплите.

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

Миграция считается успешной не тогда, когда интерфейс «похож», а когда данные бьются по событиям и источникам. Data-driven подход или работа вслепую — выбор за тобой.