<b>Appsflyer ломается не в отчёте, а в настройке событий и окон атрибуции</b>

<b>Appsflyer ломается не в отчёте, а в настройке событий и окон атрибуции</b>

Если у вас «всё посчиталось», но закупка ведёт себя странно, сначала смотрите не на дашборд, а на схему событий. Типовые ошибки:
— один и тот же post-install event отправляется из разных мест;
— purchase уходит без валюты, а revenue потом живёт отдельно;
— название события меняется между SDK и сервером;
— окно атрибуции длиннее, чем цикл решения у пользователя.

В Appsflyer особенно важно не путать источники истины. Если in-app событие приходит из клиента, а revenue — с бэка, у вас быстро появятся расхождения по LTV, fraud-фильтрам и ретеншну. То же самое с re-engagement: один лишний источник может «съесть» конверсии у paid social или у ASO.

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

Хорошая атрибуция начинается с дисциплины событий: меньше магии, больше одинаковых правил на SDK, бэке и в медиабаинге.