Вероятностная атрибуция: как работает и насколько ей верить

Вероятностная атрибуция (пробабилистика, probabilistic modeling, в старых текстах — fingerprinting) связывает установку с кликом без общего идентификатора — по совпадению косвенных признаков: IP-адреса, user-agent, модели устройства, версии ОС и времени. Ее используют как запасной метод, когда нет рекламного ID и install referrer. Работает она только в коротком окне и ошибается чаще детерминированных методов.

#Детерминированные и вероятностные методы

Детерминированный метод опирается на значение, которое физически прошло весь путь от клика до установки. Вероятностный опирается на сходство: «этот клик и эта установка похожи настолько, что, скорее всего, это один человек».

MMP применяют методы по убыванию надежности. В документации AppMetrica порядок прямой: сначала совпадение ID устройства, затем install referrer, и только потом вероятностное сопоставление. У Adjust вероятностная модель описана как вторичный, запасной метод (документация).

#Как работает сопоставление: пример

При клике трекер получает запрос через редирект и записывает признаки устройства. После установки SDK в приложении отправляет свои признаки при первом запуске. Сервер ищет клики с похожим «отпечатком» в окне и выбирает наиболее вероятный.

Пример (иллюстративный). В 14:02 был клик по рекламе с IP 198.51.100.24, user-agent Android 14 и моделью SM-A546B. В 14:09 произошел первый запуск приложения с того же IP, на Android 14 и той же модели. Рекламного ID в клике не было: пользователь удалил его в настройках. Других кликов с такими признаками за последние часы трекер не видел — установка засчитана клику с меткой «вероятностно».

Теперь та же ситуация, но в 14:05 с того же IP пришел еще один клик с той же популярной моделью, только из другой сети. Признаки у двух кандидатов одинаковые, и правило «последний клик» отдаст установку второй сети, хотя пользователь кликал по первой. В этом и состоит главная слабость метода: у него нет способа отличить двух людей с одинаковыми признаками.

#Почему точность падает

MMP публикуют качественные оценки вроде «высокая точность в коротком окне», но проверяемых цифр точности для мобильного трафика в открытом доступе нет. Поэтому разумнее понимать, от чего она зависит, чем полагаться на конкретный процент.

• CGNAT у мобильных операторов. Тысячи абонентов выходят в интернет через один публичный IP, и признак «тот же IP» теряет различающую силу.
• Смена сети. Человек кликнул в метро через мобильный интернет, а приложение открыл дома через Wi-Fi. IP другой — сопоставления нет, установка уйдет в органику.
• Общий Wi-Fi. В офисе, кафе и общежитии за одним IP десятки устройств, часто одинаковых моделей.
• Популярные модели и версии ОС. Чем массовее устройство, тем меньше информации в его user-agent.
• Сервисы, скрывающие IP. VPN и прокси меняют адрес между кликом и установкой. В браузере Safari пользователи iCloud+ могут включить Private Relay, который скрывает реальный IP.
• Время. За часы IP успевает смениться у большой доли устройств, поэтому окна вероятностной атрибуции короткие.

Типичные окна по документации MMP:

#Что разрешают Apple и Google

Apple. На странице о приватности пользователей Apple прямо отвечает на вопрос о фингерпринтинге: по лицензионному соглашению разработчика нельзя получать данные с устройства с целью его уникальной идентификации. В примерах сигналов указаны свойства устройства и браузера, местоположение и сетевое подключение. Приложения, которые так делают или содержат такие SDK, включая сервисы атрибуции, могут не пройти проверку App Store (developer.apple.com). Исключения на случай согласия ATT в этом ответе нет. Как следствие, Adjust применяет вероятностную модель на iOS 14.5+ только в отдельных сценариях: собственные каналы, кросс-промо и web-to-app с согласием, а также как запасной вариант для in-app у пользователей, давших согласие ATT (документация). Основной инструмент атрибуции рекламы на iOS без согласия — SKAdNetwork и AdAttributionKit.

Google. Отдельного запрета на вероятностную атрибуцию в Android нет, но есть правило про рекламный ID. После сброса новый ID нельзя связывать со старым без явного согласия пользователя, а связывание сбросов через другой идентификатор или отпечаток устройства Google прямо называет недопустимым «мостом» (developer.android.com). На практике это значит, что пробабилистика допустима как способ атрибутировать установку без ID, но не как способ восстановить историю пользователя, который сбросил или удалил ID.

#Когда пробабилистика оправдана

• Нет рекламного ID. Пользователь удалил GAID на Android 12+ или включил ограничение, в запросе пришли нули (00000000-0000-0000-0000-000000000000), площадка не передает ID.
• Магазин не дает referrer. Установка из магазина без API referrer или прямой APK.
• Web-to-app. Пользователь кликнул на сайте в мобильном браузере, где рекламного ID нет, и перешел в магазин.
• CTV и десктоп. Показ на телевизоре или компьютере, установка на телефоне в той же сети. Например, у AppMetrica для такой атрибуции устройства должны быть в одной сети в момент показа и установки.

Если в ссылке есть рекламный ID, а магазин поддерживает referrer, пробабилистика почти не нужна: она лишь подхватывает остаток.

#Риск фрода: click spamming

Вероятностное сопоставление — удобная мишень для клик-спама. Фродовый источник отправляет в трекер огромное число кликов, подставляя в них IP и user-agent реальных устройств, но пользователь эти клики не видел. Когда кто-то из этих людей сам, органически, устанавливает приложение, трекер находит похожий клик и отдает установку фродовому источнику. Детерминированные методы такой источник обмануть не может: у него нет ни referrer из магазина, ни настоящего клика с ID.

Признаки клик-спама в отчете:

• доля вероятностных установок у источника заметно выше, чем у остальных;
• время от клика до установки распределено почти равномерно на все окно, без пика в первые минуты;
• CTR аномально высокий, конверсия клика в установку — аномально низкая;
• удержание и платежи у «привлеченных» пользователей не отличаются от органики или хуже нее.

Подробнее о схемах — в статье про рекламный фрод.

#Как проверить качество вероятностной атрибуции

1. Посмотрите на долю метода. Разбейте установки каждого источника по методу сопоставления. Если у сети больше половины установок вероятностные, а у соседних — единицы процентов, это повод для разбора.
2. Сравните когорты. Удержание, платежи и LTV вероятностных установок одного источника сравните с детерминированными установками того же источника. Сильное отставание означает, что часть установок — чужая или органическая.
3. Проверьте на размеченных данных. Возьмите установки, у которых есть детерминированное совпадение, «спрячьте» ID и прогоните вероятностное сопоставление. Доля совпадений с известным ответом — оценка точности на вашем трафике. Если в интерфейсе трекера такой проверки нет, спросите поддержку, можно ли получить для нее сырые данные.
4. Проверьте инкрементальность. Если сомнения остаются, отключите источник на части аудитории и посмотрите, упадут ли установки. Методика — в статье про A/B-тесты в рекламе.

#Как MMP помечают такие установки

В сырых данных и в постбэках трекера у установки указан метод: по referrer, по рекламному ID или вероятностный. У AppsFlyer это поле match type. Что с этим делать, решают стороны: часто договариваются платить за вероятностные установки по сниженной ставке или не платить, если их доля выше оговоренной. Условия лучше закрепить в договоре до запуска, а не после первой сверки.

#Вероятностная атрибуция и Ibiza

DSP Ibiza сама вероятностную атрибуцию не ведет. Конверсия засчитывается только по click_id, который MMP возвращает в постбэке, то есть связь на стороне платформы всегда детерминированная. Identity-граф платформы тоже детерминированный: идентификаторы связываются, только если пришли вместе в одном запросе. При этом в трекинговую ссылку можно подставить макросы {ip} и {ua}, и трекер получит признаки, нужные для его собственной вероятностной модели. Метод сопоставления постбэк не передает, поэтому долю вероятностных установок по кампаниям Ibiza смотрите в отчетах MMP. Список макросов — в разделе макросы и трекеры.