В атрибуции мобильных приложений «всё работает» ровно до тех пор, пока вы не начинаете проверять реальные сценарии в разных странах: другой стор-лендинг, другой язык, другой набор редиректов, блокировки подсетей, ограничения браузеров и приватность iOS. Поэтому для маркетингового QA часто используют индивидуальные mobile proxy и тестируют цепочку целиком: клик → стор → установка → первый запуск → событие.
Ниже — практическая схема работы AppsFlyer, типовые места поломок и чек-листы: где именно настраивается прокси (на уровне тестового профиля/устройства), какие поля нужны (host/port/login/password, протокол), как доказать, что гео действительно нужное (IP→Country + ASN) и как поймать «прыжки» сессии.
Что такое MMP и зачем нужна атрибуция
MMP (mobile measurement partner) — платформа измерений, которая единообразно считает установки и события по всем источникам трафика, а также помогает сравнивать эффективность и бюджеты. AppsFlyer решает задачу «склейки» взаимодействия с рекламой (клик/показ) с установкой и дальнейшими событиями в приложении.
Как AppsFlyer связывает клик, установку и события
1) Атрибуционная ссылка
На объявлении стоит ссылка (OneLink или single-platform). При клике AppsFlyer получает параметры кампании и делает редирект в нужный магазин приложений или сразу в приложение (если оно установлено). Важно, что в реальной цепочке участвуют дополнительные редиректы (трекеры, email-клик-трекинг, CDN), из‑за чего часть параметров может теряться.
2) Первый запуск и SDK
После установки AppsFlyer SDK внутри приложения отправляет install/first_open и последующие in-app события. Для сопоставления клика и первого запуска AppsFlyer использует идентификаторы устройства (IDFA/IDFV на iOS, GAID на Android и др.) и дополнительные сигналы.
3) Гео в отчётах: откуда берётся страна
Страна пользователя, как правило, определяется по IP-адресу устройства и её маппингу в гео. В QA это критично: IP может быть замаскирована VPN, iOS Private Relay или прокси-слоем (например, в контексте SKAN), поэтому «страна» в отчёте может отличаться от ожиданий. Перед тестом фиксируйте IP и проверяйте его независимыми способами.
Где чаще всего ломается цепочка «клик → стор → первый запуск → событие»
| Шаг | Что должно произойти | Что ломается чаще всего | Как диагностировать |
|---|---|---|---|
| Клик | AppsFlyer получил клик и параметры кампании | Неверные параметры, link wrapping, блок скриптов, rate limiting | Проверить длинный URL, параметры, повторить в другом браузере |
| Редирект в стор | Открылся правильный storefront по стране | Geo redirect, недоступность приложения в стране, блок подсетей/ASN | Проверить доступность стран в консоли магазина и логи редиректов |
| Установка | Пользователь установил именно то приложение | Кэш стора, другой аккаунт, отложенная установка | Чистый тест: удалить приложение, очистить кеш/данные, фиксировать время |
| Первый запуск | SDK отправил install/first_open | SDK не инициализируется, блок доменов, проблемы сети/consent | SDK debug, проверка сетевого доступа, тестовая подия |
| Deep link / deferred deep link | Переход в нужный экран | Неправильные Universal Links/App Links, ограничения браузера | Матрица тестов OS×браузер×статус «установлено/нет» |
Зачем в гео-QA нужны индивидуальные mobile proxy
Mobile proxy — это прокси из мобильных операторских сетей (carrier IP). В гео‑тестах они дают более «живое» поведение: меньше блоков, корректнее редиректы, меньше подозрений антифрода по сравнению с датацентровыми IP. Индивидуальный endpoint снижает риск того, что IP‑пул уже «испорчен» чужими тестами и попал в denylist.
| Тип прокси | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
| Mobile (carrier) | Максимально близко к реальному трафику | Дороже, нужен sticky session | Store + deferred deep link, ретаргет |
| Residential | Неплохо для web-to-app | Не всегда стабильны | Лендинги, локализация, geo redirect |
| Datacenter | Дёшево и быстро | Часто блокируют | Быстрые smoke-тесты |
Где настраивается прокси (уровень профиля) и что настраивать в AppsFlyer
Ключевой момент: прокси не задаётся «в AppsFlyer». AppsFlyer получает события от SDK и видит IP устройства. Поэтому прокси настраивается:
- на тестовом смартфоне (сетевой прокси/VPN-подключение),
- в browser profiles — если вы контролируете клик и редиректы отдельным профилем браузера,
- в эмуляторе/ферме устройств.
Шаги в AppsFlyer
- Создайте OneLink под ваши сценарии (редирект в стор + deep/deferred deep linking).
- Зарегистрируйте тестовые устройства: профиль (email справа сверху) → Test devices. Это позволяет делать повторные установки и снижает риск фрод‑флагов. Есть лимит на количество устройств.
- Для ретаргет‑проверок включите ретаргетинг в настройках приложения и используйте ссылки с
is_retargeting=true.
Шаги в профиле браузера/инструменте
В менеджерах профилей обычно есть блок Proxy: выбираете тип (HTTP/HTTPS или SOCKS5), вводите host, port, login, password и жмёте проверку соединения. Для мобильных прокси дополнительно настраивается sticky session — фиксация IP на время прохождения сценария.
Как проверить страну и стабильность сессии (IP→Country + ASN)
IP→Country
- проверьте IP и страну минимум в двух независимых сервисах;
- зафиксируйте IP «до клика», «перед установкой», «перед first_open»;
- если сервисы дают разную страну — это уже риск для выводов по тесту.
ASN check
ASN помогает понять, кому принадлежит сеть: мобильному оператору, хостингу или VPN‑пулу. Многие политики (CDN/антифрод) умеют ограничивать доступ по диапазонам и ASN, поэтому ASN — обязательная часть валидации.
Session persistence
- используйте sticky session на время «клик → стор → установка → первый запуск»;
- не делайте больших пауз — провайдер может сменить IP;
- один сценарий = один профиль + один прокси, чтобы не смешивать cookies/кеш/контекст;
- контекст тоже должен быть согласован: timezone, locale, Accept-Language.
Почему ломаются пиксели/виджеты и редиректы
В гео‑тестах вмешиваются сторонние ограничения: блоки по подсетям/ASN, гео‑правила магазинов, особенности in‑app браузеров. Иногда ломает даже мелочь — например, открытие OneLink в новой вкладке через target="_blank" может показать пустую страницу вместо редиректа. Поэтому подход «сначала зафиксировать, где упало» обычно быстрее, чем бесконечно «перепроверять всё».
Кейс: UA‑команда тестирует ЕС и Украину
Минимальный план прогона:
- составить матрицу OS×браузер×статус (установлено/нет) и добавить страны;
- подготовить OneLink с UTM и тестовыми метками (pid/c/af_sub*);
- зарегистрировать тестовые устройства в AppsFlyer;
- для каждой страны — отдельный профиль браузера с индивидуальным mobile proxy и sticky session;
- зафиксировать IP/ASN на шагах и сравнить инсталл+события в AppsFlyer с ожидаемыми параметрами.
FAQ
Мобильные прокси для AppsFlyer: как понять, что без них результаты будут «не те»?
мобильные прокси для AppsFlyer особенно полезны там, где поведение зависит от страны и типа сети: стор-лендинги, доступность приложения, deferred deep links, ретаргет‑цепочки и блокировки датацентровых IP.
Можно ли настроить прокси «внутри» AppsFlyer?
Нет. Прокси настраивается на устройстве или в профиле браузера/эмулятора. В AppsFlyer вы настраиваете ссылки, тестовые устройства и смотрите отчёты/сырые данные.
Как убедиться, что IP не «прыгнула» в процессе?
Включите sticky session, фиксируйте IP на каждом шаге и проверяйте ASN. Если IP меняется до first_open — атрибуция и гео‑логика могут стать нерелевантными.
Источники
- AppsFlyer: структура и параметры атрибуционных ссылок
- AppsFlyer: модель атрибуции и device ID matching
- AppsFlyer: определение локации по IP и ограничения
- AppsFlyer: OneLink и сценарии deep/deferred deep linking
- AppsFlyer: регистрация тестовых устройств
- AppsFlyer: SDK testing и ретаргет‑тесты
- AppsFlyer: OneLink troubleshooting
- Пример полей прокси в browser profiles
- Google Play Console: доступность/таргетинг по странам
- Google Cloud Media CDN: блокировки по IP/стране/ASN