SKAdNetwork и SKAN 4.0: почему ваша атрибуция на iOS врёт, и что с этим делать?

Если у вас приложение и хоть какой-то бюджет на iOS — у вас сломана атрибуция. Не «может быть сломана». Сломана. Вопрос только в том, знаете вы об этом или нет.

ATT убил детерминированную связку «клик → установка». Apple больше не говорит вам, кто откуда пришёл. Вместо этого — SKAdNetwork, который отдаёт обрывки данных с задержкой, шумом и privacy threshold, из-за которого половина постбэков приходит пустыми. И вот на этих обрывках вы пытаетесь принимать решения по бюджету.

Самое неприятное — для финтеха это бьёт сильнее всего. Почему? Воронка длинная. Установка, регистрация, верификация, первое пополнение, первая сделка — это растягивается на дни, иногда недели. А SKAN живёт в окне постбэка. Событие, которое случилось на десятый день, в стандартную настройку просто не попадёт. Вы оптимизируетесь на установки и регистрации, а платящий клиент появляется за пределами вашей видимости.

Что вообще такое conversion value и почему 6 бит решают всё

В SKAN вы кодируете состояние пользователя в одно число — conversion value. В fine-варианте это 6 бит, то есть значения от 0 до 63. Всё. Вся ваша воронка должна уложиться в 64 состояния.

Звучит как мало. На практике хватает, если не пытаться запихнуть туда всё подряд. Типичная ошибка — кодировать каждый чих: открыл экран, нажал кнопку, посмотрел котировки. Не надо. Кодируйте то, что влияет на деньги: регистрация, KYC пройден, счёт пополнен, первая сделка совершена. Четыре-пять состояний, которые реально что-то значат для бизнеса.

И приоритет тут по ценности, а не по порядку наступления. Если человек пополнил счёт — это важнее, чем то, что он посмотрел десять экранов онбординга. Кодируйте максимальное достигнутое состояние, а не последнее.

Три окна постбэка — и почему про них все забывают

SKAN 4.0 принёс три окна вместо одного: 0–2 дня, 3–7 дней, 8–35 дней. Это то, ради чего вообще стоило обновляться. Длинная воронка теперь помещается.

Но есть подвох — lock window. Вы можете «заморозить» conversion value раньше, чтобы получить данные быстрее. И вот тут люди стреляют себе в ногу: фиксируют значение на втором дне, радуются скорости, и теряют всё, что случилось дальше. Для финтеха с его двухнедельным циклом до первой сделки это самоубийство. Не торопитесь с lock — вам важнее полнота, а не скорость.

Спорный тейк, на котором меня будут поправлять: для большинства финтех-приложений второе и третье окно важнее первого. Первое окно все настраивают, потому что это дефолт. А деньги живут в третьем. Если у вас нет нормального маппинга на 8–35 дней — вы выкинули половину смысла SKAN 4.0.

Coarse value — это не «запасной вариант», это реальность

Когда трафика по кампании мало, Apple не отдаёт вам fine value. Срабатывает privacy threshold, и вместо детального числа приходит coarse: low / medium / high. Три градации вместо 64.

Люди настраивают fine value и забивают на coarse. А потом удивляются, почему по новым или мелким кампаниям одни нули. Настраивайте оба. Coarse должен осмысленно делить вашу воронку на три куска, чтобы даже при низком трафике вы понимали, регистрация это была или платящий клиент.

Что проверить прямо сейчас

Открываете конфигурацию SKAN в своём MMP. Смотрите три вещи. Первое — есть ли вообще маппинг на третье окно, или вся воронка скукожена в первые два дня. Второе — настроен ли coarse value или там пусто. Третье — не стоит ли lock window там, где он режет вам отложенные конверсии.

Если хоть на одном пункте споткнулись — у вас утекают данные, и вы платите за это реальным бюджетом, который Smart Bidding льёт не туда.