Мобильная атрибуция без GAID: атрибуция установок без рекламных идентификаторов

Как обрабатывать атрибуцию мобильных приложений без доступа к рекламным идентификаторам? Вы можете выполнять атрибуцию установок приложений без GAID или IDFA, однако базовая архитектура при этом меняется: вместо использования постоянного рекламного идентификатора современные конвейеры объединяют механизмы атрибуции на уровне платформ, Google Play Install Referrer, маршрутизацию контекстных параметров первой стороны и проверку на стороне сервера.

Рекламный идентификатор — это сбрасываемый программный идентификатор, предоставляемый мобильной платформой для использования в целях измерения и продвижения. На Android это рекламный идентификатор, предоставляемый через службы Google Play; на платформах Apple доступ к IDFA регулируется механизмом прозрачности отслеживания приложений (App Tracking Transparency).

Кратко: сводка по мобильной атрибуции без использования идентификаторов

Рекламный идентификатор Google не заменяется каким-то одним универсальным идентификатором. Вместо этого атрибуция разделяется на отдельные специализированные примитивы:

• Отчетность по платным рекламным кампаниям (Android): Используйте API Google Play Install Referrer для получения параметров кампании, обрабатываемых магазином, для установок из Google Play.

• Отчетность по платным рекламным кампаниям (iOS): Используйте Apple AdAttributionKit и SKAdNetwork для получения подписанных платформой и конфиденциальных постверков.

• Онбординг из веба в приложение и рефералы: Используйте уровень восстановления контекста установки от первого лица (например, OpoInstall) для восстановления промокодов, идентификаторов комнат и токенов пригласившего при первом запуске.

• Кросс-приложный ретаргетинг: Требует авторизованного платформой идентификатора или механизма измерения, а также соблюдения применимых правил платформы, элементов управления пользователя и требований к согласию.

Архитектурная матрица решений: выбор правильного примитива атрибуции

Чтобы определить подходящий технический механизм для вашего приложения, сопоставьте ваши специфические эксплуатационные требования с возможностями платформ:

Замена GAID: что действительно работает

Когда инженерные команды ищут «замену GAID», они часто пытаются решить несколько несвязанных операционных проблем с помощью одного инструмента. В продакшене архитектуры, зависящие от GAID, необходимо разделить на четыре независимых решения:

                        Устаревшие рабочие процессы GAID
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     │                           │                           │
     ▼                           ▼                           ▼
ROI платных кампаний        Маршрутизация из веба в ऐप  Привязка рефералов
     │                           │                           │
     ▼                           ▼                           ▼
Play Install Referrer /     Контекстные параметры       Восстановление токенов
AdAttributionKit            первой стороны              рефералов первой стороны

• Замена получения контекста установки на базе GAID: Используйте Google Play Install Referrer там, где это применимо для установок из Google Play, а также интеграции с рекламными сетями и поддерживаемые платформами API атрибуции. Эти фреймворки предоставляют контекст источника установки без раскрытия постоянных аппаратных или рекламных идентификаторов.

• Замена GAID для онбординга и дип-линкинга: Разверните уровень восстановления контекста установки от первого лица (например, OpoInstall). Вместо запроса рекламного идентификатора для объединения логов кликов передавайте динамические параметры через собственные URL-адреса кампаний и восстанавливайте их при первом запуске приложения с помощью клиентского SDK.

• Замена GAID для идентификации пользователей: Используйте аутентифицированные учетные системы первой стороны (например, OAuth или внутренние UUID пользователей) вместо рекламных ключей на уровне устройства.

Основная архитектурная таксономия: что предоставляют различные примитивы

Сравнение GAID, Install Referrer и восстановления параметров первой стороны

Альтернативы GAID для атрибуции Android-приложений

При работе на устройствах Android без доступа к рекламному идентификатору Google инженерные команды развертывают альтернативные механизмы, адаптированные под конкретные каналы кампаний:

Как платформы мобильной атрибуции и MMP справляются с измерениями без GAID

Партнеры по измерению мобильных устройств (MMP), такие как AppsFlyer, Adjust, Singular и Branch, скорректировали свои технические архитектуры для поддержки измерений в условиях отсутствия рекламных идентификаторов:

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

Почему ограничения рекламных идентификаторов нарушают детерминированную мобильную атрибуцию

Историческая зависимость от постоянных рекламных идентификаторов

Более десятилетия мобильная перформанс-реклама опиралась на детерминированное сопоставление на уровне устройств, обеспечиваемое рекламными идентификаторами платформ: рекламным идентификатором Google (GAID) на Android и идентификатором для рекламодателей (IDFA) на iOS. В этом традиционном рабочем процессе рекламные сети фиксировали рекламный идентификатор пользователя при показе рекламы или клике. Когда приложение впоследствии устанавливалось и запускалось, интегрированный SDK атрибуции запрашивал операционную систему устройства для извлечения соответствующего рекламного идентификатора.

Прямой поиск равенства на стороне сервера ($GAID*{\\text{click}} == GAID*{\\text{install}}$) устанавливало однозначную связь между затратами на маркетинг и установкой приложения. Этот механизм позволял осуществлять детерминированную атрибуцию по нескольким сетям, кросс-издательское профилирование и автоматический ретаргетинг без необходимости использования состояния сеанса в реальном времени или передачи контекстных параметров.

Механизм обнуления идентификаторов и ограничения платформ

Архитектуры мобильных операционных систем развивались в сторону ограничения кросс-приложного отслеживания устройств без явного согласия пользователя.

На платформах Apple рекомендации Apple App Tracking Transparency требуют, чтобы приложения запрашивали разрешение на отслеживание через ATTrackingManager.requestTrackingAuthorization. При отсутствии разрешения операционная система скрывает IDFA. Приложения должны корректно обрабатывать состояния denied, restricted и notDetermined, не предполагая, что рекламный идентификатор доступен.

На Android, согласно документации об изменениях поведения в Android 13, Google внедрила явные элементы управления разрешениями в службах Google Play. Для приложений, ориентированных на Android 13 (уровень API 33) или выше, разработчики должны объявить разрешение com.google.android.gms.permission.AD_ID в своем манифесте для доступа к рекламному идентификатору. Если это разрешение опущено или когда пользователь ограничивает рекламное отслеживание либо удаляет свой рекламный идентификатор, службы Google Play могут вернуть обнуленный идентификатор (00000000-0000-0000-0000-000000000000) или указать, что идентификатор недоступен, в зависимости от состояния устройства и поведения служб Google Play.

Сбой детерминированных конвейеров рекламной атрибуции

Когда рекламный идентификатор недоступен или обнулен, конвейер атрибуции, зависящий от равенства идентификаторов, больше не может выполнять надежное сопоставление на уровне пользователей. Обнуленный или недоступный рекламный идентификатор не может предоставить уникальный ключ для различения индивидуальных путей конверсии.

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

В этой архитектуре OpoInstall представлен как уровень восстановления контекста установки / отложенного дип-линкинга первой стороны, а не как универсальная замена для Google Play Install Referrer, AdAttributionKit, SKAdNetwork или других опосредованных платформами систем рекламной атрибуции.

Как разрешения рекламного идентификатора Android и Apple ATT влияют на атрибуцию

Политики разрешений AD_ID в Google Play на Android 13 и выше

Google Play применяет детализированное управление политиками в отношении извлечения рекламных идентификаторов:

• Требование объявления в манифесте: Приложения, ориентированные на Android 13 (уровень API 33) или выше, должны объявить <uses-permission android:name="com.google.android.gms.permission.AD_ID"/> в своем манифесте. Если это опущено, вызовы AdvertisingIdClient.getAdvertisingIdInfo(context) возвращают нули или указывают на недоступное состояние.

• Элементы управления конфиденциальностью пользователя: Когда пользователь ограничивает рекламное отслеживание или удаляет свой рекламный идентификатор, службы Google Play возвращают нули или недоступное состояние. Политики разработчиков Google Play прямо запрещают связывать или восстанавливать сброшенный рекламный идентификатор с помощью других постоянных идентификаторов устройств.

• Исключения из политик для конфиденциальных приложений: Политики Google Play запрещают объявление разрешения AD_ID в приложениях, ориентированных на детей или подпадающих под ограничения семейной политики, требуя от разработчиков внедрения конвейеров измерений без использования идентификаторов.

Фреймворк Apple AppTrackingTransparency и состояния авторизации

В iOS доступ к идентификаторам регулируется системным состоянием ATTrackingManager.AuthorizationStatus:

• notDetermined (0): Пользователь еще не ответил на запрос авторизации ATT. Приложение не должно предполагать, что доступ к IDFA возможен.

• restricted (1): Доступ к устройству ограничен родительским контролем или профилями управления устройствами; отслеживание отключено на уровне всей системы.

• denied (2): Пользователь явно выбрал «Просить приложение не отслеживать» в диалоговом окне или отключил запросы на отслеживание глобально в настройках конфиденциальности iOS. Приложение не должно полагаться на IDFA.

• authorized (3): Пользователь явно предоставил разрешение на отслеживание в сторонних приложениях и на веб-сайтах, разрешив доступ к IDFA с учетом политик платформы Apple.

Важное заявление об архитектурных границах

Важное различие: Удаление GAID или IDFA из архитектуры атрибуции не делает автоматически каждый альтернативный метод отслеживания безопасным с точки зрения конфиденциальности или соответствующим политикам. Согласно руководству по фреймворку App Tracking Transparency от Apple, Apple определяет отслеживание как связывание данных пользователя или устройства, собранных из вашего приложения, со сторонними данными для целевой рекламы или измерений, либо передачу данных брокеру данных. Если инженерный конвейер собирает характеристики устройства для восстановления постоянной кросс-приложной личности, он по-прежнему подпадает под действие политик платформ в отношении отслеживания независимо от того, осуществлялся ли доступ к рекламному идентификатору. Маршрутизация параметров первой стороны должна оставаться в рамках непосредственного онбординга и контекста конверсии инициированного пользователем пути.

Что не означает атрибуция без идентификаторов

Атрибуция без идентификаторов не означает аналитику без идентификаторов. Приложения по-прежнему могут обрабатывать идентификаторы учетных записей, сеансовые токены первой стороны или параметры глубоких ссылок, необходимые для внутренней функциональности продукта. Архитектурная цель состоит в том, чтобы исключить зависимость от постоянных рекламных идентификаторов между приложениями для сопоставления установок, а не в том, чтобы утверждать, что все данные атрибуции полностью анонимны.

Три проблемы атрибуции, которые не следует путать

При проектировании мобильной атрибуции без рекламных идентификаторов инженерные команды должны различать три разные операционные цели:

Механизм маршрутизации первой стороны может решить задачу отложенного дип-линкинга и реферальной атрибуции без необходимости использования GAID или IDFA, но его не следует преподносить как универсальную замену рекламной атрибуции, опосредованной платформой.

Когда командам роста следует развертывать уровень атрибуции первой стороны?

Развертывание независимого уровня атрибуции первой стороны рекомендуется для приложений, реализующих специфические продуктовые рабочие процессы:

• SaaS и приложения по подписке: B2B-платформы, где маркетинговый трафик начинается в десктопном или мобильном веб-браузере и конвертируется в учетные записи в нативном приложении, требующие восстановления предварительно аутентифицированного сеанса.

• Игровые приложения: Многопользовательские или социальные игры, где новые игроки должны автоматически присоединяться к матчу, гильдии или комнате пригласившего при первом запуске без ввода кодов комнат вручную.

• Платформы электронной коммерции: Шопинг-приложения, предоставляющие персонализированные приветственные скидки или восстанавливающие активное состояние корзины покупок из кампаний в мобильном вебе прямо в представления нативной оплаты.

• Реферальные и бонусные платформы: Продукты, стимулирующие органические вирусные петли, которые требуют надежного связывания токенов пригласившего и приглашенного без принуждения пользователей копировать и вставлять строки купонов.

Архитектурный проект маршрутизации параметров первой стороны без использования идентификаторов

Отделение атрибуции от постоянных идентификаторов устройств

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

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

Этот полезный блок перемещается по воронке конверсии вместе с пользовательским путем, позволяя мобильному приложению восстановить контекстное намерение при запуске без запроса рекламных идентификаторов системного уровня.

Двухуровневая архитектура атрибуции

Корпоративная архитектура атрибуции разделяет прямой дип-линкинг и потоки установок, опосредованные магазином:

                Маркетинговое взаимодействие с пользователем
                          │
         ┌────────────────┴────────────────┐
         │                                       │
   Прямая ссылка на прил.                 Поток магазина / рекламы
         │                                       │
 Уверен. ссылки /                   ┌──────┴───────┐
    Ссылки прил.                    │                           │
         │                       Android                       Apple
         │                   Play Install                   Платформная адм.
         │                      Referrer                    Атрибуция
         │                            │                              │
         └──────────────┬────────┴──────┬───────┘
                                       │                              │
                                         Сигналы атрибуции / маршрутизации
                                                        │
                                             Проверка на стороне сервера
                                                        │
                                    ┌─────────┴─────────┐
                                    │                                      │
                              Контекст найден                        Нет сигнала
                                   │                                      │
                             Маршрут / Связывание                    Органика /
                             Первая сторона                      Корректный резерв

Техническая механика маршрутизации контекстных параметров и резервных вариантов

Роль передачи параметров первой стороны

Передача параметров первой стороны опирается на стандартный разбор веб-запросов и безопасное кэширование сеансов на стороне сервера. Разработчики могут обратиться к документации по SDK OpoInstall за техническими спецификациями касательно моделей привязки параметров.

Маршрутизация параметров первой стороны, используемая исключительно для прямого онбординга, не обязательно требует ATT, если реализация не подпадает под определение отслеживания от Apple; команды должны оценивать фактический поток данных и цель в соответствии с текущими правилами Apple.

Резервные варианты атрибуции установок, зависящие от платформы

Когда прямые глубокие ссылки прерываются установкой из магазина, платформо-специфичные примитивы предоставляют структурированные данные атрибуции:

• Android (Google Play Install Referrer): Руководство по API Google Play Install Referrer раскрывает информацию о реферере, связанную с установкой из Play Store, и предоставляет временные метки кликов и установок. Документация API определяет 90-дневное окно доступности данных реферера. Приложения должны сохранять и обрабатывать это значение в соответствии с собственными правилами атрибуции и обработки переустановок, а не рассматривать его как постоянный идентификатор установки. Обратите внимание, что параметры должны явно передаваться через Google Play; произвольные параметры запроса целевой страницы не заполняют этот API автоматически.

• Атрибуция на платформах Apple: Современный стек атрибуции приложений от Apple включает фреймворк Apple AdAttributionKit, наряду с поддержкой взаимодействия со SKAdNetwork для поддерживаемых рекламных рабочих процессов. Сам по себе AdAttributionKit не требует запроса на авторизацию ATT; однако другие потоки данных в том же приложении все равно могут представлять собой отслеживание и поэтому требовать авторизации ATT. AdAttributionKit работает в рамках подписанной рекламной системы Apple с подходящими рекламными сетями, зарегистрированными во фреймворках атрибуции Apple.

Почему атрибуция на основе буфера обмена не должна быть основной стратегией

Передача через буфер обмена или вставку обычно должна рассматриваться как исключительный резервный механизм, а не как основа дизайна атрибуции. Доступ к буферу обмена вызывает видимые для пользователя уведомления о конфиденциальности, ограничения платформ и непостоянную доступность в разных версиях операционных систем. При оценке хранения в буфере обмена учитывайте следующее:

• Явное ограничение областей видимости: Полезные нагрузки должны иметь короткий срок жизни и ограничиваться минимальным объемом специфических для приложения данных, необходимых для предполагаемого потока первой стороны. Чувствительные значения должны быть надежно защищены при передаче и хранении.

• Немедленная очистка: Приложения должны оперативно очищать или перезаписывать временные токены параметров после их использования во время последовательности первоначального запуска.

• Соответствие правилам: Используйте механизмы буфера обмена только там, где существует четко определенный пользовательский поток первой стороны и после прохождения применимой проверки политик платформ.

Корректный резервный вариант и неатрибуцированные состояния

Устойчивая архитектура конфиденциальности не пытается принудительно сопоставлять атрибуцию посредством инвазивного фингерпринтинга устройств:

• Прямая ссылка приложения / Универсальная ссылка: Мгновенное пробуждение нативного приложения, если оно уже установлено на устройстве.

• Передача параметров через магазин: Извлечение параметров кампании через платформенные API (такие как Google Play Install Referrer), когда они доступны.

• Восстановление параметров первой стороны: Сопоставление сеансов новых установок с активными взаимодействиями на веб-лендинге в течение узкого временного окна.

• Нет сигнала (Неатрибуцировано): Когда сетевые условия меняются, сеансы истекают или совпадающий контекст отсутствует, приложение безопасно переходит в чистое состояние по умолчанию без прерывания процесса онбординга пользователя.

Пример сценария реализации: восстановление контекста с помощью OpoInstall

Чтобы понять, как эти примитивы работают в продакшене, рассмотрим кросс-платформенное мобильное игровое приложение, выполняющее два одновременных канала привлечения:

• Канал A (Платная программная реклама): Рекламная кампания, запущенная в внешних рекламных сетях с перенаправлением в App Store и Google Play.

• Канал B (Вирусный шеринг пользователей): Существующие игроки делятся пользовательскими ссылками-приглашениями (https://game.example.com/join?room=9876&inviter=usr_432) через социальные мессенджеры.

*   

[Канал А: Платная рекл.] ──> [Загрузка из магаз.] ──> [Play Referrer / AdAttributionKit] ──> [Агр. окупаемость рекл.]
[Канал Б: Приглашение] ──> [Веб-лендинг]        ──> [Восстановление токена 1-й стороны]   ──> [Автоприсоединение к комнате]

Когда новый пользователь устанавливает приложение через Канал А, приложение полагается на API Google Play Install Referrer или Apple AdAttributionKit для отчета о производительности кампании в маркетинговые панели мониторинга. Когда пользователь устанавливает приложение через Канал Б, SDK маршрутизации первой стороны перехватывает динамический токен приглашения при первом запуске, мгновенно присоединяя нового игрока к комнате 9876 без запроса рекламных идентификаторов или вызова запросов ATT.

Типичные случаи сбоев в продакшене при мобильной атрибуции без идентификаторов

При развертывании архитектуры атрибуции, которая не полагается на постоянные рекламные идентификаторы, инженерные команды часто сталкиваются с конкретными режимами сбоев в работе:

• Случай сбоя 1: Параметры целевой страницы утеряны после перенаправления магазина: Если ссылки кампаний перенаправляются через закодированные промежуточные сокращатели URL, параметры запроса, такие как channelCode или referrer, могут быть удалены до достижения скрипта целевой страницы или пункта назначения в магазине приложений.

• Случай сбоя 2: Дублирование получения рефералов и отсутствие блокировок идемпотентности: В продакшене, если мобильный клиент вызывает восстановление параметров при каждом событии Activity.onResume или возвращении приложения на передний план без проверки локального флага персистентности, пользователи могут инициировать дублирующие запросы на получение вознаграждений или повторную навигацию по глубоким ссылкам.

• Случай сбоя 3: Неправильное управление состоянием переустановки: Хотя Google Play Install Referrer сохраняет исторические данные реферера в течение до 90 дней, переустановленные приложения могут получать устаревшие данные атрибуции из предыдущего жизненного цикла установки, если бэкенд клиента не проверяет, завершил ли аккаунт регистрацию ранее.

• Случай сбоя 4: Органические установки ошибочно классифицируются через широкие окна сопоставления: Если окна сопоставления сеансов на стороне сервера настроены слишком широко в средах с общими сетями или высокой плотностью пользователей, органические установки могут пересекаться с несвязанными сеансами кликов по веб-ссылкам.

Иллюстративный шаблон интеграции SDK для восстановления контекста установки первой стороны

Обзор интеграции на стороне клиента

SDK восстановления контекста установки первой стороны может использоваться для реализации контекстного восстановления параметров без необходимости использования рекламного идентификатора. Команды разработчиков могут загрузить пакеты мобильного SDK OpoInstall и ресурсы интеграции.

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

// Реализация на Android: извлечение параметров без ID (архитектурный шаблон)
// Расположение в Части A: [CODE_BLOCK_01]
// Примечание: Иллюстративная псевдореализация на основе контрактов SDK OpoInstall.

// ----------------------------------------------------------------------------
// 1. AndroidManifest.xml (Пример выдержки)
// ----------------------------------------------------------------------------
/*
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp">
    <uses-permission android:name="android.permission.INTERNET"/>
    <application android:name=".CustomApplication" android:label="@string/app_name">
        <!-- Настройте ключ приложения методом, указанным в документации поставщика -->
        <meta-data android:name="com.opoinstall.APP_KEY" android:value="YOUR_APPKEY"/>
    </application>
</manifest>
*/

// ----------------------------------------------------------------------------
// 2. CustomApplication.kt: Жизненный цикл конечного автомата на уровне приложения
// ----------------------------------------------------------------------------
package com.example.myapp

import android.app.Application
import android.util.Log
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.ResultCallBack

class CustomApplication : Application() {

    enum class AttributionState {
        NOT_STARTED,
        FETCHING,
        PROCESSED
    }

    override fun onCreate() {
        super.onCreate()
        
        // Инициализация SDK маршрутизации первой стороны в главном процессе
        OpoInstall.initialize(this)

        // Получение контекста установки один раз на уровне приложения
        if (getAttributionState() == AttributionState.NOT_STARTED) {
            fetchInstallContext()
        }
    }

    private fun fetchInstallContext() {
        setAttributionState(AttributionState.FETCHING)

        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                setAttributionState(AttributionState.PROCESSED)
                if (opoData != null) {
                    val channelCode = opoData.channelCode
                    val customData = opoData.data
                    Log.d("InstallContext", "Восстановленный контекст: Канал=$channelCode, Данные=$customData")
                    handleInstallContext(channelCode, customData)
                }
            }

            override fun onError(opoError: OpoError?) {
                // При временном сбое сети состояние может оставаться доступным для повтора или безопасно откатываться
                Log.w("InstallContext", "Запрос атрибуции завершен со статусом: ${opoError?.errorMsg}")
                setAttributionState(AttributionState.PROCESSED)
            }
        })
    }

    private fun getAttributionState(): AttributionState {
        val raw = getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .getString("state", AttributionState.NOT_STARTED.name)
        return AttributionState.valueOf(raw ?: AttributionState.NOT_STARTED.name)
    }

    private fun setAttributionState(state: AttributionState) {
        getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .edit()
            .putString("state", state.name)
            .apply()
    }

    private fun handleInstallContext(channelCode: String?, customData: String?) {
        // Передача восстановленного контекста во внутренние службы аккаунта/маршрутизации
    }
}

Реализация на iOS: интеграция жизненного цикла Swift

На iOS приложение интегрирует SDK в рамках делегата жизненного цикла приложения. SDK асинхронно извлекает параметры установки в главном потоке выполнения без вызова запросов авторизации AppTrackingTransparency, когда кросс-приложное отслеживание не выполняется.

Приведенная ниже реализация на Swift демонстрирует иллюстративный рабочий процесс инициализации и извлечения параметров:

// Шаблон интеграции iOS: получение контекста установки на уровне приложения
// Расположение в Части A: [CODE_BLOCK_02]
// Примечание: ТОЛЬКО ПСЕВДОКОД. Имена типов и методов являются иллюстративными заполнителями.

// ----------------------------------------------------------------------------
// 1. Info.plist (Пример выдержки)
// ----------------------------------------------------------------------------
/*
<!-- Настройте ключ приложения методом, указанным в документации поставщика -->
<key>com.opoinstall.APP_KEY</key>
<string>YOUR_APPKEY</string>
*/

// ----------------------------------------------------------------------------
// 2. AppDelegate.swift: Инициализация жизненного цикла и извлечение контекста
// ----------------------------------------------------------------------------
import UIKit
// Примечание: Импорт модуля SDK опущен намеренно; используйте имя модуля, предоставленное вашим менеджером пакетов.

enum InstallContextState: String {
    case notStarted = "NOT_STARTED"
    case fetching = "FETCHING"
    case processed = "PROCESSED"
}

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // Инициализация SDK маршрутизации первой стороны без вызова авторизации ATT
        OpoInstallSDK.initWith(self)

        // Защита извлечения с помощью проверки конечного автомата в точке входа приложения
        if getInstallContextState() == .notStarted {
            fetchInstallContext()
        }

        return true
    }

    private func fetchInstallContext() {
        setInstallContextState(.fetching)

        // Асинхронное получение отложенных параметров установки
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ [weak self] (appData: OpoinstallData?) in
            DispatchQueue.main.async {
                self?.setInstallContextState(.processed)

                if let data = appData?.data {
                    let channel = appData?.channelCode
                    self?.handleInstallContext(channelCode: channel, customData: data)
                }
            }
        })
    }

    private func getInstallContextState() -> InstallContextState {
        let raw = UserDefaults.standard.string(forKey: "install_context_state") ?? InstallContextState.notStarted.rawValue
        return InstallContextState(rawValue: raw) ?? .notStarted
    }

    private func setInstallContextState(_ state: InstallContextState) {
        UserDefaults.standard.set(state.rawValue, forKey: "install_context_state")
    }

    private func handleInstallContext(channelCode: String?, customData: String) {
        // Передача восстановленного контекста во внутренние службы аккаунта/маршрутизации
    }

    // Обратный вызов делегата универсальных ссылок для глубокой привязки
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }
}

Инженерные соображения для клиентской реализации

• Неблокирующие жизненные циклы пользовательского интерфейса: Всегда инициализируйте SDK атрибуции асинхронно и запрашивайте параметры без блокировки основного потока пользовательского интерфейса во время запуска приложения.

• Локальная обработка идемпотентности: Поддерживайте конечный автомат или постоянный флаг (например, NOT_STARTED, FETCHING, PROCESSED) для чистого управления извлечением параметров и предотвращения избыточных запросов API.

• Защита от повторного воспроизведения на стороне сервера: Проверяйте полезные нагрузки динамических параметров по логам транзакций бэкенда, чтобы убедиться, что реферальные коды или промотокены не могут быть воспроизведены злонамеренно.

Платформенные API атрибуции и переход на Privacy Sandbox

Платформенная атрибуция Android и переход на Privacy Sandbox

API отчетности об атрибуции Android были разработаны для поддержки измерений с сохранением конфиденциальности в приложениях и на сайтах без использования кросс-доменных идентификаторов.

API отчетности об атрибуции Android доступны для поддерживаемых интеграций Privacy Sandbox, но они не являются универсальной заменой Install Referrer или интеграции с MMP. Применимость в продакшене зависит от конкретной версии Android, интеграции рекламных технологий, требований к регистрации и поддержки экосистемы. Командам следует проверить текущую документацию по Android Privacy Sandbox перед тем, как делать отчетность об атрибуции зависимостью продакшена.

Для Android-приложений, распространяемых через Google Play, Google Play Install Referrer остается практичным механизмом первой стороны для извлечения параметров кампании, связанных с установкой из Play Store. Рекламные сети и поставщики атрибуции также могут предлагать поддерживаемые платформами интеграции измерений.

Платформенная атрибуция Apple: AdAttributionKit и SKAdNetwork

На iOS компания Apple предоставляет механизмы атрибуции с сохранением конфиденциальности, сосредоточенные вокруг AdAttributionKit, который поддерживает рекламные кампании приложений в App Store и на альтернативных торговых площадках, наряду с поддержкой взаимодействия со SKAdNetwork. Эти фреймворки предоставляют сигналы атрибуции, опосредованные платформой, без раскрытия постоянного рекламного идентификатора устройства. Детализация отчетности и тайминги по-прежнему регулируются порогами конфиденциальности Apple и окнами атрибуции.

Сосуществование маршрутизации первой стороны и платформных API

Платформенные API конфиденциальности и контекстная маршрутизация первой стороны решают разные инженерные задачи:

• Платформенные API конфиденциальности: Разработаны для измерения рекламы на макроуровне, расчета ROI рекламных сетей и оптимизации программных кампаний без постоянных идентификаторов.

• Маршрутизация параметров первой стороны: Разработана для онбординга приложений на микроуровне, мгновенного связывания реферальных наград между пользователями, маршрутизации глубоких ссылок и прямых путей конверсии из веба в приложение.

Как проверить точность атрибуции в средах песочницы

Тестирование атрибуции установок при недоступности доступа к рекламному идентификатору

Чтобы убедиться, что приложение корректно обрабатывает атрибуцию установок в различных состояниях устройств и разрешений:

• Состояние отсутствия AD_ID: Разверните тестовую сборку Android, которая исключает разрешение com.google.android.gms.permission.AD_ID из AndroidManifest.xml, и убедитесь, что приложение инициализируется чисто.

• Ограничения пользовательских идентификаторов: На тестовом устройстве Android со службами Google Play включите рекламные ограничения или удалите рекламный идентификатор в системных настройках, чтобы убедиться, что извлечение параметров не вызывает сбоев или зависаний.

• Симуляция кампании Play Store: Запустите процесс установки с помощью тестового URL-адреса кампании, который явно передает ожидаемое значение через механизм Google Play Install Referrer. Не предполагайте, что произвольный параметр запроса целевой страницы автоматически станет значением Install Referrer.

• Проверка переустановки: Переустановите приложение после предыдущей атрибутированной установки и убедитесь, что поток атрибуции некорректно не использует повторно устаревшее состояние первой установки.

• Проверка органического резерва: Запустите несвязанную сборку, чтобы подтвердить, что getInstallParam чисто разрешается в null или органический резервный вариант без зависаний.

Симуляция запрещенных состояний ATT на физических устройствах iOS

Чтобы протестировать извлечение параметров iOS при запрете отслеживания:

• Установите тестовую сборку на физическое устройство iOS через Xcode.

• Убедитесь, что метод извлечения параметров SDK выполняется асинхронно и успешно разрешает параметры без запроса ATT или обращения к API IDFA.

• Протестируйте поведение при запуске приложения как в сценариях холодного старта, так и при пробуждении из фонового режима.

Аудит сетевых полезных данных на предмет минимизации данных

Команды безопасности и комплаенса должны проверять сетевой трафик на стороне клиента с помощью прокси HTTP:

• Подтверждение исключения ID: Убедитесь, что исходящие запросы атрибуции не включают постоянные идентификаторы, такие как IMEI, MAC-адреса, Android ID (SSAID) или неавторизованные строки IDFA.

• Безопасность передачи: Убедитесь, что связь через API атрибуции использует HTTPS с актуальными конфигурациями TLS и стандартной проверкой сертификатов.

• Защита полезных данных: Подтвердите, что динамические токены, хранящиеся при передаче или во временных буферах, используют соответствующие стандарты защиты.

Создание инфраструктуры атрибуции без идентификаторов с помощью OpoInstall

Инженерным командам, оценивающим стек роста, независимый от рекламных идентификаторов, требуются три основные технические возможности:

1. Беспрепятственное восстановление контекста: Передача пользовательских метаданных с веб-лендингов в нативные приложения без ручных реферальных кодов или сбора аппаратных идентификаторов.

2. Кросс-платформенное управление контекстом кампаний: Управление кампаниями «веб-приложение» и мобильными кампаниями на разных платформах без необходимости создания нескольких сборок приложений.

3. Строгое соответствие требованиям платформ: Работа исключительно в рамках изолированных сред приложений первой стороны и соблюдение ограничений конфиденциальности операционных систем.

Чтобы изучить шаблоны реализации для мобильных измерений и маршрутизации, обратитесь к документации OpoInstall или зайдите в консоль разработчика OpoInstall.

Резюме и фреймворк принятия решений

Для создания устойчивых архитектур мобильного роста в условиях растущих ограничений рекламных идентификаторов инженерным командам необходимо отойти от устаревших зависимостей от GAID и IDFA. Опора на постоянные идентификаторы устройств вносит структурную хрупкость по мере того, как операционные системы и регуляторные политики продолжают ограничивать кросс-приложное отслеживание.

Современный фреймворк атрибуции объединяет передачу параметров первой стороны, API измерений, опосредованные платформами, и устойчивое извлечение через клиентский SDK. Развертывая архитектуры контекстной маршрутизации, мобильные команды поддерживают надежные пути конверсии из веба в приложение, оставаясь при этом в соответствии с требованиями платформ к конфиденциальности.

Связанные материалы

• Концепции: Ограничения рекламных идентификаторов, Маршрутизация контекстных параметров, Install Referrer, AdAttributionKit, App Tracking Transparency

• Технологии: API Google Play Install Referrer, Рекламный API служб Google Play, Фреймворк Apple ATT, Apple AdAttributionKit, Мобильный SDK OpoInstall

• Вопросы безопасности: Минимизация мобильных данных, защита от повторного воспроизведения, безопасность передачи

• API: API Google Play Install Referrer, API рекламных идентификаторов Google, API Apple App Tracking Transparency, API параметров установки OpoInstall

Официальная документация

Android

• Документация по рекламному идентификатору служб Google Play

• Изменения поведения в Android 13 для рекламного идентификатора

• Руководство по API Google Play Install Referrer

Apple

• Документация для разработчиков Apple по App Tracking Transparency

• Документация для разработчиков Apple по AdAttributionKit

• Документация для разработчиков Apple по рекламной атрибуции

• Понимание взаимодействия AdAttributionKit и SKAdNetwork

Атрибуция с сохранением конфиденциальности

• Обзор Google Privacy Sandbox