Tracking по device-id после iOS 17/18: что реально ещё можно связать

Tracking по device-id после iOS 17/18: что реально ещё можно связать

После ужесточения iOS device-id перестал быть опорой для «железного» атрибута. Осталось не «одно ID на всё», а связка из нескольких сигналов: click-id, postback, SDK-события, fingerprint с урезанной точностью и серверная дедупликация.

На практике рабочая схема такая:
— в клик всегда прокидывать свой subid и сохранять его на бэке;
— в app-first сценарии сразу фиксировать install-token и first open;
— не полагаться на один идентификатор, а строить матчинг по окну времени, кампании и creative;
— отдельно проверять, где ломается цепочка: webview, store redirect, app open, in-app event. 🔧

Что важно: device-id всё ещё полезен для внутренней склейки и антифрода, но не как единственный источник истины. Если есть ATT-режим и приватные ограничения, часть трафика уйдёт в modeled attribution — и это нормально, если у вас есть резервный контур через server-to-server и логи редиректов.

На практике слабое место почти всегда одно и то же: нет единого event schema. Когда клик, инсталл и целевое событие пишутся в разных форматах, attribution «плывёт» сильнее, чем из-за самой iOS.

Если нужен устойчивый трекинг, проектируйте его от postback, а не от device-id: ID — это только один из слоёв, а не фундамент.