Партнёрка занизила EPC задним числом: как ломается отчётность

Партнёрка занизила EPC задним числом: как ломается отчётность

Контекст: вебы лили по одной связке, сверяли планку по EPC и строили масштабирование на цифрах из кабинета. Потом партнёрка пересчитала постфактум: в отчёте прибыль уже «не сходилась», а решение о бусте кампании оказалось принято на мусорных данных.

Что пошло не так:
— не зафиксировали исходные отчёты до изменения условий;
— сравнивали только EPC, не смотрели CR, approve rate и payout по каждому источнику;
— не было отдельного лога по датам, офферам и правилам атрибуции;
— команда приняла изменение метрики как «обычную коррекцию», хотя это меняет экономику теста.

Что нужно было сделать иначе:
— выгружать снапшоты отчётов и хранить их вне кабинета;
— считать не одну метрику, а связку EPC + CR + approve;
— заранее прописывать, что считается основанием для пересчёта;
— держать запасной оффер, если партнёрка режет аналитику задним числом.

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