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

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

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

Что обычно ломается:
— теряются старые postback-связки и часть событий;
— дублируются или не доходят конверсии;
— сравнение «до/после» становится бессмысленным, потому что меняется не только интерфейс, но и логика атрибуции;
— команда начинает резать рабочие связки, думая, что они просели.

Правильнее было бы не мигрировать в активной фазе, а заморозить на тестовом окне: сначала продублировать события, сверить дашборды, прогнать 24–48 часов параллельного учёта и только потом переключать основной поток. Иначе оптимизация идёт вслепую, а виноватым оказывается не трекер, а собственная спешка.

Вывод простой: менять трекер можно, но не в момент, когда вы ещё не понимаете, где у вас реально есть прибыль.