7 типовых ошибок в AppsFlyer, из-за которых атрибуция начинает врать

7 типовых ошибок в AppsFlyer, из-за которых атрибуция начинает врать

Первое: сводить все кампании в одну пачку. Когда в naming нет структуры, потом невозможно отделить paid social от affiliate, а ретаргет — от acquisition. Второе: не фиксировать postback-логику по каждому источнику. Если событие уходит не на тот ивент или с задержкой, MMP рисует красивую, но бесполезную картину.

Третье: путать install с first_open и считать это одной и той же точкой входа. Четвёртое: не проверять окна атрибуции перед запуском. Короче окно — больше last-click перетягивает на себя, длиннее — сильнее шум от старых касаний. Пятое: не настраивать deep link и deferred deep link отдельно — это два разных сценария, и ломаются они тоже по-разному.

Шестое: не смотреть raw data до того, как идти в дашборды. Если в сырых событиях уже каша, отчёты только красиво её упакуют. Седьмое: доверять одной метрике. ROI без разреза по источнику, крео, GEO и окну ретеншна часто маскирует fraud, переток и плохую сегментацию.

Проверка нужна не в интерфейсе, а на уровне схемы: источник → клик → инстал → событие → сверка raw data. Если цепочка прозрачна, AppsFlyer работает как счетчик, а не как генератор споров.