Tracking по device-id в iOS давно не умер — он просто переехал в другие точки контроля

Tracking по device-id в iOS давно не умер — он просто переехал в другие точки контроля

На практике после ужесточения приватности остались не «магические» идентификаторы, а набор сигналов, которые надо собирать и склеивать: IDFV, first-party события, реферальные параметры, server-side postback, fingerprint как запасной слой. Один источник больше не дает полной картины.

Что важно:
— не строить атрибуцию только на device-id;
— заранее держать свой mapping между click_id, install_id и user_id;
— передавать ключевые события с сервера, а не только из SDK;
— проверять, где ломается цепочка: браузер, WebView, app-open, signup, purchase.

В WebView-воронках чаще всего теряется не сам трекинг, а связка между лендингом и приложением. Если не прокидывать UTM, click_id и source в deep link, потом нечего матчить ни в AppFigures, ни в своей BI-схеме. На iOS это особенно видно в сценариях, где пользователь уходит в app без явного install-шага.

На практике лучший подход — считать device-id не якорем, а одним из признаков. Чем раньше вы заведете server-side логику, единый postback и понятную схему дедупликации, тем меньше будет «необъяснимых» расхождений в отчетах.