Atomic attribution: почему команды спорят не о слове, а о границе правды

Atomic attribution: почему команды спорят не о слове, а о границе правды

Atomic attribution — это подход, где одну конверсию стараются разложить на минимально неделимые события и правила присвоения. Не «кто последний кликнул», а какие сигналы реально заслужили инкремент: click, view, install, re-engagement, in-app event.

Зачем это UA-команде:
— меньше конфликтов между MMP, ASA и внутренней аналитикой;
— проще объяснить, почему один и тот же install в разных отчётах выглядит по-разному;
— легче строить ruleset для SKAN, где postback часто приходит без полной картины.

Главная ошибка — пытаться сделать atomic-модель «справедливой» для всех каналов сразу. У каждого источника своя задержка, окно атрибуции и набор доступных сигналов. Если не зафиксировать priority rules, lookback window и дедупликацию, отчёт будет не про инкремент, а про хаос.

Проверка простая: в модели должны быть описаны три вещи — какое событие считается атомом, кто получает credit при конфликте, и как система ведёт себя при missing data. Если на эти вопросы нет ответа, атрибуция у вас не atomic, а декоративная.