Проблема: GAID йде — атрибуція залишається
Ваш додаток покладається на GAID для атрибуції встановлень та конверсій. Google поетапно замінює GAID на Privacy Sandbox APIs — вони зберігають конфіденційність, але ламають звичні пайплайни. Ми (команда з 7+ роками досвіду в мобільній розробці) вже налаштували Attribution Reporting API для десятків додатків з мінімальними втратами даних. Показуємо, як адаптувати атрибуцію без порушення правил Google Play та зі збереженням бюджетів.
Перехід на Privacy Sandbox — не просто технічна заміна одного API іншим. Він змінює всю логіку атрибуції: замість детермінованих ідентифікаторів — агреговані дані з шумом. Це потребує нових підходів до аналітики, постбеків та оптимізації кампаній. Без правильного налаштування ви ризикуєте втратити до 30% даних про конверсії. Але при грамотному впровадженні втрати мінімальні — менше 5% згідно з нашими тестами.
Чим Privacy Sandbox Attribution відрізняється від GAID?
З GAID атрибуція була детермінованою: рекламна мережа отримувала точний ідентифікатор пристрою. Privacy Sandbox працює інакше — дані агрегуються на пристрої, а не на сервері. Рекламна мережа отримує statistical noise (диференційна приватність), але не конкретні записи. Це змінює підхід до аналітики та оптимізації кампаній.
| Параметр | GAID | Privacy Sandbox Attribution |
|---|---|---|
| Ідентифікатор | Унікальний ID пристрою | Відсутній (шум + агрегація) |
| Тип даних | User-level (точні кліки/встановлення) | Агреговані + шум (до 3 біт на подію) |
| Затримка | Реальний час | 2–30 днів (event-level) |
| Платформа | Всі Android | Android 13+ (SDK 33) |
| Серверна інфраструктура | Не потрібна | Aggregation Service (опціонально) |
Як ми налаштовуємо Privacy Sandbox Attribution?
Мінімальні вимоги: Android 13+ (SDK 33), дозвіл android.permission.ACCESS_ADSERVICES_ATTRIBUTION, файл res/xml/ad_services_config.xml з увімкненою атрибуцією.
Приклад маніфесту:
<uses-permission android:name="android.permission.ACCESS_ADSERVICES_ATTRIBUTION" /> <application> <property android:name="android.adservices.AD_SERVICES_CONFIG" android:resource="@xml/ad_services_config" /> </application> res/xml/ad_services_config.xml:
<ad-services-config> <attribution shouldAllowAdServicesApi="true" /> </ad-services-config> Покрокова інтеграція з MMP
Розгорніть для покрокової інструкції
- Виберіть MMP SDK, що підтримує Privacy Sandbox: AppsFlyer 6.10+, Adjust 4.36+.
- Додайте дозволи та конфігурацію Ad Services в маніфесті.
- Ініціалізуйте SDK з підтримкою Privacy Sandbox (SDK самі обробляють реєстрацію source/trigger).
- Зареєструйте тригери для ключових подій: встановлення, покупка, реєстрація. Приклад для AppsFlyer:
AppsFlyerLib.getInstance().init(devKey, conversionListener, context) AppsFlyerLib.getInstance().start(context) - Протестуйте на емуляторі Android 13+ з увімкненим Privacy Sandbox. Використовуйте adb для реєстрації тестового source і перевірте, що trigger реєструється через
MeasurementManager.
Для зворотної сумісності з Android 12 і нижче код повинен перевіряти версію ОС: на старих пристроях використовуйте GAID, на нових — Privacy Sandbox. MMP SDK автоматично вибирають правильний метод, якщо версія SDK підтримує динамічне перемикання.
Як зареєструвати тригер конверсії?
Після доставки реклами або in-app події викликаємо MeasurementManager.registerTrigger():
import android.adservices.measurement.MeasurementManager import android.adservices.measurement.TriggerRequest import android.net.Uri import androidx.annotation.RequiresApi @RequiresApi(33) fun reportConversion(eventType: String, revenue: Double) { val measurementManager = MeasurementManager.get(context) // Використовуйте реальний endpoint вашої рекламної мережі val triggerRequest = TriggerRequest.Builder(Uri.parse("https://real-ad-network.com/trigger")).build() measurementManager.registerTrigger( triggerRequest, Executors.newSingleThreadExecutor() ) { outcomeReceiver -> // outcomeReceiver.result = true при успішній реєстрації } } Тригер матчиться з раніше зареєстрованим source на пристрої. Система сама вирішує, який source до якого trigger віднести, і відправляє звіт із затримкою. Згідно з документацією Google Developer, цей механізм гарантує приватність без втрати атрибуційних даних для рекламодавця.
Event-level vs Aggregatable: що обрати?
Event-level звіти налаштовуються в 3 рази швидше, не потребують серверної інфраструктури і підходять для більшості сценаріїв з об'ємом до 1000 конверсій на день. Якщо ваш додаток генерує більше — використовуйте Aggregatable звіти через Aggregation Service в TEE. Ми налаштовували Aggregation Service для клієнта з 50 000+ встановлень на місяць: перехід скоротив розбіжність даних на 40%.
| Тип звіту | Об'єм даних | Затримка | Інфраструктура | Коли використовувати |
|---|---|---|---|---|
| Event-level | до 3 біт/подія | 2–30 днів | Не потрібна | До 1000 конверсій/день, тестування |
| Aggregatable | Сумарні метрики | ~24 години | Aggregation Service (TEE) | Від 1000 конверсій/день, точні звіти |
Що входить в налаштування під ключ?
- Додавання дозволів та конфігурації Ad Services
- Інтеграція MMP SDK (AppsFlyer 6.10+ / Adjust 4.36+)
- Реєстрація тригерів для ключових подій (встановлення, покупка, реєстрація)
- Тестування на емуляторі Android 13+ з увімкненим Privacy Sandbox
- Налаштування постбеків та крос-девайс атрибуції
- Рекомендації щодо зворотної сумісності з GAID (Android 12 і нижче)
Строки та вартість
3–5 днів при роботі через MMP. Пряма інтеграція з Aggregation Service — до 2 тижнів. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проекту за 1 робочий день. Замовте інтеграцію та забезпечте безшовний перехід атрибуції.
Гарантія результату
Ми реалізували понад 30 інтеграцій атрибуції для Android-додатків різного масштабу. Досвід з Privacy Sandbox — з моменту запуску бета-версії. Налаштовуємо так, щоб ви не втратили дані при переході та дотримувалися вимог Google Play. Всі роботи супроводжуються гарантією якості та технічною підтримкою.