<b>Singular ломают не «плохие данные», а один неверный слой в схеме атрибуции</b>

<b>Singular ломают не «плохие данные», а один неверный слой в схеме атрибуции</b>

За спорами про MMP обычно теряется база: кто отправляет событие, с каким user_id, в каком окне, и как оно потом склеивается с кликом или показом. Если эти четыре слоя расходятся, отчёты начинают жить своей жизнью: UA видит один source, продукт — другой, а finance не сходится ни с кем.

Проверьте цепочку по порядку:
— app_instance_id и internal user_id не должны меняться без причины;
— event_name и event_time должны быть одинаково описаны в SDK, backend и BI;
— postback mapping не должен терять параметры между install, reattribution и in-app event;
— окна атрибуции для click/view-through надо фиксировать отдельно, а не «по умолчанию» 🙃

Отдельная зона риска — дубли. Их часто создают не фрод-боты, а собственная инфраструктура: повторная отправка событий, ретраи без idempotency, разные SDK у одного продукта, ручные выгрузки поверх автоматических. Singular тут не волшебник: он честно соберёт то, что вы ему отдали.

Если у вас расходятся отчёты, начинайте не с разборок с источником, а с аудита схемы событий и postback-пути. Когда одна и та же конверсия проходит один маршрут и один раз, MMP перестаёт быть загадкой и становится инструментом.