Tracking по device-id на iOS: что реально осталось после ужесточения приватности

Tracking по device-id на iOS: что реально осталось после ужесточения приватности

На iOS device-id больше не работает как универсальный якорь. В лоб привязать пользователя к установке и повторному визиту нельзя так, как это делали через старые схемы. Но это не значит, что трекинг умер: он просто стал вероятностным и завязанным на цепочку сигналов.

Что остается в работе:
— SKAdNetwork для постбека по установке и части post-install событий
— first-party данные внутри app/webview: click-id, session-id, timestamp, source
— server-to-server связка, если у вас есть своя логика матчингa
— fingerprint-подобные сигналы только как вспомогательный слой, не как основа

Что важно: если воронка живет на одном device-id, ее легко сломает любой антифрод, редирект или смена источника. Нормальная схема строится так: клик получил свой ID, лендинг сохранил его в cookie/localStorage, app/webview прокинул его в install flow, сервер связал события по времени и атрибутам. Это уже не «точный трекинг», а контроль вероятности совпадения.

На практике: меньше магии, больше дисциплины. Логи кликов, единый формат параметров, резервный postback-канал, отдельная проверка на дубли и потерю атрибуции. Если этого нет, вы не видите трафик — вы гадаете по обрывкам.

Вывод: device-id на iOS больше не опора, а один из слабых сигналов; строить нужно вокруг своих ID и серверной связки.