Make iOS Attribution Great Again. Як обійти обмеження iOS 14.5 за допомогою простої моделі атрибуції трафіку

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт, спільното! Ми — Андрій Дрозд та Руслан Кисельов, аналітики з багаторічним досвідом у продуктових кампаніях. Працюючи над атрибуцією IOS-трафіку, ми зіштовхнулись з думкою індустрії, що ця задача немає рішення або воно занадто складне для реалізації. Натомість ми бачимо простий і практичний підхід до цього питання. У цій статті ми поєднали наш досвід, щоб розкрити тему IOS-атрибуції та поділитися концептуальним підходом, який допоможе вирішувати подібні завдання ефективніше.

З введенням iOS 14.5 компанія Apple запровадила нові правила конфіденційності, що суттєво вплинули на здатність відстежувати користувачів та їхні дії в застосунках. До цієї зміни передавалася повна інформація про те, звідки прийшов кожен юзер до вашого застосунка. Після введення нових правил:

• З точки зору користувачів: вони мають вибір, чи дозволяти застосункам збирати їхні дані. На практиці більшість людей не передає дані.
• З точки зору компаній: втрачається інформація про джерело трафіку кожного юзера, адже Apple приховує IDFA.

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

Як реагує індустрія

Більшість компаній намагаються знайти способи розв’язання цієї проблеми. Вони пробують різні підходи, щоб компенсувати втрату атрибуції:

• Зміна фокусу з iOS на Android.
• Загальний аналіз результатів без детальної атрибуції.
• Аналіз лише тих даних, що мають атрибуцію.
• Використання різних моделей для відновлення атрибуції.

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

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

Що таке атрибуція за суттю

Атрибуція — це інформація про джерело трафіку для кожної установки. Наприклад, якщо у вас є мобільний застосунок, і за місяць ви отримали 1000 інсталів, то інформація про джерело кожного з них (реклама, пошукові системи) є атрибуцією.

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

Оновлення iOS призвело до втрати атрибуції навіть на загальному рівні. На практиці мінімально необхідно відновлювати атрибуцію до рівня медіасорсу та кампанії.

Що потрібно для атрибуції, щоб вона була «хорошою»

Спойлер — не «однакову конверсію на всі медіасорси».

Табл.1: приклад хорошої атрибуції (коли все в таблиці заповнено фактичними числами)

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

Хороша атрибуція — це та, яка надає точну інформацію про джерело трафіку і дозволяє побачити різну результативність для різних медіасорсів. Наприклад, одні кампанії можуть приводити більше платних клієнтів і бути більш окупними, що дозволяє масштабувати ці успішні кампанії. Інші кампанії можуть бути менш ефективними, і їх варто оптимізувати або вимикати, щоб уникнути збитків.

Саме можливість бачити різний і правильний перформанс з різних джерел трафіку і є хорошою атрибуцією і дає можливість цілеспрямовано розвивати маркетинг.

Приклад поточних рішень атрибуції через призму «хорошості»

Женучись за хорошою атрибуцією, ми також можемо натрапити на погані рішення. Наприклад, одним з таких є використання моделей, запропонованих безпосередньо рекламними мережами (Google, Meta). Попри свою доступність вони не завжди є надійними, адже користувачам не розкривається, на яких саме даних базуються ці моделі. І, як показує практика, подібні алгоритми можуть давати суттєві похибки. Ці моделі є не в кожній рекламній мережі, відрізняються за якістю і погано синхронізуються між собою.

Іншим таким підходом є використання статистичних моделей, які будують на основі розподілу інсталів. Але при цьому подальший перформанс, кількість платних клієнтів і доходи — відірвані від інформації про атрибуцію (тому що рекламні сітки не бачать поведінку користувача після інсталу). Так порушується принцип хорошої атрибуції про різний перформанс різних медіасорсів, бо перформанс користувача після інсталу усереднюється між усіма медіасорсами однаково.

Щоб зменшити ризики помилок (нехорошої атрибуції) в умовах відсутності даних iOS 14.5 ми пропонуємо альтернативну модель атрибуції, яка використовує максимум відомих, правильних, фактичних даних і раціональне об’єднання їх з прогнозними, щоб компенсувати відсутність необхідних даних.

Особливі місця, де атрибуція не втрачається

Табл. 2: Приклад заповнення даних атрибуції там, де ці дані не втрачені

Модель атрибуції базується на максимальному об’єднанні правильних і повних даних.

Перший компонент — це особливі місця, де атрибуція не втрачається. В цих місцях є повні та правильні дані в усіх колонках, але лише для окремих рядків-кампаній (табл 2). Тобто для окремих медіасорсів-кампаній є повні дані про івенти на всьому шляху користувачів.

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

Приклади особливих місць даних з повною атрибуцією:

• Закупка через Android.
• Користувачі iOS, які надали дозвіл на трекінг (частка таких користувачів може бути мала, тому що крім дозволу на трекінг в застосунку юзеру також необхідно надати дозвіл на трекінг в рекламній мережі).

Pro tip: Працюйте над оптимізацією ATT consent prompt, щоб підвищити частку користувачів, які погоджуються на трекінг, бо це прямо впливає на відсоток повних даних.

• Apple Search Ads — це медіасорс від самого Apple, в якому атрибуція не втрачається і ми бачимо деталі по кожному користувачу.
• Окремі медіасорси за допомогою AppsFlyer відновлюють атрибуцію з великим відсотком достовірності. Це працює на імовірнісний атрибуції, яку робить AppsFlyer, використовуючи сирі дані від окремих non-SRN медіасорсів.
• Інші методи, що дозволяють зберегти атрибуцію.

Pro tip: Використовуйте ці медіасорси та оптимізуйте їх, оскільки вони забезпечують повну деталізацію атрибуції.

Перераховані джерела трафіку дозволяють зберегти атрибуцію і аналізувати поведінку користувачів після інсталу. А для частин трафіку, де атрибуція втрачається, потрібно доповнити дані, щоб компенсувати відсутність атрибуції: cost, impression, click, install, revenue, refund, а також цільові екшени після інстала. Маючи ці дані в абсолютному вимірі, можна легко вирахувати всі інші потрібні метрики, наприклад CAC, ROI та інші. Ці дані потрібно збирати з різних джерел та інтегрувати в одну повну картину.

Дані з рекламних мереж

Табл.3: Приклад заповнення даних атрибуції — відомих чисел з медіасорсів, після додавання даних на попередньому кроці

Незалежно від втрати атрибуції в усіх рекламних мережах є фактичні правильні дані для доповнення атрибуції, але не всі метрики, які потрібні. Фактичними даними є лише cost, impression, click, джерело трафіку, а решта метрик передаються з інших джерел або моделюються з дискусійною достовірністю. В результаті після додавання цих даних загальна таблиця атрибуції виглядає, як на слайді вище.

Дані про інстали з Apple SKAdNetwork

Табл. 4: приклад таблиці атрибуції — після попередніх кроків — доповнення інсталами зі SKAN

Щоб відновити дані про інстали для частин трафіку, де атрибуція втрачається, потрібно об’єднати два джерела. Частина трафіку, де є атрибуція (особливі місця) + дані про інстали в SKAN (інструмент, який надав Apple на заміну минулій повній атрибуції).

Потрібно врахувати, що ці дані перетинаються, тому необхідно уникнути дублікатів. Друге, що необхідно враховувати — дані SKAN мають суттєві обмеження: є тільки сумарні інстали на рівні дат, медіасорсів і кампаній (в SKAN4.0 додається географія) — тому це джерело накладає обмеження на деталізацію, яку можна отримати. Тобто ми отримуємо дані з атрибуцією, але тільки на рівні кампаній, без деталей.

Дані зі SKAdNetwork Conversion Value

Табл. 5: приклад таблиці атрибуції — після попередніх кроків — доповнення фактичними івентами зі SKAN

Після інсталів потрібно атрибуціювати інформацію про кількість платних клієнтів, доходу і необхідні івенти. Але SKAN накладає суттєве обмеження на інформацію, яка доступна.

SKAN дозволяє передати налаштовану вами інформацію про івенти разом з інсталом (SKAN Conversion Value) і має атрибуцію таку ж, як інстали (дата, медіасорс, кампанія). Але має суттєві обмеження на те, що можна передавати: лише івенти, які стались протягом 24 годин після інсталу і лише закодовані 6 біт інформації. Тобто Apple принципово не дозволяє передавати івенти, які стаються після першої доби (в SKAN 4.0 це обмеження покращується та інформація передається тричі до 35 днів). Наша рекомендація — відсутні дані відновлювати моделюванням.

Необхідно використовувати по максимуму фактичну правильну інформацію. Тому що фактичні дані будуть краще за будь-який прогноз. Для цього треба налаштувати конверсію через SKAN Conversion Value та передавати максимум інформації про івенти та платних клієнтів в рамках цього вікна, яке дозволяє SKAN, і доповнювати загальну таблицю атрибуції цими даними.

Наприклад, якщо для вас важливий івент ліда і в більшості випадків він стається в перші 24 години, потрібно налаштувати його передачу. Якщо для вашого застосунка реалістична ситуація, що в перші 24 години стається покупка, то потрібно передавати дані про кількість платних клієнтів та суму доходу. SKAN Conversion Value має ліміт 6 біт, тому налаштування конверсії, щоб передавати максимум інформації — окрема «наука».

Pro tip: якщо у вашому випадку достатньо інформації лише про факт івентів, то можливо передавати максимум 6 івентів. Але це лише інформація про те, чи відбувся івент, чи ні.

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

За деяких умов SKAN не передає значення конверсій (передає null) — коли на одну кампанію приходить мало інсталів. Щоб протидіяти цьому, можна посилювати кампанії для збільшення кількості інсталів в день та використовувати модельовані конверсії. Їх можна моделювати самостійно або використовувати інструменти маркетингової аналітики AppsFlyer чи аналоги, і таким чином робити поправку на відсоток null конверсій.

Яких даних немає взагалі і що з цим робити

Табл. 6: приклад таблиці атрибуції після попередніх кроків та моделювання на основі фактичних даних

Останній блок, необхідний для моделі атрибуції, — це івенти, які не можуть передаватися через SKAN, але є критичними для розуміння поведінки трафіку. Наприклад, у SKAN 4.0 це будь-які івенти після 35-го дня з моменту інсталу (особливо важливі дані про доходи), а в старіших версіях — івенти після першого дня, як-от подальші покупки.

Як компенсувати цю нестачу? Фактично правильних даних немає в жодному джерелі, тому єдиний спосіб — це змоделювати-спрогнозувати.

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

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

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

Pro tip: не рекомендується використовувати середні результати всього трафіку, краще максимально точно переносити прогнози на конкретний медіасорс або кампанію. Але в крайніх випадках, коли фактичних даних немає для певної кампанії, можна використовувати середнє значення по всьому трафіку або його релевантній підчастині (наприклад, середнє для певного медіасорса або типу кампанії). Чим менша доля таких «середніх» прогнозів, тим краще.

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

Інструменти для реалізації

Загалом щоб отримати результати атрибуції за описаною моделлю, їх потрібно збирати воєдино з різних джерел та за допомогою різних інструментів.

Візуалізувати готовий результат рекомендуємо в BI-системі (Tableau, PowerBI). Дані з різних джерел підтягувати в одну базу даних або хмарні сервіси (GCP, AWS тощо).

Рекомендуємо використовувати дані, які надає AppsFlyer. Він суттєво доповнює і розширює атрибуцію, домодельовує нестачу конверсій в SKAN, дозволяє гнучко налаштовувати ці конверсії та експортувати ці дані в базу даних.

Висновок

З виходом iOS 14.5 перед індустрією постала важка проблема з атрибуцією користувачів, яка на перший погляд не має рішення. Незважаючи на реальну втрату даних, існують шляхи відновлення атрибуції в тому чи іншому вигляді. Пастка деяких рішень полягає в тому, що вони нівелюють саму суть атрибуції — здатність бачити різну прибутковість різних джерел трафіку і масштабуватись відповідно.

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

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