Мобільна атрибуція очима веб-аналітика

Кабінет Google Ads або Meta Ads показує одне, Appsflyer - інше, а SKAdNetwork - третє. Чи дійсно правда посередині? Або до кого вона ближче? Подібних питань в вебі виникає значно рідше і зрозуміти правду не займає багато часу, та мобільна аналітика і трекінг - то зовсім інша, більш закрита тусовка. Розбираємось разом - будуємо мости від зрозумілого вебу до такого складного мобайлу.

Вступ

Цією статтею я відкриваю нову рубрику, де буду покроково йти з самих верхів залучення користувачів в мобільні апки, зупиняючись на кожному відкритому для мене питанню. Йду від власного болю - я працюю в продукті, де основна платформа користувачів - веб. Так, ми маємо додатки, але все ж основний фокус компанії зосереджений не на них. Від цього, можна сказати, страждає mobile acquisition в цілому.

Веб з точки зору трекінгу і атрибуції для мене - вже пройдена гра і челенжів, чесно кажучи, майже не залишилося. Тут атрибуція вираховується на основі page_location, page_referrer - для цього навіть не обовʼязково мати якусь модну аналітику. Проблема з трекінгом? Відкрив developer tools в браузері, запустив превью ГТМу, відкрив DebugView в ГА4 - методів купа, просто бери і роби.

Мобільний трекінг для мене, на противагу - непахане поле викликів. І, якщо порівнювати його з вебом, він складніший як технічно, так і концептуально. Чого лише вартує славнозвісний SKAdNetwork. При тому, як би ти не старався, а на мобілках ти ніколи не отримаєш таку ж точність даних, як на вебі.

Чим мобільна атрибуція відрізняється від вебу?

TLDR: всім, але по порядку.

Ваш сайт доступний з будь-якого браузеру світу - клієнт вбиває адресу і просто переходить на нього. У кожного переходу є свій набір атрибуційних діменшенів, котрі вираховуються на основі URL і сторінки, з якої відбувся перехід на сайт.

Мобільну апку треба спочатку встановити. І тут у нас два великих гравця - Apple Store і Google Play (в обличчі Apple і Гугла відповідно). Щоб скачати, користувач має опинитись на сторінці магазину з самим додатком. Але заруба вже почалася під капотом ще на попередніх кроках. От встановили ви додаток, і що далі? А нічого - магазин (зараз про Apple) не передає в апку жодної інфи з приводу того, яка це була рекламна кампанія або навіть рекламодавець (виключення - Apple Search Ads). Атрибуція, яка у вебі тримається на урлі, тут ламається рівно на моменті, як натискають кнопку Download.

Навіть сам факт завантаження додатку не рахується, як якийсь окремий івент по типу first_visit в ГА4 - перший івент може зʼявитися ТІЛЬКИ з першим відкриттям апки (тобто запуску SDK). І ось саме в цей момент починається дельожка шкури ведмедя - додаток, вірніше SDK від MMP, котра у вас використовується, намагається зрозуміти, що привело користувача на сторінку апки в магазині.

MMP (Mobile Measurement Partner) - це незалежний суддя між вами і рекламними мережами. AppsFlyer, Adjust, Branch та інші: вони бачать усі кліки й інстали і за одними правилами вирішують, кому з мереж зарахувати користувача.

І тут перше важливе розгалуження:

1. Прийти на сторінку апстору можна через атрибуційну лінку вашої MMP;
2. З обʼявки рекламної платформи, котра є SRN
3. Якщо ні перше, ні друге, то ваш інстал буде зарахований в органіку (в світі мобільного трекінгу це близько до прямого трафіку на вебі, але точніше це “ніхто не зарахував собі цей інстал”)

SRN (Self-Reporting Network) - рекламна мережа, яка атрибутує інстали сама. MMP не бачить її кліків, тому надсилає їй інстал і чекає, заявить мережа на нього права чи ні.

На Андроїді, до речі, все дуже просто - Google Play віддає в додаток install referrer, буквально посилання, по котрому людина прийшла в магазин, тож тут все дуже схоже з вебом. На iOS такої краси нема, бо Apple - privacy first. І це - основна глобальна проблема світу мобільної атрибуції.

Замість кукі - айді пристрою, замість браузеру - девайс і SDK

На вебі є client_id (user_pseudo_id), ідентифікатор браузеру, котрий генерується аналітикою при першому заході користувача на сайт і записується у куку _ga. У “світі мобільного трекінгу” айді живуть на двох рівнях:

1. Аналітика. У кожного вендора свій: Firebase - app_instance_id, Appsflyer - appsflyer_id. Тобто айдішник, котрий генерується SDK в момент першого відкриття додатку. Прямий аналог з вебу - user_pseudo_id;
2. Операційна система. Тут у кожної ОС свої айді і в контексті статті вони для нас важливіші. Тож зосередимося на них нижче.

Ідентифікатор розробника. Для iOS це IDFV. Для Android - App Set ID. Однаковий для всіх апок на вашому пристрої від конкретного розробника. Найбільш близька сутність з вебу - first-party куки, але дуже віддалено. За цим ідентифікатором Apple дозволяє зіставити дані юзера між різними застосунками за умови, що ви є їхнім розробником.

Рекламний айді - IDFA на iOS, GAID на Android - спільний ідентифікатор усіх апок на девайсі користувача. Саме він дозволяє зметчити клік по обʼявці в одній апці з інсталом в іншій. Схожу роль у вебі виконують third-party кукі: по них одна компанія впізнає той самий браузер на різних сайтах.

Ось тут ключове для атрибуції - MMP метчить клік з інсталом саме по рекламному айді. Якщо він є - маємо точність, якщо нема - метчимо по ймовірнісній моделі за непрямими ознаками по типу айпі і таймстемпу кліку. Звучить, як фінгерпрінт, котрий Apple забороняє по Licence Agreement для розробників, але вендори наполягають, що це задля метчу кампаній, а не окремих користувачів (що теж, по суті, правда). Виходить така собі сіра зона. Уявляю, яка криза настане в світі мобільного маркетингу, якщо Apple вирішить прикрити цю лавочку…

Навіщо тут узагалі MMP

Якщо для вебу GA4 закриває всі питання як атрибуції, так і поведінки, то в мобілках не все так просто. Коли в тебе купа платних каналів і кожний воліє атрибутувати щось зайве собі, має бути арбітр, котрий визначить, клік або показ якого джерела був вирішальним для інсталу додатку, домовиться з SRN, розшифрує SKAN постбеки і зведе це все під спільний знаменник. Цим арбітром і виступає MMP, тобто сервіси типу Appsflyer, Adjust, Branch, Singular та інші.

“Ми запускаємо лише Universal App Campaigns в Google Ads, більше реклами нема, навіщо нам MMP”? У випадку однієї SRN в вашому арсеналі дійсно можна обійтись і без MMP, бо там (в Гуглі) дійсно працює своя атрибуція. А додайте ще рекламу одночасно у фейсбуці, тіктоку і підключіть пару-трійку партнерок, що тоді, рахувати кожну систему у її власному інтерфейсі? Кожна зарахує собі все, що зможе, і сума по кабінетах вийде більшою за реальні інстали. От саме для цього має бути незалежна сторона з прописаними правилами атрибуції, і виступати для бізнесу єдиним джерелом правди. Такою стороною і має бути MMP. Питання стає ще критичнішим, коли мова йде про перерозподіл бюджетів між каналами, відштовхуючись від їх ефективності.

Друга функція - передавати сигнал у рекламні мережі. Івенти MMP (реєстрація, тріал, покупка тощо) один раз налаштовуються в коді апки або на бекенді, а далі при підключенні нового джерела трафіку робиться інтеграція. Остання - це певний договір про відправку так званих постбеків, щоб рекламні системи могли оптимізувати рекламу на основі тих самих івентів, що й у вашій MMP. Додатково кожна поважаюча себе MMP має у власному арсеналі захист від фроду, збір витрат та підрахунок ROAS/ROI (в деяких - як платні функції), діплінки, роботу з SKAdNetwork тощо.

Чого MMP не робить - продуктову аналітику. Репорти в ньому - зведені і суцільно про маркетинг: яке джерело, кампанія, когорта привели користувача. Людина там - це інстал, котрий треба атрибутувати на якесь джерело, а не користувач, поведінку котрого треба розбирати івент за івентом. Воронки, ретеншн, User Journey, АБ-тести екранів та запис сесій - це вже треба звертатись до сервісів типу Amplitude чи Mixpanel. Натомість інкрементальне тестування реклами - це також територія MMP.

Як подивитися, що йде із застосунку

Наступна кардинальна відмінність між вебом і апкою - тестування івентів. Погодьтеся, що це невідʼємна частина роботи аналітика. Так от: у вебі ми обвішані інструментарієм для дебагінгу - в кожному з ГТМів свій превью, сотні екстеншинів для Хрому для дебагу, врешті решт, сама консоль і Network Tab в Developer Tools. Зробив івент і миттєво бачиш, працює чи ні.

З апками все набагато складніше. Найочевидніше - ти не можеш бачити в апці, які вихідні реквести робить апка, не маючи актуальної збірки від девелоперів + встановлений локально Xcode / Android Studio. Окрім цього, івенти з апки (на реальному пристрої) відправляються пачками, у Firebase, наприклад, приблизно раз на годину. Робиться це для економії трафіку і заряду батареї. На “віртуальному” пристрої це обходиться, увімкнувши режим розробника.

У AppsFlyer є свій аналог превью GTM (певно, у конкурентів також, але з ними досвіду в мене небагато) - сторінка тестування SDK, де івенти видно в реальному часі. Але на iOS вона працює, лише якщо на телефоні дали згоду у вікні ATT (про нього - в наступному розділі). Ще один нюанс - якщо хочете тестувати атрибуцію, зареєструйте свій пристрій як тестовий. Інакше повторне встановлення протягом 90 днів AppsFlyer зарахує як переустановку, і атрибуції отримаєте ре-атрибуцію. В той час на вебі було б достатньо почистити куки або режим інкогніто…

Що зламав ATT і взагалі що це таке?

Вікно ATT уже двічі фігурувало в цій статті. Це - візуальне відображення того, що зламало ринок мобільної атрибуції в далекому 2021.

ATT (App Tracking Transparency) - це вікно самої iOS, котре ви бачите частіше за все при першому запуску щойно скачаного додатку. Текст можна відредагувати, але суть одна: пристрій питає дозволу, чи можна цій апці стежити за користувачем в чужих апках і на чужих сайтах. Для нас, як веб-аналітиків, найближче з світу вебу - кукі банер з режимом opt-in (як у Європі), але з трьома важливими відмінностями:

1. Від відповіді залежить, чи буде пристрою наданий рекламний айді (IDFA);
2. Рендерить це вікно не сайт, і навіть не апка, а сама iOS;
3. В кукі-банері можна видати часткову згоду. Тут - або повний дозвіл, або повна заборона

Полилися сльозки з виходу iOS 14.5 - без згоди в ATT замість реальних IDFA апка почала отримувати суцільні нулі і вся атрибуція, що трималася на цьому айдішнику, полетіла.

Що бачить людина і що може відповісти

По замовчуванню, це вікно апка (в обличчі розробників) показує десь одразу після першого запуску застосунку. Від останніх в ньому - лише можливість впливати на текст у вікні з поясненнями, навіщо потрібно відстеження. Вся решта - за операційною системою (навіть не додатком). Кнопок дві, тож відповідь справді бінарна: дозволив - апка отримує IDFA, відмовив - нулі. Але станів у системи чотири, бо відповіді може й не бути:

1. Дозволив - апка отримує рекламний айді;
2. Відмовив - нулі;
3. Не вирішив - стан, коли банер ще не показався або ОС сама закрила банер без відповіді (коли останнє трапляється, чесно, не знаю);
4. Обмежено - на рівні пристрою (в налаштуваннях) встановлена повна заборона на відстеження.

Є певні правила, продиктовані нормативними актами, наприклад, не можна закривати доступ до функціоналу апки за відмову на банері. Розробникам дозволяється перед банером поставити свій екран-пояснення перед системним вікном, але лише пояснення, чесне і неупереджене, а не заохочення натиснути на кнопку згоди. Якщо це Європа, то при явній відмові повторно показати банер користувачеві можна не раніше ніж за рік.

Яка кількість людей дає згоду на трекінг? В мережі гуляють різні цифри, але однозначно можна сказати, що більшість все ж таки тицяє відмову. І, як і з кукі-банерами, за відсоток згод можна поборотися: показати вікно ATT можна будь-коли на шляху користувача, і Apple сама радить не питати одразу на запуску. Тож розробники тестують показ після якоїсь позитивної події в апці, наприклад, після привітання з проходженням першого рівня в грі або коли людина вже отримала від апки певну користь. Єдиної відповіді тут немає: за даними AppsFlyer, згод найбільше якраз на першому запуску. Одне правило незмінне - пропонувати щось в обмін на «дозволити» Apple забороняє.

А що на Android?

На Android нема такого жорсткого механізму, як ATT: згоди по типу айосної тут немає, рекламний айдішник (GAID, Google Advertising ID) доступний по дефолту. Так, юзер може цілеспрямовано скинути або видалити його в налаштуваннях пристрою - тоді теж підставляються нулі, - але то зайві тілорухи, і мало хто подібним переймається. На “веб-аналітичному” це як кукі-банер у Європі (iOS) проти Америки: у першому випадку за замовчуванням не можна, у другому можна, але з можливістю заборонити. Тож трекінг і атрибуція на Android не є такою значною проблемою для маркетологів, і саме тому основний фокус у статті (і на ринку в цілому) - на iOS. Тим більше, що прийнято вважати: власники iPhone в середньому платоспроможніші за рядового користувача Android.

Чому це насамперед удар по статистиці

Якщо читати поміж рядків і осмислити написане, то ATT з виходом iOS 14.5 поламав не тільки «кому зарахувати інстал». Він зламав бізнес-рішення, які трималися на цьому: які кампанії приносять гроші, які - ні; куди перекласти бюджет або який канал взагалі відключити. Зламалася не тільки атрибуція, поїхали і кількісні показники. З так званою ерою пост-ATT кожна цифра в звіті - це вже оцінка, котру треба вивести прямими і непрямими шляхами, а не сталий факт. І від цього вся мобільна атрибуція така складна і цікава. Стільки танців з бубнами у вигляді SKAN і vendor-specific інструментів (типу ODM & ICM від Google) на вебі точно не буде. Як ніколи і не буде точних цифр. Чи можливі правильні рішення за таких умов? Так, але для мене це поки що залишається на рівні вищого пілотажу.

А ще вишка - це зрозуміти і осмислити весь шлях від А до Я. Наступний розділ саме про це. На мою думку - база баз, дуже складна за концепцією, але одразу закриває купу питань. Знали б ви, скільки я плавав у тому болоті… Тож зекономлю вам трошки часу. Enjoy.

Шлях одного інсталу: від показу до звіту

Трохи повторюсь за веб. Людина клікає по рекламі (при цьому, не важливо, пошукова видача або на сайті), переходить на сайт, аналітика фіксує page_location & page_referrer, фіксується клік айді (та / або набір UTM) і за правилами атрибуції вираховується source / medium.

В мобайлі між показом і першим запуском апки стоїть App Store, котрий далі нічого не передає. Виняток - Apple Search Ads, але там атрибуцію дає сам iOS, а не магазин. Очима користувача, на перший погляд, шлях схожий (єдине, що для вебу нема магазину): побачив рекламу, перейшов в апстор, скачав додаток. Але підкапотна історія куди заплутаніше.

Перше розгалуження - по рекламі якого типу перейшла людина. Варіанти:

• Рекламні мережі з атрибуційною лінкою
• Так звані Self-Reporting Networks

Друга розвилка в логіці йде від того, чи дав користувач згоду в ATT в обох апках - там, де показали рекламу, і в тій, яку рекламують. Окремо від цього паралельним потоком йде SKAdNetwork - власний механізм від Apple, який не залежить від MMP або згоди / незгоди в ATT. На схемах нижче це кроки 1, 6, 10.

Нижче - дві намальовані мною схеми: до інсталу і після. Кроки пронумеровані послідовно. Де є розвилки - позначаю кольорами і додаю літери до нумерації. Як їх читати: спершу відкрийте картинку на повний розмір (клік по ній), а далі - згори донизу і зліва направо, слідкуючи за номерами кроків.

До інсталу

Крок 1. Мережа (неважливо, SRN / non-SRN) показує рекламу в чужій апці (YouTube, Facebook, Instagram - теж апки) або на сайті в Safari. Якщо мережа підписала рекламу для SKAN, пристрій одразу фіксує показ.

Крок 2a-3a. non-SRN (мережа з attribution link). Юзер клікає на оголошення, клік йде редіректом через атрибуційну лінку. В цей момент ваша MMP фіксує у себе інформацію по кліку (включно з IDFA, якщо в додатку-”майданчику” юзер дав згоду на ATT) і перенаправляє людину на сторінку App Store для завантаження. Буває і інше - редіректу через attribution link не відбувається, але рекламна система самостійно повідомляє умовний Апсфлаєр про клік. Результат один - MMP дізнається, звідки відбувся показ або клік.

Крок 2b-3b. SRN (Google Ads, Meta Ads, TikTok Ads, Snap etc). Клік залишається в самій рекламній системі і на цьому етапі в MMP нічого НЕ передається. Оголошення прямо направляє користувача на сторінку апстору

Крок 4. Юзер завантажує апку. Завантаження, як подія, ніде не рахується допоки апка вперше не буде відкрита.

Крок 5. Апка відкривається вперше - вперше запускається SDK від MMP і саме ця подія вважається інсталом. SDK з апки відправляє на сервер MMP таймстемп, IDFV & IDFA (останній - лише за згодою в банері ATT).

Крок 6. Паралельно з запуском додатку SDK ставить перше conversion value = 0 для SKAN. Зазвичай 0 - то саме інстал.

Далі (на наступній схемі) MMP має зрозуміти, кому зарахувати цей інстал. Там - 5 варіантів розвитку подій, але відбувається лише один:

1. Крок 7a-8a - мережа з attribution link, IDFA з обох боків;
2. Крок 7b-8b - мережа з attribution link, IDFA нема хоча б з одного боку;
3. Крок 7c-8c - SRN, IDFA з обох боків;
4. Крок 7d-8d - SRN, IDFA нема хоча б з одного боку;
5. Крок 7e-8e-8e2 - Apple Search Ads

Мережа з посиланням атрибуції

Крок 7a-8a. non-SRNs, IDFA з обох боків (з апки, де побачили рекламу і в апці, котру рекламували і щойно встановили). MMP шукає у себе серед усіх кліків (вікно 7 днів) і показів (вікно 1 день). Пошук відбувається по IDFA - на минулій схемі на кроці 2a він прийшов разом з кліком по оголошенню, а на кроці 5 - в момент першого запуску апки. Якщо вони співпадають (а вони мають, бо у всіх апок в межах пристрою IDFA однаковий), то це - детермінований (точний) метч. Точний метч - найбільш сприятливий для маркетологів (але його меншість).

Крок 7b-8b. Рекламного ідентифікатору нема хоча б з одного боку. Достатньо нулів замість IDFA з однієї сторони і точного метчу не відбудеться. Тоді в гру вступає ймовірнісна модель (probabilistic) з вікном до 24 годин (MMP намагається зметчити по IP + таймстемпам кліку і інсталу) - та сама “сіра зона”, на котрій тримається весь ринок мобільної атрибуції.

Мережа із самоатрибуцією: Google, Meta etc

У випадку з SRN також потрібно дві згоди - в апці, де показали рекламу, і в апці, яку рекламують. Відмінність тут в тому, що найчастіше самі “майданчики” і є апками цих рекламних систем.

• Meta показує ATT вікно у фейсбуці і інстаграмі. Поки людина не відповіла, система вважає, що трекінг заборонений. Тож при кліку по рекламі в цих додатках IDFA передаватися не буде.
• Гугл, що цікаво, в своїх апках на iOS вікно ATT не показує в принципі і IDFA не передає. Виняток - реклама в апці Youtube. Це - єдина апка Гугла з банером ATT.
• Пошук Google на iOS по айді пристрою не атрибутується зовсім - ні в браузері, ні в апці Google. У браузері IDFA немає в принципі: це ідентифікатор лише для апок. А апка Google Search вікна ATT не показує

Крок 7c-8c. SRN, IDFA є з обох боків. Умовний Appsflyer питає всі самоатрибутуючі рекламні системи, з котрими в нього налаштована інтеграція, чи не був у них випадково клік з таким-то IDFA. Мережа, котра такий IDFA знайшла на своєму боці, відповідає “це мій інстал”. В такому випадку MMP атрибутує інстал саме на цю мережу.

Крок 7d-8d. SRN, IDFA нема хоча б з однієї сторони. Тут випадки:

1. Згоду на ATT не дали в вашій апці, тобто з вашого боку нема IDFA. Тут MMP нема з чим йти до інтегрованих рекламних систем і все вирішує тумблер Advanced Data Sharing. Якщо вимкнений, то умовний Апсфлаєр про такий інстал конкретну рекламну систему навіть питати не буде. Якщо увімкнений - спитає по решті інформації, але не по IDFA (котрого нема).
2. IDFA є у вас, але нема на стороні рекламної системи (відмова на стороні апки, де клікнули на рекламу). Тут MMP шукає власника кліку по IDFA, але власник не знайдеться, бо IDFA не був записаний з того боку.

В обох випадках рекламна система може надіслати відповідь “це мій клік” на основі власної ймовірнісної моделі. Але у кожного вендору своя технологія: у Google це ICM, у Meta - AEM. Докладніше - в розділі про шари.

Apple Search Ads, як виняток

Номінально це теж Self-Reporting Network, але з дуже значущим бенефітом на правах спільної з App Store екосистеми. Для повноцінної точної атрибуції цьому каналу IDFA не потрібен взагалі.

Крок 7e. Мобільна апка просить спеціальний токен у фреймворку AdServices і iOS видає його прямо на девайсі. Дійсний він в межах 24 годин.

Кроки 8e, 8e2. SDK передає токен у MMP, а та надсилає його на сервер атрибуції Apple і отримує запис з інфою, яка кампанія привела цей інстал.

Хто вирішує, кому зарахувати

Крок 9. Так званих заявок на один інстал може бути декілька від усіх підряд: Google, Meta, якісь дрібні рекламні партнери з атрибуційною лінкою… Але MMP має визначити лише одного переможця. Правила наступні:

1. Клік важливіший за показ
2. Точний метч сильніший за ймовірнісний
3. Таймстемп кліку - найближчий до інсталу

Якщо на інстал ніхто не заявляє право власника - це вважається органікою. Тут, на відміну від вебу, це безхатько, котрий ближче до (direct) / (none). Отже органічний інстал - інстал, котрий не приписати в заслуги жодному відомому джерелу.

SKAN - паралельно всьому

SKAN - як незалежний аудитор, живе своїм життям і на схемах вище проходить через три кроки:

Крок 1. На айфоні-айпаді в момент показу реклами в апці-”майданчику” рекламна мережа підписує показ, а SKAN цей підпис зберігає на девайсі. Інформація про підпис не покидає вашу операційну систему. При цьому, що дуже важливо, SKANʼу абсолютно не важливо, чи є з боку “майданчика” переданий IDFA.

Крок 6. В момент першого запуску інсталу SDK робить виклик запису Conversion Value і тим самим реєструє інстал в SKAdNetwork, якщо від кліку до інсталу минуло не більше 30 днів, а від показу - не більше 24 годин. Відкривається перше вікно SKAD, але поки воно не буде закрите, дані з вашого пристрою нікуди не йдуть.

Крок 10. Після закриття першого вікна iOS відправляє постбек рекламній мережі (з рандомною затримкою 24-48 годин) по підпису з Кроку 1, повз MMP і серверів Apple - від пристрою одразу в умовний Гугл або Мету. Паралельно з цим є можливість відправки копії постбеку розробнику. Таким чином дані по SKAD також потрапляють в MMP.

Загалом SKAdNetwork - надважлива тема для мобільної атрибуції і точно вартує окремої статті. Сподіваюся, колись до неї руки дійдуть, не виключено, що й найближчим часом.

В принципі, по основам мобільної атрибуції це все. Варто зрозуміти - точний метч кліку і інсталу можливий лише, якщо рекламний ідентифікатор IDFA є з обох боків. Решту інсталів доводиться атрибутувати обʼїздними шляхами - ймовірнісними моделями самих мереж (ICM, AEM) та власною моделлю вашої MMP + сподіватися на агреговані дані від SKAN. Жодна з опцій не закриває питання на 100%, тож на практиці їх складають шарами. Про ці шари - далі.

Чим лагодять втрату IDFA: 3 шари

Після ATT ринок адаптується (MMP і рекламні системи) і знаходить свої воркераунди. Детермінований матч, як був, так і залишається, проте в меншості у порівнянні з імовірнісним метчем, котрий постійно вдосконалюється і обростає новими інструментами на кшталт ICM & AEM. Далі - таблиця з трьох шарів. Два з них - рівень юзера, третій (SKAN) - агрегація по кампанії.

Точне співпадіння - там все ясно, IDFA з двох сторін (перший крок). Другий шар даних - probabilistic matching, коли IDFA є з однієї із сторін або його нема зовсім. І тут усе залежить від типу мережі. Якщо це мережа з лінкою атрибуції, працює ймовірнісна модель самої MMP. Якщо на іншому боці - SRN, як то Гугл або Фейсбук, власна модель працює на боці цих вендорів і вирішує самостійно, чи їх це інстал. Якщо так, то подає заявку до MMP, а остання вирішує вже, чи приймати її. Як ці моделі налаштовані в точності, не знає ніхто окрім самих вендорів.

Третій шар - агрегації від SKAdNetwork. Нагадаю, що згода тут не потрібна, але і даних на рівні юзера ви не отримаєте - лише на рівні кампанії, а деталізація цих даних буде залежати від певних трешхолдів. Про все це, як і пообіцяв, буде в окремій статті.

Окрема опція, в тому чи іншому вигляді - збагачення персональними даними (імейл або телефон) для рекламних мереж. Для цього в інтеграції з конкретною мережею має бути увімкнений Advanced Matching Data Sharing (не плутати з Advanced Data Sharing - назви дуже схожі). Варто зауважити, що на результати атрибуції вашої MMP це не впливає (ви не отримаєте більше заявок з Гуглу і не зменшите таким чином обʼєм органіки).

Найбільше питань викликає другий шар. Точне співпадіння і SKAN працюють за зрозумілими правилами, а от як Google і Meta вирішують, що інстал - їхній, коли IDFA немає, публічно не кажуть. Видно лише, які дані до них ідуть і що повертається назад. Ось як це виглядає схематично.

Google: ODM & ICM

ODM (OnDevice Measurement) дослівно - вимірювання на пристрої. Буває двох видів і кожен переслідує різні цілі.

Суть першого - передача пошти в SDK Firebase після реєстрації юзера в вашій апці (E1-E3). Збіг шукається прямо на телефоні. На виході в Гугл - лише знеособлені дані про те, чи дійсно була конверсія. По суті, це працює на збільшення конверсій в Google Ads для UAC кампаній.

Суть другого виду - знеособлені дані івентів (I1-I6) і саме на цьому працює ICM (Integrated Conversion Measurement). Достатньо мати актуальну SDK Firebase + звʼязки відповідної проперті ГА4 з кабінетом Google Ads. Після першого запуску SDK AppsFlyer сам забирає у Firebase рядок odm_info і відправляє його разом з інсталом. Далі, якщо в інтеграції з Google увімкнено Advanced Data Sharing, AppsFlyer передає Гуглу подію інсталу разом з odm_info, IDFV, IP та user agent, той своєю моделлю вирішує, чи його то інстал, і надсилає заявку. А AppsFlyer перевіряє її вже своєю моделлю.

На виході - більше інсталів з атрибуцією на Гугл саме з боку Апсфлаєру (в сирих даних останнього match_type буде = probabilistic). Тобто зменшується доля органіки на користь Гугла і зменшується розрив між числами івентів в MMP та кабінетом.

Важливий нюанс - обидві технології не працюють в EEA + Британії і Швейцарії.

Meta: AEM

AEM (Aggregated Event Measurement) - технологія, якою Meta рахує інстали й івенти людей, котрі не дали згоду на ATT. Якщо глянути на схему, Meta по крокам робить те ж саме, що Гугл (вірніше навпаки: AEM з’явився раніше за ICM). Головна відмінність - на початку: нема завʼязки на імейлі і odm_info.

Якщо в інтеграції з Meta в AppsFlyer увімкнений Advanced Data Sharing, інстали передаються без IDFA, але з IDFV, IP та юзер агентом (A1-A2), власне тут аналогічно до ICM. IP при цьому маскувати не можна (опція з боку MMP) - інакше івенти для AEM не підійдуть. Далі Meta вирішує, чи належить їй цей інстал (A3), і якщо так - надсилає клейм в AppsFlyer по ласт кліку, з вікном до 24 годин (A4). А от чи перевіряє AppsFlyer ці клейми своєю моделлю, як у випадку з Гуглом, - не розкривається (A5).

Що AEM, що ICM, в принципі, подібні технології + певний блекбокс у кожної. Обидві доставляють заявки в MMP майже в реальному часі. Різниця - в самому кабінеті: Meta на тих самих сигналах AEM показує звіти в Ads Manager і вчить рекламу, а Google заявок ICM у своєму кабінеті не показує - там свої модельні конверсії, які дораховуються до п’яти днів.

Як звести шари докупи

Як-як, в MMP - це одна з його сутностей. Якщо просто скласти класичну атрибуцію (все, що можна заметчити на рівні юзера) і SKAN (агрегація на рівні кампанії), ми отримаємо більше, ніж є насправді: SKAN - паралельний потік, і той самий інстал може мати ще й детермінований метч, тож певні інстали можуть порахуватися двічі.

В AppsFlyer для цього є SSOT (Single Source of Truth). Він зводить обидва потоки до агрегату рівня кампанії (як спільний знаменник) і прибирає дублі. Інстал, який бачили обидва, рахується один раз за класичною атрибуцією, а той, що є лише в SKAN, додається зверху.

У цього є ціна - один біт із шести в conversion value для SKANʼу. Тобто якщо без SSOT флажку ви маєте можливість зашити 64 значення (від 0 до 63), можливість робити таку собі дедуплікацію коштуватиме вам 2 в пʼятій степені (32) - рівно половину значень від 64. Ставить цей флаг сам SDK AppsFlyer - прямо на телефоні, при першому запуску, якщо атрибуція вдалася. А от як він дізнається результат атрибуції, коли IDFA немає то вже блекбокс. Та чому тут дивуватися - це ж мобільний трекінг ¯\_(ツ)_/¯

Висновок

Світ мобільного трекінгу і маркетингу завжди залишав у моїй голові купу незрозумілостей. Щось ніби розумієш, щось відчуваєш, але чи правильні твої поверхневі висновки? Важко оцінити, коли все ж таки пріоритет на роботі цілком на стороні вебу.

У вебі, по суті, все детерміновано (якщо винести за дужки адблокери і відмови по консенту). Атрибуція там, по суті, безкоштовна: достатньо знати page_location & page_referrer і порахувати джерело трафіку можна самостійно. Тому я довго не розумів, за що конкретно системи типу Апсфлаєру гребуть такі гроші. Бо не було розуміння, наскільки важкий процес відбувається задля визначення того, хто привів користувача до інсталу. Бо на вебі нема таких речей, як опитати всі SRN, розшифрувати постбеки від SKAN, звести до купи детермінованих юзерів і агрегати від Apple, врешті решт, зрозуміти, кому і чому зарахувати інстал.

Тож відповідь на питання “Де правда?” з початку статті: вона не посередині - MMP і має бути правдою, бо це - арбітр, котрий намагається звести гравців типу Гугла і Мети під одні загальні правила підрахунку. Якщо ваша правда не прямує до даних MMP - питання до вашого мобільного трекінгу.

А ще MMP - це місточок до продуктових даних. Заджойнити користувачів по класичній атрибуції до продуктових даних, зробивши поправку на агрегат від SKAN - цілком можливо. Тож якою б не була велика спокуса рахувати CAC по конверсіях Гугла або Мети, правильніше рахувати її по подіях Апсфлаєру і йому подібним сервісам.

Детермінованих користувачів - меншість, решта - моделі.

Якщо порівнювати мобілки з вебом, то у мене пробігає паралель з алгеброю та геометрією. Знаючи алгоритм дій, формули і арифметику, скоріш за все, ти прийдеш до відповіді. В геометрії чітких інструкцій замало - треба думати, дивитися з різних боків, аналізувати. Тому, як на мене, спеціалістів, реально шарящих за мобільний трекінг, аналітику і маркетинг в цілому, днем з вогнем не знайти і кожен, хто на рівні розуміння освоїв мобільну атрибуцію та всі ці страшні абревіатури - на вагу золота.

Окремо хочу подякувати самому собі, що я взявся за цю статтю і особливо - що намалював ці три схеми. Чесно, багато чого б віддав за подібну вижимку знань на початку, коли тільки почав торкатися мобільних апок. Цією статтею я відкрив нову рубрику, котра щиро мене драйвить і, судячи з того, скільки питань вона закрила особисто мені, продовженню бути. Якщо ви теж зараз там, де я був на початку, сподіваюся, ця карта зекономить вам кілька тижнів блукань.