Атрибуція застосунку з AppsFlyer: OneLink, SKAN і дашборд з доходом

Для мобільного застосунку запитання «звідки прийшов користувач» складніше, ніж для сайту: між кліком на рекламу і першим запуском стоїть магазин застосунків, який не передає UTM. Цю прогалину закривають MMP (mobile measurement partners). AppsFlyer — один з найпоширеніших.

#Що робить MMP

• Атрибуція встановлень: зіставляє встановлення з кліком або показом реклами в мережах (Meta, Google, TikTok, Apple Search Ads та інших).
• In-app події: реєстрація, trial, підписка, покупка — з прив'язкою до джерела встановлення.
• Deep linking: ведення користувача з посилання одразу на потрібний екран застосунку.
• Постбеки в мережі: повідомлення рекламним платформам про конверсії для оптимізації.
• Захист від фроду: фільтрація підозрілих встановлень.

#OneLink: міст між сайтом і застосунком

OneLink — посилання AppsFlyer, яке:

• на мобільному відкриває застосунок, якщо він встановлений, або веде в потрібний стор;
• після встановлення відкриває потрібний екран (deferred deep link);
• зберігає параметри кампанії для атрибуції.

Практичне застосування для бізнесу — кнопки «Завантажити застосунок» на сайті. Якщо кожна кнопка — це OneLink з параметрами розміщення (банер на головній, сторінка товару, футер), ви бачите, скільки встановлень приносить сайт і які розміщення працюють. Ці кліки варто відстежувати і в GA4 як подію, щоб побудувати повну воронку «сесія на сайті → клік на OneLink → встановлення → підписка».

#iOS: ATT і SKAdNetwork

Після впровадження App Tracking Transparency на iOS атрибуція на рівні користувача можлива лише за згодою. Для решти використовується SKAdNetwork (SKAN) — агреговані постбеки від Apple з обмеженою інформацією і затримкою. Наслідки для аналітики:

• на iOS частина встановлень приходить без детальної атрибуції або з затримкою;
• значення конверсій у SKAN кодуються обмеженим набором значень — їх схему треба продумати заздалегідь;
• iOS і Android не можна порівнювати напряму за CPI і ROAS — різні методи вимірювання.

#Що з'єднувати в дашборді

Ключ з'єднання — ідентифікатор користувача в застосунку (customer user ID), який передається і в AppsFlyer, і в білінг, і в Firebase. Без нього зв'язати встановлення з доходом практично неможливо.

#Метрики за каналами

ROAS у застосунках завжди когортний: виручка рахується від дня встановлення (когортний аналіз). Для підписок додайте комісію стору — валова виручка і чиста суттєво відрізняються.

#Типова структура екрана «Маркетинг застосунку»

• KPI: встановлення, CPI, нові підписники, ROAS D30;
• таблиця медіа-джерел з витратами, встановленнями, trial, підписками, ROAS;
• окремо iOS і Android;
• блок «Сайт → застосунок»: кліки OneLink за розміщенням і встановлення з них;
• когорти утримання D1/D7/D30 за джерелами.

Повний набір метрик продукту — у статті про метрики SaaS і застосунків. Загальна логіка моделей — у гайді з атрибуції.

#Типові помилки

• Не передавати customer user ID — і не мати зв'язку з доходом.
• Порівнювати CPI iOS і Android «в лоб».
• Рахувати ROAS за датою покупки, а не за когортою встановлення.
• Кнопки на сайті ведуть прямо в стор без OneLink — сайт як канал «невидимий».
• Не враховувати комісію сторів у LTV.

#Чекліст

• SDK AppsFlyer інтегровано, in-app події узгоджені з продуктом
• Customer user ID передається в MMP, білінг і аналітику
• Схема конверсійних значень SKAN продумана
• Усі кнопки «Завантажити» на сайті — OneLink з параметрами розміщення
• Кліки по OneLink відстежуються в GA4
• Витрати всіх мереж в одній таблиці
• ROAS і LTV — когортні, з урахуванням комісій

#Покроково: дані MMP — у власне сховище

Дашборд MMP відповідає на «яка кампанія привела встановлення». Бізнесові питання — виручка за когортами встановлень, окупність за каналами, маржа — потребують даних поряд із бекендом. Звичний шлях:

1. Оберіть спосіб вивантаження. AppsFlyer пропонує агреговані API звітності і вивантаження сирих даних (доступність сирих даних і data locker залежить від тарифу — що входить у ваш договір, дивіться в довідковому центрі AppsFlyer).
2. Завантажуйте щоденні агрегати за датою, медіаджерелом, кампанією і країною: встановлення, витрати (якщо підключено дані про вартість), події в застосунку і виручка.
3. Завантажуйте сирі встановлення і події, якщо доступні, з AppsFlyer ID і вашим власним ID користувача (customer_user_id), щоб з'єднувати з користувачами бекенду.
4. Передавайте власний customer user ID у SDK під час входу чи реєстрації. Без нього з'єднання даних MMP з виручкою бекенду — це вгадування.
5. З'єднуйте з виручкою бекенду (підписки, покупки, повернення) за customer user ID і будуйте когорти за датою встановлення і медіаджерелом.

#Приклад: когорти встановлень за каналами

Ілюстративний застосунок з підпискою, встановлення за один місяць, виручка з бекенду за вирахуванням комісій сторів і повернень:

Найдешевші встановлення — не найцінніші. Apple Search Ads коштує за встановлення у 2,5 раза більше, ніж TikTok, але за 90 днів повертає більше, ніж коштує. Якщо оптимізувати за CPI, бюджет тече в неправильний бік. ROAS на 90-й день потребує когорти віком 90 днів, тож звітуйте ковзний набір зрілих когорт, а для швидших висновків використовуйте ранні сигнали (початки тріалу, платні на 7-й день).

#SQL: ROAS на N-й день за медіаджерелами

WITH inst AS (
  SELECT customer_user_id, media_source, DATE(install_time) AS install_date
  FROM clean.af_installs
  WHERE customer_user_id IS NOT NULL
),
rev AS (
  SELECT i.media_source, i.install_date,
         SUM(IF(DATE_DIFF(DATE(p.paid_at), i.install_date, DAY) < 90, p.net_amount, 0)) AS rev_d90
  FROM inst i JOIN clean.payments p ON p.user_id = i.customer_user_id
  GROUP BY 1, 2
)
SELECT r.media_source, DATE_TRUNC(r.install_date, MONTH) AS cohort,
       SUM(r.rev_d90) AS rev_d90, SUM(c.cost) AS cost,
       SAFE_DIVIDE(SUM(r.rev_d90), SUM(c.cost)) AS roas_d90
FROM rev r
JOIN mart.af_cost_daily c ON c.media_source = r.media_source AND c.day = r.install_date
WHERE r.install_date < DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
GROUP BY 1, 2;

Приєднуйте витрати на рівні «день + джерело», як тут, або спершу агрегуйте обидві сторони до рівня когорти — щоб не помножити витрати на кількість платних користувачів.

#Реалії iOS

На iOS дані на рівні кампаній для користувачів, які не дозволили відстеження, надходять з Apple SKAdNetwork / AdAttributionKit. Вони агреговані, із затримкою та обмежені порогами приватності, тож ROAS на N-й день за кампаніями на iOS завжди буде частковим. Практичний підхід:

• Значення конверсій SKAN прив'язати до найбільш прогностичної ранньої події (наприклад, початку тріалу чи першої покупки)
• Порівнювати канали на iOS на рівні медіаджерел, на рівні кампаній — лише де дозволяють дані
• Перевіряти тестами інкрементальності найбільші канали на iOS, див. гайд з атрибуції

#Часті запитання

#Чи потрібен AppsFlyer, якщо є Firebase?

Firebase добре відстежує поведінку, але атрибуцію встановлень платних кампаній у різних мережах і постбеки зазвичай робить MMP. Для застосунків з платним залученням MMP майже обов'язковий.

#Чому дані AppsFlyer не збігаються з кабінетом Meta чи Google?

Різні вікна й правила атрибуції, view-through, SKAN на iOS. Для рішень між каналами беріть один «суддя» — MMP — і зважайте на його обмеження.

#Як виміряти, скільки встановлень дає сайт?

Використовуйте OneLink на всіх кнопках і банерах сайту з параметрами розміщення та відстежуйте кліки в GA4.

#Чи можна вивантажувати сирі дані AppsFlyer у BigQuery?

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