iOS-приватность ломает атрибуцию не «вдруг», а по четырём типовым узлам

iOS-приватность ломает атрибуцию не «вдруг», а по четырём типовым узлам

Первый узел — разрешение на трекинг. Если у вас есть кросс-апп или кросс-сайт связка, не считайте, что идентификатор доступен по умолчанию. Второй — потери на уровне браузера и in-app webview: часть кликов, рефов и событий режется ещё до анализа.

Третий узел — postback и дедупликация. Когда один и тот же конверт приходит из нескольких источников, без жёсткой логики приоритета вы завысите результат. Четвёртый — модельное измерение. Если событие не приходит в сыром виде, не пытайтесь компенсировать это «на глаз» в отчётах.

Что проверить в трекинге: — есть ли fallback на first-party storage; — настроен ли consent-gate до отправки событий; — совпадают ли окна атрибуции в рекламной системе и аналитике; — есть ли отдельная валидация по server-side событиям; — не смешаны ли в одном отчёте consented и non-consented данные.

На практике лучший подход простой: сначала фиксируете, какие события вы вообще можете собирать без потерь, потом строите отчётность вокруг них. Иначе любой рост или просадка будут выглядеть как «проблема в трафике», хотя сломалась только измерительная схема.