Как SKAdNetwork для веб-рекламы помог сохранить оплату iOS-установок

Оплата установок стала зависеть от подтверждения в AppsFlyer

Ключевой партнёр крупного международного рекламного агентства изменил условия сотрудничества. Рекламодатель с мобильным приложением стал оплачивать только установки, подтверждённые постбэками через AppsFlyer. Постбэк представляет собой автоматическое уведомление об установке. AppsFlyer отвечает за атрибуцию: связывает установку с рекламным источником, чтобы рекламодатель мог учитывать результат рекламы.

Особую сложность представляли пользователи, приходившие с сайтов: существенная часть этой аудитории использовала iOS. Подтверждать установки после веб-рекламы нужно было через SKAdNetwork. Этот механизм Apple передаёт рекламной сети сведения об установке, не раскрывая личность пользователя.

Ко мне обратились коллеги, работавшие с рекламодателями. Без таких подтверждений агентство лишилось бы оплаты iOS-установок от одного из основных партнёров. Под угрозой оказалось не само привлечение пользователей с сайтов, а коммерческий смысл этого направления.

Существующие интеграции не подходили для рекламы на сайтах

Прежде чем разрабатывать своё решение, я проверил готовые варианты. У крупных рекламных сетей, которые я изучил, SKAdNetwork был интегрирован только для рекламы внутри мобильных приложений. Наша задача отличалась: пользователь видел рекламу на сайте, а затем устанавливал приложение на устройство iOS. Готового решения для этого сценария я тогда не нашёл.

Чтобы выстроить такую цепочку, агентству требовалась собственная рекламная сеть, зарегистрированная в Apple и поддерживающая SKAdNetwork. Полезного практического описания запуска в интернете найти не удалось. На Stack Overflow встретилось лишь обсуждение похожей проблемы: разработчик крупной рекламной сети не мог запустить интеграцию и писал, что месяцами ждёт ответа Apple.

Этот опыт показывал, что рассчитывать только на помощь вендора нельзя. В нашей работе Apple тоже не помогла вовремя, поэтому причины сбоев пришлось исследовать самостоятельно.

Разные версии документации не объясняли причину сбоя

Основой стала документация Apple, но для реализации в ней не хватало деталей. Часть информации удалось найти у AppsFlyer. При этом материалы двух платформ описывали разные версии интеграции, и их нельзя было просто объединить в готовую инструкцию.

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

Параллельные проверки сократили ожидание при отладке

Я разработал бэкенд рекламной сети и подготовил тестовый стенд. На нём проверял гипотезы: менял условия интеграции и отслеживал, приходит ли постбэк об установке.

Проверка не давала мгновенного ответа. Задержка постбэков в SKAdNetwork служит защите приватности: она затрудняет сопоставление уведомления с конкретным пользователем. Для отладки был доступен ускоренный режим, но ждать результата всё равно приходилось. Последовательная проверка каждого варианта заметно удлиняла бы работу.

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

Цепочка от установки до кабинета рекламодателя

Я зарегистрировал рекламную сеть агентства в Apple и связал её с AppsFlyer. Для завершения интеграции требовались настройки со стороны рекламодателей; с этой частью я тоже им помог.

В результате удалось наладить весь путь подтверждения. Пользователь iOS переходил к установке приложения после рекламы на сайте. Apple отправляла через SKAdNetwork постбэк рекламной сети агентства, а затем данные поступали в AppsFlyer и отображались в кабинете рекламодателя.

Партнёр стал получать подтверждения в требуемом виде. Это позволило агентству сохранить сотрудничество и оплату iOS-установок после изменения условий. Направление, которое рисковало потерять выручку, удалось сохранить.

Всю техническую работу, включая исследование документации, разработку и запуск интеграции, я выполнил самостоятельно.

Другой проект с AppsFlyer: восстановление полноты трекинга

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

Я написал бэкенд на Python и FastAPI. Он принимал данные от мобильных приложений, разбирал и структурировал их, после чего отправлял серверные постбэки в AppsFlyer. После запуска трекинг начал работать корректно, и команда осталась довольна результатом.

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