Мобільна аналітика та оптимізація кампаній: чому для просування застосунку на iOS та Android замало лише Firebase
Часто, коли запускають промо мобільних застосунків одночасно на Android та iOS, виникає спокуса обмежитись Firebase (Google Analytics for Firebase) - він безкоштовний і вже інтегрований з Google Ads. Але якщо рекламний мікс ширший за один кабінет, цього недостатньо: Firebase добре працює всередині екосистеми Google, проте не дедуплікує інстали між різними мережами, обмежений у deep linking і не дає повноцінного захисту від фрод-трафіку. Тому мобільний маркетинг застосунку з кількома каналами залучення зазвичай будується на окремому MMP (Mobile Measurement Partner) поверх Firebase, а не замість нього.
Геозона визначає, скільки даних ви отримаєте з iOS
Головне джерело обмежень на дані користувачів iOS - не GDPR, а фреймворк Apple App Tracking Transparency (ATT) і SKAdNetwork: вони діють однаково в усьому світі й залежать від того, чи дав користувач дозвіл на трекінг, а не від його країни. Без згоди IDFA повертає самі нулі, і рекламодавець отримує лише агреговані, відкладені дані через SKAdNetwork.
GDPR - окрема, суто європейська правова рамка про обробку персональних даних, а не причина роботи SKAdNetwork. На практиці в ЄС на запит ATT накладається ще один шар згоди - cookie- та consent-банери за вимогами GDPR й ePrivacy, тому частка користувачів, що погоджуються на трекінг, там нижча. Для аудиторії в Україні, США, Латинській Америці, Азії чи Африці рекламні мережі на практиці частіше отримують більше сигналу про iOS-користувачів - не через інший закон, а через вищий opt-in rate без подвійного шару згоди.
AppsFlyer і Adjust: навіщо потрібен окремий MMP
AppsFlyer та Adjust - два провідні MMP на ринку. У Power-UP ми частіше обираємо Adjust - за гнучкість налаштувань і швидку, лояльну підтримку, - але принципової різниці в підході немає: головне не бренд MMP, а кількість каналів і афіліатів, які через нього можна звести в одному вікні.
Будь-який провідний MMP уже інтегрований через API з усіма великими рекламними мережами - Google Ads, Meta Ads, TikTok Ads, Apple Ads і Snapchat. У термінології MMP їх називають SAN (self-attributing network) - мережі, що самі рахують собі атрибуцію. Теза «з AppsFlyer чи Adjust можна працювати з Google Ads і TikTok Ads, а з Meta Ads не вийде» - неточна: Meta Ads так само є SAN і так само підключається до MMP. Різниця лише в тому, що SAN передає назад не сирі дані кліків і показів, а власні, вже готові заяви про конверсії.
Чому власний SDK рекламного кабінету все одно потрібен
Тут ховається головне правило оптимізації. Дані, які SAN-мережа отримує через постбек від MMP, - це по суті лише кількість підтверджених подій: умовно, «за три дні з 1000 інсталів MMP зарахував 20 покупок», без жодних додаткових сигналів про користувача чи пристрій.
Якщо ж до застосунку одночасно підключено Firebase (для Google Ads), Meta SDK чи Conversions API (для Meta Ads) і TikTok SDK (для TikTok Ads), кожен кабінет отримує не просто факт конверсії, а повноцінні сигнали про користувача й пристрій - і саме на них навчається його алгоритм. Це дозволяє перевести кампанію з оптимізації «під інстали» на оптимізацію під цільову вартість дії (tCPA) чи цінність (value-based bidding), орієнтуючись на реальні events у застосунку.
Практичне правило просте: кожному рекламному кабінету - власний SDK для навчання алгоритму, а зведену, дедупліковану картину по всіх каналах дивитись уже в «єдиному вікні» AppsFlyer чи Adjust.
Чому цифри в кабінетах і в MMP ніколи не збігаються ідеально
Навіть за ідеально налаштованих SDK дані рекламної мережі й дані MMP завжди трохи відрізнятимуться - і це нормально. Кожна SAN-мережа застосовує власну модель атрибуції (за кліком, показом чи переглядом відео) і зазвичай ширше вікно атрибуції, ніж MMP, який дедуплікує інстали між усіма мережами одночасно й приписує конверсію лише одному каналу за принципом last-touch. Тому для оцінки витрат довіряють кабінету, а для порівняння каналів між собою - дедуплікованим даним MMP: жодне з двох джерел саме по собі не «неправильне».
Окремий випадок: Apple Search Ads
Apple Search Ads (ASA) - реклама в самому App Store - атрибутується інакше, ніж решта SAN: не через SKAdNetwork, а через власний фреймворк AdServices. Атрибуція відбувається на пристрої, і Apple напряму передає campaign ID, adgroup ID, ключове слово й творчий елемент. Через це дедуплікація ASA з іншими мережами обмежена: клікнув користувач і рекламу в Meta, і в ASA - обидва джерела можуть претендувати на одну інсталяцію.
Висновок
Просування застосунку на Android та iOS одночасно - це робота з кількома рекламними кабінетами, кількома моделями атрибуції і хоча б одним MMP для зведеної картини. Якщо потрібно вибудувати таку мобільну аналітику з нуля або розібратись, чому цифри в кабінетах не збігаються з AppsFlyer чи Adjust, - команда Power-UP супроводжує мобільний маркетинг застосунків на Android та iOS від налаштування SDK до оптимізації кампаній під tCPA. Лишайте заявку на сайті: розберемо вашу аналітику і покажемо, де губляться дані.