MMP ломается не в SDK, а в договорённостях между источником, продуктом и аналитикой

MMP ломается не в SDK, а в договорённостях между источником, продуктом и аналитикой

Если воронка «плывёт», сначала проверьте не интерфейс MMP, а базовые правила: какое событие считается install, где начинается trial, кто владеет purchase, как передаётся revenue. Без этого один и тот же ивент в отчётах превращается в три разных сигнала.

Дальше — карта атрибуции. Нужны фиксированные окна, единый приоритет каналов и список того, что считается reassignment. Иначе ретаргетинг съедает органику, а paid social внезапно выглядит сильнее поискового трафика. Это не баг, а отсутствие общей логики.

Отдельно проверьте postback-цепочку: какие поля реально уходят в сеть, какие режутся, где теряется source ID, как обрабатываются null и дубль-ивенты. Ошибка часто сидит не в трекинге, а в том, что BI и MMP сравнивают разные сущности под одним названием.

Ещё один обязательный слой — тестовый контур. Любое изменение кампании, схемы deeplink или revenue-параметров сначала прогоняйте на одном канале и одном событии, а потом уже масштабируйте. Иначе вы чините одну интеграцию, а ломаете пять.

Если MMP нужен как источник правды, у него должен быть один владелец схемы данных, а не «все по чуть-чуть»; иначе отчёт всегда будет спором, а не инструментом.