Singular ломается не в атрибуции, а в настройке событий и их иерархии

Singular ломается не в атрибуции, а в настройке событий и их иерархии

У большинства команд проблемы начинаются не с MMP, а с путаницы в том, какие события вообще должны жить в схеме. Если purchase, подписка и trial смешаны в один поток, отчёты становятся шумными, а оптимизация — слепой.

Базовый чек-лист для схемы:
— одно событие = одна бизнес-цель
— названия должны быть одинаковыми в приложении, MMP и BI
— revenue, currency и transaction_id передаются всегда в одном формате
— все ключевые события отмечены как source of truth, а не дублируются случайно

Вторая типовая ошибка — ожидать, что postback решит всё сам. Singular хорошо работает, когда у вас заранее определены окна атрибуции, дедупликация, правила по re-engagement и логика для SKAN/AEM. Без этого любой source начинает выглядеть «лучше», чем есть на самом деле.

Третья зона риска — разъезд между маркетингом и продуктом. Если команда закупки видит только install и trial, а продукт меряет activation и retention, вы оптимизируете разные воронки. Связывайте MMP-события с внутренними KPI, иначе отчётность будет красивая, а закупка — дорогая.

Проверка перед масштабом одна: откройте сырой поток событий и найдите дубли, пустые revenue и рассинхрон между ID. Если это не чисто, масштабировать рано.