<b>Атрибуция после iOS 14.5+: как компенсировать потерю сигналов без самообмана</b>

<b>Атрибуция после iOS 14.5+: как компенсировать потерю сигналов без самообмана</b>

После урезания событий на уровне устройства модель атрибуции начинает ошибаться не в пользу медиабайера: растет доля «unknown», ломается сравнение каналов, а окно конверсии становится статистически шумным. Если считать только last click, вы оптимизируете не спрос, а видимость.

Компенсация строится не на одном костыле, а на слое данных:
— server-side events и дедупликация по event_id;
— CAPI/постбэки с нормальной схемой приоритета событий;
— расширение first-party идентификаторов: email, phone hash, customer_id;
— склейка веба и CRM через единый ключ заказа.

Дальше включается вероятностная модель. Для каждого канала оценивайте не «сколько он закрыл», а вклад в инкрементальность: holdout, geo-split, time-lag анализ, сравнение cohort LTV. Если платформа показывает меньше конверсий, это не всегда потери — часть сигналов просто переехала в агрегированную статистику или в более длинный лаг.

Считать нужно по цепочке: показы → клики → серверные события → сделки → возвраты. Если на любом звене нет контроля дедупликации и тайм-окна, ROI будет завышен или занижен случайным образом. Данные — это новая нефть, но только если их правильно очистить.

Оптимизация на уровне юнит-экономики начинается с восстановления сигнального слоя: сначала сбор, потом атрибуция, и только после этого решения по бюджету.