iOS privacy ломает атрибуцию не в одном месте, а сразу в трёх

iOS privacy ломает атрибуцию не в одном месте, а сразу в трёх

Первое — ограничения IDFA. Если пользователь не дал согласие, связка install → event становится хуже, а «точный» роутинг по юзеру исчезает. Второе — скрытие части параметров в in-app и web flow: клики, реферер, UTM и постбэки могут доходить не так, как ожидает трекер. Третье — агрегация сигналов: вместо одного полного профиля вы часто получаете набор обрывков. 📉

Что важно: ломается не только отчётность, но и оптимизация. Алгоритмам хуже обучаться, если события приходят с задержкой, в разном формате или без стабильного source mapping. Отсюда типовая ошибка — сравнивать платформенные отчёты с внутренней аналитикой как будто это одна и та же система.

Что делать на практике:
• заранее разделить «измеряемое» и «решающее» событие
• хранить собственный source of truth по кампаниям и неймингу
• проверять, где теряются UTM, referrer и click IDs
• ставить серверные события туда, где это возможно
• тестировать путь пользователя от клика до конверсии на реальных девайсах

Если у вас воронка на iOS, не пытайтесь выжать из неё старую модель точного user-level трекинга. Лучше строить атрибуцию как систему с допусками: меньше магии, больше стабильных правил.