Переход на новый трекер во время активного спенда ломает оптимизацию чаще, чем кажется

Переход на новый трекер во время активного спенда ломает оптимизацию чаще, чем кажется

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

Что обычно ломается:
— дублируются или теряются postback-события;
— расход и конверсии расходятся по разным системам;
— старые и новые UTM/клики живут параллельно;
— оптимизация идёт по неполному срезу, и связка режется раньше времени.

Главная ошибка — считать трекер нейтральной заменой интерфейса. Это не так: меняется логика сбора, а значит меняется база для решений. Если в этот момент ещё и тестируются новые креативы, команда уже не понимает, что именно убило CTR или CR: связка, оффер или кривой учёт.

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

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