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

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

Если MMP подключён, а отчёты всё равно «плывут», почти всегда проблема не в SDK, а в дисциплине данных. Базовый чек-лист простой:
— один install_event на устройство;
— единые названия событий во всех платформах;
— не дублировать purchase через SDK и server-to-server;
— заранее согласовать окна атрибуции и таймзону.

В Singular особенно важно не смешивать аналитику и атрибуцию в одну кучу. SDK должен отправлять то, что нужно для привязки источника, а бизнес-события — идти по одной логике во всех каналах. Если event_name меняется от команды к команде, потом нельзя нормально сравнить когорты, воронку и fraud-отсечки.

Отдельная зона риска — postback-логика. Когда один и тот же ивент уходит в несколько систем без фильтра по статусу, появляются фантомные конверсии, а затем «не объяснимые» расхождения между DSP, MMP и BI. Ещё одна типовая ошибка — не проверять ретраи: повторная доставка без idempotency быстро раздувает отчёт.

Лучший способ внедрять Singular — сначала утвердить словарь событий, потом прогнать тестовую схему на одном флоу, и только после этого масштабировать на все источники. Так вы ловите не «магические баги атрибуции», а конкретные ошибки в разметке и постбеках.