5 мест, где AppsFlyer чаще всего ломается не в SDK, а в процессе

5 мест, где AppsFlyer чаще всего ломается не в SDK, а в процессе

За ночь: большинство ошибок в атрибуции появляются не потому, что «MMP плохо считает», а потому что где-то рвётся цепочка данных.

— Ивент не совпадает по имени между продуктом и медиа-логикой: purchase, af_purchase, buy — это три разных сигнала для отчётов и автоматизаций.
— Неверно настроены окна атрибуции и reattribution: пользователь уже был учтён, но команда ждёт от него нового first touch.
— Партнёр шлёт postback без нужных параметров, и дальше ломаются LTV-срезы, антифрод и сверка с BI.
— SDK стоит, но часть событий не проходит из-за consent flow, офлайн-стейта или фильтров на стороне приложения.
— Разные команды смотрят на разные отчёты: в одном месте install, в другом re-engagement, а спорят будто это один и тот же ивент.

Что делать: держать один словарь событий, проверять postback-mapping, отдельно тестировать consent и offline-сценарии, а сверку строить от сырых данных, а не от скриншота из дашборда.

Если атрибуция «плывёт», первым делом ищите не воронку, а место, где данные потеряли смысл.