Проблема: 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) val triggerUri = Uri.parse("https://your-ad-network.com/trigger") val triggerRequest = TriggerRequest.Builder(triggerUri).build() measurementManager.registerTrigger( triggerRequest, Executors.newSingleThreadExecutor() ) { outcomeReceiver -> // outcomeReceiver.result = true при успешной регистрации } } Триггер матчится с ранее зарегистрированным source на устройстве. Система сама решает, какой source к какому trigger отнести, и отправляет отчёт с задержкой. Согласно Google Developer Documentation, этот механизм гарантирует приватность без потери атрибуционных данных для рекламодателя.
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+ приложениях. Закажите интеграцию и обеспечьте бесшовный переход атрибуции.
Гарантия результата
Мы реализовали более 30 интеграций атрибуции для Android-приложений разного масштаба. Опыт с Privacy Sandbox — с момента запуска бета-версии. Настраиваем так, чтобы вы не потеряли данные при переходе и соблюдали требования Google Play. Все работы сопровождаются гарантией качества и технической поддержкой.