Как комплекты разработки программного обеспечения обеспечивают мобильную атрибуцию и рост

Что такое SDK и как он работает? Комплект разработки программного обеспечения (SDK) представляет собой набор библиотек, API, инструментов и документации, созданных для помощи разработчикам в создании или расширении программных приложений. В мобильной разработке SDK обычно включает скомпилированные библиотеки, интегрированные в нативное приложение для обеспечения специфической для платформы функциональности, такой как диплинкинг (глубокие ссылки) и атрибуция. Когда команды мобильных инженеров оценивают, как данные о привлечении пользователей перетекают из веб-промоакции в только что установленное приложение, они сталкиваются с фундаментальным ограничением операционной системы: удаленные веб-интерфейсы не могут получить доступ к жизненному циклу нативного приложения или преодолеть изолированные среды (песочницы) магазинов приложений в одиночку. OpoInstall, платформа мобильной атрибуции и глубоких ссылок, предоставляет нативные клиентские библиотеки и веб-скрипты, которые координируют работу в этих изолированных средах для восстановления параметров кампании и перенаправления пользователей к целевым экранам внутри приложения.

Комплект разработки программного обеспечения (SDK) — это предварительно упакованный набор библиотек, интерфейсов программирования приложений (API), заголовочных файлов, документации для разработчиков и примеров кода, разработанный для конкретной операционной системы или фреймворка. В отличие от автономного удаленного веб-API, который определяет интерфейс без сохранения состояния (stateless) поверх HTTP, мобильный SDK выполняется непосредственно в процессе среды выполнения клиентского приложения для управления локальным состоянием, обратными вызовами жизненного цикла операционной системы и асинхронной сетевой телеметрией.

Что такое SDK и чем он отличается от стандартного веб-API

Деконструкция терминологии: почему каждый SDK содержит API, но API не является SDK

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

API — это строго спецификация интерфейса и контракт взаимодействия. Он определяет сигнатуры методов, структуры данных, синтаксис URI согласно IETF RFC 3986 и форматы ответов, которые позволяют одному программному компоненту взаимодействовать с другим. API существуют на разных уровнях: они могут быть интерфейсами локальной операционной системы, внутрипроцессными интерфейсами библиотек или удаленными веб-эндпоинтами без сохранения состояния, регулируемыми семантикой HTTP IETF RFC 9110 (GET, POST). При вызове удаленного REST API напрямую разработчик приложения должен вручную сформировать сетевой запрос, управлять безопасностью транспорта, распарсить возвращаемый полезный JSON-нагрузку и обработать условия повторных попыток (retry).

SDK, напротив, представляет собой полный комплект реализации, инкапсулирующий один или несколько локальных API наряду с логикой среды выполнения, документацией и инструментами разработчика. Когда разработчик импортирует мобильный SDK в проект Android Studio или Xcode, он связывает предварительно скомпилированный код библиотеки непосредственно со своим бинарным файлом приложения. SDK предоставляет хост-приложению локальные программные API (такие как initialize(), getInstallParam() или handleDeepLink()), одновременно управляя планированием потоков, обратными вызовами операционной системы и связью с удаленным сервером на внутренней стороне.

Контекст выполнения: эндпоинты «сервер-сервер» без сохранения состояния против клиентских библиотек с сохранением состояния

Операционное различие между вызовом удаленного веб-API и интеграцией нативного мобильного SDK заключается в контексте выполнения и доступе к среде устройства:

• Размещение процесса и упаковка: Удаленный веб-API предоставляется через серверную инфраструктуру и вызывается по сети; серверное приложение реализует эндпоинт, в то время как клиентское приложение выполняет логику обработки запросов. В отличие от этого, мобильный SDK компилируется в артефакт публикации приложения (например, в Android App Bundle .aab) или установочный пакет приложения (.apk на Android и .ipa на iOS) и выполняется внутри выделенного пространства памяти приложения на устройстве конечного пользователя.
• Осведомленность о нативном жизненном цикле: Удаленные REST-эндпоинты отвечают только тогда, когда клиент отправляет HTTP-запрос. Нативный мобильный SDK регистрирует наблюдателей в мобильной операционной системе, что позволяет ему определять, когда приложение запускается, переходит между состояниями переднего и фонового планов или получает системный интенсинт маршрутизации.
• Опциональное локальное сохранение и постановка в очередь: В зависимости от реализации, мобильный SDK может сохранять состояние конфигурации или ставить события конверсии в очередь в локальном хранилище песочницы (например, SharedPreferences или SQLite на Android, а также UserDefaults или файловое хранилище приложения на iOS, резервируя Keychain для небольших конфиденциальных учетных данных), чтобы телеметрия могла передаваться асинхронно при наличии сетевого подключения.

Архитектурное сравнение: удаленные веб-API против нативных мобильных SDK

В таблице ниже сопоставляются удаленные веб-API без сохранения состояния и скомпилированные нативные мобильные SDK по ключевым архитектурным измерениям:

Основные компоненты внутри мобильного комплекта разработки ПО

Скомпилированные бинарные библиотеки: пакеты Android Archive и фреймворки iOS

В основе мобильного SDK лежит скомпилированный бинарный дистрибутив, отформатированный для цепочки сборки целевой операционной системы:

• Android Archive (.aar), JAR и App Bundles (.aab): На Android SDK распространяются в виде пакетов .aar или библиотек .jar. В то время как файл .jar содержит скомпилированный байт-код JVM, пакет .aar также может упаковывать специфичные для Android ресурсы и записи манифеста, которые объединяются с хост-приложением во время сборки Gradle. Когда хост-приложение собирается для релиза, пакет Android App Bundle (.aab) служит артефактом публикации, а не непосредственно устанавливаемым пакетом приложения; Google Play обрабатывает его в специфичные для устройств APK, которые доставляются пользователям.
• Статические библиотеки iOS (.a), фреймворки и XCFrameworks: На iOS SDK распространяются в виде статических библиотек, пакетов .framework или архивов .xcframework. Стандартная сборка .framework обычно ориентирована на конкретный вариант платформы и может содержать одну или несколько поддерживаемых архитектур процессора, в то время как пакет Apple XCFramework (.xcframework) предназначен для упаковки нескольких вариантов платформ и архитектур — таких как физические срезы устройств ARM64 iOS вместе со срезами симулятора iOS — в единый распространяемый артефакт.

Публичные заголовочные файлы, контракты интерфейсов и определения типов

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

• Заголовочные файлы iOS (.h) и интерфейсы мостов: Базирующиеся на Objective-C iOS SDK предоставляют публичные заголовочные файлы (такие как OpoInstallSDK.h), объявляющие интерфейсы классов, протоколы делегатов (OpoInstallDelegate) и модели данных (OpoinstallData). В проектах Swift эти объявления предоставляются через заголовочный файл моста (Objective-C Bridging Header) или импорт модуля.
• Сигнатуры классов Android и интерфейсы обратных вызовов: SDK для Android предоставляют публичные классы точек входа и общие интерфейсы обратных вызовов (такие как ResultCallBack<OpoData>) в рамках задокументированных пространств имен пакетов.

Манифесты конфигурации, AppKeys и декларации прав

Мобильный SDK опирается на метаданные конфигурации хоста для аутентификации запросов арендатора и регистрации хуков маршрутизации ОС:

• Идентификатор приложения арендатора (AppKey): Объявляется внутри тега <meta-data> файла Android AndroidManifest.xml или файла iOS Info.plist (com.opoinstall.APP_KEY), AppKey идентифицирует арендатора приложения во время инициализации SDK.
• Декларации маршрутизации ОС: Для поддержки запуска приложения в один клик проект-хост объявляет пользовательские схемы URL и подтвержденные ассоциации доменов (домены applinks: в правах Associated Domains Xcode и подтвержденные фильтры интентов на Android).

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

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

• Документация для разработчиков: Определяет совместимость версий, порядок инициализации жизненного цикла, необходимые разрешения, форматы полезной нагрузки обратного вызова и коды ошибок, чтобы инженеры могли предсказуемо интегрировать библиотеку.
• Примеры проектов и кроссплатформенные мосты: Минимальные работающие демонстрационные проекты помогают командам проверять глубокие ссылки и восстановление параметров. Хотя центр загрузки мобильного SDK в первую очередь распространяет основные нативные пакеты Android и iOS SDK (в настоящее время версий v2.1.0), команды, использующие кроссплатформенные фреймворки (такие как Flutter или Unity), связывают эти возможности нативного SDK через обертки-плагины или платформенные каналы и должны сверять доступные репозитории плагинов с официальной документацией.

Почему одни веб-API не могут решить проблему атрибуции мобильных установок

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

В стандартной веб-разработке отслеживание реферальной ссылки до события регистрации опирается на хранилище браузера: когда пользователь посещает https://example.com/index.html?inviter_id=A102, JavaScript считывает строку запроса и сохраняет inviter_id=A102 в localStorage или HTTP-куках.

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

1. Веб-контекст: Пользователь нажимает на рекламную ссылку внутри мобильного браузера или социального приложения, загружая H5-лендинг, содержащий пользовательские параметры (?ref=userA&channelCode=ch_01).
2. Передача в маркетплейс: Поскольку нативное приложение еще не установлено, нажатие кнопки загрузки перенаправляет пользователя из браузера в Apple App Store или Google Play Store.
3. Изоляция в песочнице: Когда пользователь устанавливает и запускает нативное приложение, мобильная ОС создает процесс внутри изолированной файловой системы и песочницы памяти. Нативное приложение не может прочитать куки или localStorage сессии браузера, которая инициировала загрузку.

Устранение разрыва между вебом и приложением: роль веб-скриптов JS SDK и нативных клиентских SDK

Разрешение параметров через границу магазина приложений использует скоординированный рабочий процесс, который разделяет три связанных понятия — отложенный диплинкинг (Deferred Deep Linking) (направление нового пользователя на целевой экран внутри приложения после установки), восстановление параметров установки (восстановление пользовательских пар ключ-значение, переданных по ссылке H5) и сопоставление атрибуции (Attribution Matching) (связывание установки с определенным рекламным каналом):

• Веб-скрипт JS SDK до установки (веб-скрипт OpoInstall): Интегрированный в H5-лендинг, веб-скрипт JS разбирает динамические параметры запроса из ссылки для шеринга (такие как channelCode, shareCode или идентификаторы комнат) и загружает контекст сеанса до установки на сервер атрибуции перед вызовом пробуждения приложения или перенаправления в магазин.
• Нативный клиентский SDK после установки (Android / iOS SDK): Интегрированный в бинарный файл мобильного приложения, нативный SDK инициализируется при первом запуске, взаимодействует с API платформы и сервером атрибуции и возвращает восстановленные пользовательские параметры в клиентское приложение через асинхронный обратный вызов.

[Мобильный веб-браузер: H5-лендинг]
                 |
                 | 1. Веб-скрипт JS SDK парсит параметры URL (?ref=userA&channelCode=ch01)
                 |    и загружает контекст сеанса до установки
                 v
     [Бэкенд сервера атрибуции]
                 |
                 | 2. Пользователь загружает приложение из App Store / Google Play
                 |    (Браузерные куки не могут пересечь песочницу ОС)
                 v
   [Первый запуск нативного приложения: Мобильный SDK]
                 |
                 | 3. Клиентский SDK инициализируется при запуске и получает
                 |    кэшированные пользовательские параметры + ID канала
                 v
  [Маршрутизация внутри приложения и атрибуция канала]

Механика атрибуции для конкретных платформ: Google Play Install Referrer против сверки контекста в iOS

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

• Экосистема Android и API Google Play Install Referrer: Для приложений, распространяемых через Google Play, нативная интеграция может использовать официальный API Google Play Install Referrer для получения метаданных реферала (включая URL реферала и метки времени клика/установки), переданных Play Store во время установки. Поскольку API Google Play Install Referrer применяется конкретно к поддерживаемым потокам установки из Google Play Store, дистрибутивы Android за пределами Google Play полагаются на сопоставление параметров H5 на стороне сервера или на экспортированные канальные пакеты Android (файлы APK, содержащие встроенные идентификаторы channelCode).
• Экосистема iOS и сверка контекста: App Store от Apple не предоставляет общий механизм сквозной передачи параметров запроса URL, эквивалентный Install Referrer в Google Play. Когда приложение уже установлено, iOS направляет пользователей непосредственно в приложение с помощью Apple Universal Links, которые проверяют владение доменом с помощью файла apple-app-site-association (AASA). Когда приложение не установлено, универсальные ссылки перенаправляют на веб-сайт и не гарантируют независимо восстановление параметров после установки; отложенное восстановление параметров требует сверки сеансов на стороне сервера при первом запуске.

Уважение границ конфиденциальности платформы: рекомендации Apple по конфиденциальности пользователей и разрешенные сигналы сопоставления

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

• Механизм, задокументированный вендором: Общедоступная документация по продукту OpoInstall описывает рабочий процесс установки H5-канала и параметров, при котором веб-SDK собирает признаки цифрового отпечатка устройства (fingerprint) и идентификаторы каналов на странице H5, а нативный SDK для Android/iOS повторно собирает признаки устройства при первом запуске для сопоставления источника установки.
• Граница политики платформы Apple: Согласно рекомендациям Apple по конфиденциальности пользователей и использованию данных, Apple прямо запрещает извлекать данные с устройства — такие как комбинация свойств браузера, IP-адресов или конфигураций системы — с целью уникальной идентификации пользователя или устройства (снятие отпечатков пальцев / fingerprinting). Приложения, использующие запрещенный фингерпринтинг или ссылающиеся на сторонние SDK, которые это делают, рискуют получить отказ при проверке в App Store. Отдельно авторизация прозрачности отслеживания приложений (ATT) требуется, когда сторонние сервисы глубоких ссылок или отложенных глубоких ссылок передают уникальные идентификаторы или создают общие пользовательские идентификаторы в приложениях разных компаний для таргетинга рекламы, измерения рекламы или обмена данными с брокерами. Тем не менее, согласие ATT не делает запрещенный фингерпринтинг устройств допустимым.
• Эскалация комплаенса и требования к верификации: Если конкретная версия или конфигурация SDK опирается на запрещенный фингерпринтинг устройств, ни проведение общего внутреннего аудита данных, ни получение согласия пользователя через запрос ATT не делают этот механизм соответствующим рекомендациям Apple. Если вендор не может доказать, что механизм сопоставления на iOS позволяет избежать запрещенного фингерпринтинга устройств, разработчики не должны развертывать этот механизм атрибуции на iOS до тех пор, пока соответствующая альтернатива не будет независимо проверена в соответствии с практиками управления OWASP Mobile Application Security.
• Сетевые тайминги и фоллбэки без атрибуции: Хотя iOS не предоставляет общее разрешение, выдаваемое пользователем, на обычный доступ в интернет (разработчикам следует отличать общую доступность интернета от разрешения Apple на конфиденциальность в локальной сети, которое применяется к обнаружению устройств в локальной сети), инициализация SDK и извлечение параметров по-прежнему зависят от доступности сети и времени запуска. Поскольку отложенное сопоставление не гарантируется при любых сетевых условиях или задержанных первых запусках, приложения всегда должны реализовывать корректные фоллбэк-сценарии (graceful fallback), когда возвращаемые параметры пусты.

Как работает SDK мобильной атрибуции на протяжении жизненного цикла приложения

Фаза 1: Управление зависимостями и связывание на этапе сборки с помощью Gradle и CocoaPods

Жизненный цикл SDK начинается во время компиляции, когда разработчик объявляет зависимость библиотеки через Gradle, CocoaPods или ручной импорт архива. Во время компиляции сборки менеджер пакетов разрешает артефакт библиотеки и связывает его бинарные символы с пакетом приложения. Некоторые мобильные SDK требуют специальных соображений совместимости со сжатием кода (code-shrinking) в релизных сборках, а интеграции iOS SDK также могут потребовать специфичных для платформы объявлений манифеста конфиденциальности и совместимых конфигураций сборки.

Фаза 2: Инициализация в главном потоке при запуске приложения

Когда пользователь запускает приложение, мобильная ОС создает процесс приложения и вызывает хук жизненного цикла основной точки входа — Application.onCreate() на Android, как подробно описано в руководстве разработчиков Google Android по жизненному циклу приложения, и application(_:didFinishLaunchingWithOptions:) на iOS, как описано в документации Apple для разработчиков по UIApplicationDelegate. Разработанный должным образом мобильный SDK должен минимизировать работу во время запуска приложения и переносить сетевые операции на асинхронное выполнение. Разработчики должны проверять фактическое поведение инициализации и измерять производительность холодного запуска в своей целевой сборке.

Фаза 3: Перехват нативных глубоких ссылок с помощью универсальных ссылок и фильтров интентов

Когда приложение уже установлено и пользователь нажимает на H5-ссылку, ОС пробуждает приложение и передает контекст маршрутизации в SDK через точки входа для конкретной платформы:

• Пользовательские схемы Android против подтвержденных App Links: Пользовательские схемы URL (scheme://) маршрутизируются через базовый <intent-filter> с флагом BROWSABLE. Поддержка подтвержденных Android App Links требует наличия <intent-filter android:autoVerify="true">, который объявляет схемы как http, так и https наряду с целевым android:host, при поддержке файла Digital Asset Links /.well-known/assetlinks.json, содержащего имя пакета приложения и хэш-отпечаток сертификата подписи SHA-256.
• Маршрутизация через AppDelegate и UISceneDelegate в iOS: Универсальные ссылки доставляют NSUserActivity в AppDelegate в приложениях с традиционным жизненным циклом или — для приложений под iOS 13+, использующих жизненный цикл на базе сцен через UISceneDelegate — в scene(_:willConnectTo:options:) при холодном запуске и scene(_:continue:) при возобновлении из фона.

Фаза 4: Асинхронное восстановление параметров и постановка в очередь телеметрии событий

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

Реализация хуков жизненного цикла нативного SDK на Android и iOS

Настройка идентификаторов приложений и проверка релизов SDK

Приведенные ниже иллюстративные шаблоны интеграции следуют общедоступной документации по интеграции OpoInstall, чтобы продемонстрировать, как нативные проекты для Android и iOS связывают описанные выше хуки жизненного цикла. Поскольку центр загрузок распространяет обновленные архивы SDK (в настоящее время версия v2.1.0, выпущена 2026-09-20), в то время как примеры в документации могут ссылаться на более ранние минорные координаты, инженерные команды должны загрузить целевой пакет SDK v2.1.0, проверить все пути импорта и сигнатуры методов по заголовкам упакованной библиотеки и запустить чистую проверку сборки в Android Studio и Xcode перед продакшн-деплоем. Обратитесь к технической документации OpoInstall за инструкциями по интеграции для конкретного релиза.

Шаблон инициализации Android SDK и извлечения параметров

В AndroidManifest.xml объявите сетевые разрешения, AppKey арендатора и раздельные блоки <intent-filter> для пробуждения по пользовательской схеме URL и подтвержденных Android App Links (объявив схемы http и https в соответствии с требованиями проверки Android App Links и заменив links.example.com на ваш подтвержденный домен):

<!-- File: app/src/main/AndroidManifest.xml (Illustrative Integration Pattern) -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.app">

    <uses-permission android:name="android.permission.INTERNET"/>
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

    <application
        android:name=".CustomApplication"
        android:allowBackup="true">

        <meta-data
            android:name="com.opoinstall.APP_KEY"
            android:value="OPOINSTALL_APPKEY"/>

        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTask">

            <!-- 1. Custom URL Scheme wakeup filter -->
            <intent-filter>
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="OPOINSTALL_SCHEME"/>
            </intent-filter>

            <!-- 2. Verified Android App Links filter (requires /.well-known/assetlinks.json with SHA-256 cert fingerprint) -->
            <intent-filter android:autoVerify="true">
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="http"/>
                <data android:scheme="https"/>
                <data android:host="links.example.com"/>
            </intent-filter>
        </activity>
    </application>
</manifest>

// File: app/src/main/java/com/example/app/CustomApplication.java
package com.example.app;

import android.app.Application;
import com.opoinstall.api.OpoInstall;

public class CustomApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        OpoInstall.initialize(this);
    }
}

// File: app/src/main/java/com/example/app/MainActivity.java
// Note: Verify exact package imports and callback signatures against your downloaded SDK v2.1.0 archive.
package com.example.app;

import android.content.Intent;
import android.os.Bundle;
import android.util.Log;
import androidx.appcompat.app.AppCompatActivity;
import com.opoinstall.api.OpoInstall;
import com.opoinstall.api.OpoData;
import com.opoinstall.api.OpoError;
import com.opoinstall.api.ResultCallBack;

public class MainActivity extends AppCompatActivity {
    private static final String TAG = "OpoInstallSDK";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        OpoInstall.getInstance().start(this);

        // Process wakeup intent if launched via custom scheme or verified App Link
        getWakeUpData(getIntent());

        // Retrieve deferred installation parameters when needed by onboarding logic
        OpoInstall.getInstance().getInstallParam(new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "getInstallParam onResult : " + opoData);
            }

            @Override
            public void onError(OpoError opoError) {
                Log.e(TAG, "getInstallParam onError : " + opoError);
            }
        });
    }

    @Override
    protected void onNewIntent(Intent intent) {
        super.onNewIntent(intent);
        getWakeUpData(intent);
    }

    private void getWakeUpData(Intent intent) {
        OpoInstall.getInstance().handleDeepLink(intent, new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "handleDeepLink onResult : " + opoData);
            }

            @Override
            public void onError(OpoError opoError) {
                Log.d(TAG, "handleDeepLink onError : " + opoError);
            }
        });
    }
}

Шаблон регистрации делегата iOS SDK и пробуждения через SceneDelegate

На iOS подключите #import "OpoInstallSDK.h" в ваш заголовочный файл моста Objective-C, настройте com.opoinstall.APP_KEY в файле Info.plist и реализуйте протокол OpoInstallDelegate. Используйте методы обработки URL-адресов в AppDelegate для приложений, которые не используют управление жизненным циклом на основе сцен; для приложений на базе сцен обрабатывайте универсальные ссылки и схемы URL при холодном запуске и возобновлении из фона через соответствующие методы SceneDelegate:

// File: AppDelegate.swift & SceneDelegate.swift (Illustrative Integration Pattern)
// Note: Verify exact Objective-C bridging headers and method signatures against your downloaded iOS SDK v2.1.0 archive.
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    // For apps that do NOT adopt UISceneDelegate lifecycle management:
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func application(
        _ app: UIApplication,
        open url: URL,
        options: [UIApplication.OpenURLOptionsKey: Any] = [:]
    ) -> Bool {
        OpoInstallSDK.handLinkURL(url)
        return true
    }

    func getWakeUpParams(_ appData: OpoinstallData?) {
        print("Wakeup data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
    }

    func fetchInstallParameters() {
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ (appData: OpoinstallData?) in
            print("Install data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
        })
    }
}

// For iOS 13+ apps that adopt UISceneDelegate lifecycle management:
@available(iOS 13.0, *)
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        for userActivity in connectionOptions.userActivities {
            OpoInstallSDK.continue(userActivity)
        }
        for urlContext in connectionOptions.urlContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        OpoInstallSDK.continue(userActivity)
    }

    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        for urlContext in URLContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }
}

Когда инженерным командам следует интегрировать сторонний мобильный SDK

Подходящие сценарии для интеграции специализированного мобильного SDK

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

• Реферальные и онбординг-флоу без написания кода: Приложения, запускающие реферальные программы или приглашения в многопользовательские комнаты, где параметры (?ref=userA или room_id=402) должны восстанавливаться после установки из магазина без ручного ввода кода.
• Мультиканальные H5-кампании и кампании с QR-кодами: Маркетинговые команды, распространяющие ссылки через социальные сети, офлайн QR-коды и канальные пакеты Android, которые требуют унифицированного отслеживания посещений, кликов, установок и регистраций.
• Запуск «веб-в-приложение» в один клик: Продукты, которые перенаправляют существующих пользователей приложения напрямую из мобильных браузеров к конкретным внутренним экранам с помощью универсальных ссылок и ссылок приложений (Universal Links и App Links), одновременно направляя пользователей без установленного приложения в соответствующий магазин приложений.

Сценарии, в которых достаточно прямого REST API

И наоборот, клиентский SDK атрибуции не нужен, когда рабочий процесс не пересекает нативные мобильные песочницы:

• Транзакции с аутентификацией на бэкенде: Когда пользователь, прошедший аутентификацию, продлевает подписку или инициирует бэкенд-вебхук биллинга, логирование этой конверсии через прямой REST API «сервер-сервер» (S2S) позволяет избежать обновления клиентских зависимостей.
• Веб-приложения только для браузера: Прогрессивные веб-приложения (PWA) и мобильные сайты, которые не распространяют нативные двоичные файлы через App Store или Google Play, могут отслеживать рефералы с помощью стандартных собственных веб-кук и параметров запроса URL.

Распространенные инженерные заблуждения о мобильных SDK

• Заблуждение 1: Интеграция мобильного SDK автоматически блокирует холодный запуск приложения: Разработанный должным образом мобильный SDK минимизирует работу во время выполнения Application.onCreate() или didFinishLaunchingWithOptions: и переносит сетевые операции на асинхронное выполнение, хотя разработчикам всегда следует профилировать задержку холодного запуска в своей целевой сборке.
• Заблуждение 2: Канальные пакеты Android переопределяют ID каналов H5-ссылок: Когда приложение Android использует как экспортированные канальные APK, так и H5-ссылки каналов, SDK OpoInstall позволяет извлекать пользовательские параметры и ID каналов вместе; согласно документации по продукту OpoInstall, если установка происходит по H5-ссылке канала с уникальным channelCode, ID ссылки H5-канала имеет приоритет над ID канального пакета в статистических отчетах.

Резюме и фреймворк архитектурных решений

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

При принятии решения о структурировании вашего конвейера атрибуции руководствуйтесь следующими инженерными принципами:

• Разверните нативный мобильный SDK: Когда пользовательские сценарии переходят с H5-лендингов, шеринга в соцсетях или QR-кодов через App Store или Google Play и требуют автоматического восстановления параметров или маршрутизации по универсальным ссылкам и ссылкам приложений в один клик.

• Используйте HTTP API «сервер-сервер»: При экспорте агрегированной статистики каналов в хранилище внутренних данных или при записи бэкенд-событий, которые не зависят от контекста запуска на клиенте.

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

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

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

• Концепции: Комплект разработки программного обеспечения, Интерфейс программирования приложений, Отложенный диплинкинг, Изоляция песочницы ОС

• Технологии: Android Archive (.aar), iOS XCFramework, Google Play Install Referrer, Apple Universal Links

• Стандарты: Семантика HTTP IETF RFC 9110, Общий синтаксис URI IETF RFC 3986, Проект мобильной безопасности OWASP

• Интерфейсы платформы и интеграции: Android Application.onCreate, iOS UIApplicationDelegate, UISceneDelegate, NSUserActivity

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

  • Руководство разработчиков Google Android по жизненному циклу приложения

  • Руководство разработчиков Google Android по ссылкам приложений (App Links)

  • Техническое руководство по API Google Play Install Referrer

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

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

  • Документация Apple для разработчиков по поддержке универсальных ссылок

  • Документация Apple для разработчиков по созданию мультиплатформенного пакета бинарного фреймворка (XCFramework)

  • Рекомендации Apple по конфиденциальности пользователей и использованию данных