Appsflyer ломается не на SDK, а на грязной схеме событий и атрибуции

Appsflyer ломается не на SDK, а на грязной схеме событий и атрибуции

Если в Appsflyer «не сходится» отчет, почти всегда проблема не в самом MMP, а в базе: лишние события, дубли, разные имена ивентов у приложений, неверные окна атрибуции или конфликт между first-party логикой и постбеками.

Проверьте 4 вещи:
— одно событие = одно имя + одна бизнес-логика
— purchase и revenue не должны уезжать в разные сущности
— re-attribution и re-engagement не должны считать один и тот же юзер дважды
— органика не должна подмешиваться в paid через кривые UTM, deep link или server-to-server

Отдельно следите за postback map: если партнерам уходят не те статусы, они начинают оптимизировать на мусорные сигналы. В итоге байер видит «нормальный» CPA, а продукт получает фрод, инсталлы без value и красивые, но бесполезные отчеты 📉

Еще одна типовая ошибка — смотреть только на dashboard. В MMP важнее не график, а цепочка: install → event → revenue → postback → BI. Если на одном звене есть задержка или расхождение по таймзоне, весь отчет выглядит «сломанным».

Держите схему событий и правила дедупликации в одном документе, а не в голове у аналитика. В Appsflyer выигрывает не тот, кто поставил SDK, а тот, кто заранее описал, как именно приложение считает пользователя, событие и деньги.