Мобільні проксі для AppsFlyer: гео-QA атрибуції та deep link тестування

У маркетингу мобільних застосунків часто все виглядає просто: є реклама, є клік, є інсталл, потім — перший запуск і події. На практиці цей ланцюжок легко «ламається» через редіректи, різні стор-лендинги за країною, приватність iOS, кеші браузерів, або блокування підмереж. Тому для якісного QA атрибуції й deep links команда зазвичай тестує сценарії з реального мобільного трафіку — і тут з’являються індивідуальні mobile proxy.

Нижче — покроковий гайд: що таке MMP та AppsFlyer-атрибуція, де саме виникають збої «клік → стор → перший запуск → подія», як налаштовувати проксі на рівні профілю тестового середовища, і як валідовувати, що гео справді потрібне (IP→Country + ASN) і що сесія не «стрибає».

Що таке MMP та навіщо потрібна атрибуція

MMP (mobile measurement partner) — це платформа вимірювання, яка допомагає чесно та однаково рахувати інсталли/події з різних каналів і зіставляти їх з рекламними витратами. AppsFlyer — один із найпоширеніших MMP. Його задача — «з’єднати» взаємодію з рекламою (клік або показ) з подальшим інсталом і поведінкою в застосунку.

Чому без MMP складно:

• рекламні платформи мають власні атрибуційні моделі та конфлікт інтересів (вони оптимізують під свої метрики);
• ланцюжок проходить через App Store / Google Play, де частина параметрів губиться;
• на iOS приватність обмежує ідентифікатори (ATT), а на Android можливі нюанси з Install Referrer, альтернативними сторами тощо.

Як AppsFlyer вимірює інстали та події

1) Точка входу: атрибуційне посилання

У більшості кейсів користувач бачить рекламу і клікає. За кліком стоїть атрибуційне посилання (OneLink або одно-платформне), яке «повідомляє» AppsFlyer про взаємодію та параметри кампанії (source, campaign, adset, UTM, тощо). Далі посилання робить редірект у стор або у застосунок (якщо він уже встановлений).

2) Інсталл → перший запуск → SDK

Після інсталу SDK AppsFlyer всередині застосунку відправляє подію інсталу/першого запуску та наступні in-app events. Для зіставлення кліку з першим запуском використовуються ідентифікатори пристрою (наприклад, IDFA/IDFV на iOS, GAID на Android) та інші сигнали.

3) Геолокація в AppsFlyer: звідки береться «країна»

Для більшості звітів AppsFlyer визначає локацію користувача на основі IP-адреси пристрою, яку мапить у країну/місто. Важливий нюанс для QA: IP може бути замаскована VPN, iOS Private Relay або проксі-серверами (наприклад, у контексті SKAN), і тоді «країна» у звітах може бути неочевидною. Саме тому перед тестом треба зафіксувати, який IP бачать сторонні сервіси, і чи відповідає він країні, яку ви перевіряєте.

Де найчастіше ламається ланцюжок «клік → стор → перший запуск → подія»

У QA корисно мислити не «інсталл/не інсталл», а «де саме відвалилося». Ось типова карта проблем.

Етап	Що має статись	Типові причини збою	Як перевірити
Клік	AppsFlyer отримав клік з параметрами кампанії	Link wrapping, неправильно зібрані параметри, блок скриптів у in-app browser, rate limiting	Перевірити довгий URL, лог кліку, UTM/параметри, повторити з іншим браузером
Редірект у стор	OneLink/лінк відкрив правильний Storefront	Гео-редіректи, недоступність застосунку в країні, блоки підмереж (CDN/антифрод), помилки HTML-відкриття	Порівняти стор-URL для різних країн, перевірити доступність у Play Console/App Store Connect
Інсталл	Застосунок встановлено з потрібної сторінки	Кеш стора, інший акаунт, відкладена інсталяція, альтернативний стор без реферальних параметрів	Чистий тест: видалити застосунок, очистити кеш, фіксувати час інсталу
Перший запуск	SDK відправив install/first_open	SDK не ініціалізувався, немає мережі/блок доменів, відкладена згода (consent), фаєрвол/проксі	Debug/лог SDK, перевірка доступу до доменів, тестова подія
Події	In-app events відображаються в AppsFlyer	Неправильні назви подій, дублювання, відсутній revenue/currency, затримки, фільтри	Порівняти з бекенд-логами, перевірити raw data, звірити схему подій
Deep link / deferred deep link	Користувач потрапив у потрібний екран	Universal Links/App Links не налаштовані, in-app браузер «ламає» intent, параметри не передались після інсталу	Матриця тестів по OS/браузеру/стану «встановлено/не встановлено», перевірка колбеків

Навіщо потрібні індивідуальні mobile proxy у QA AppsFlyer

Під «mobile proxy» зазвичай мають на увазі проксі з мобільних операторських підмереж (carrier IP). Для гео-QA це важливо, бо багато сервісів по-різному поводяться з датасентровими IP і з мобільними: різна доступність, антифрод, редіректи, ліміти. Індивідуальні проксі означають, що endpoint закріплений за вами (менше «шуму» від чужих тестів і менше ризику, що підмережа вже у бані).

Коли це реально потрібно:

• перевіряєте, що стор-лендинг і локалізація коректні в різних країнах (geo redirect, localization QA);
• тестуєте deferred deep linking (клік до інсталу) в «реальному» мобільному трафіку;
• перевіряєте ретаргет-ланцюжки (re-attribution/re-engagement) і роботу параметрів is_retargeting=true;
• ловите баги, які проявляються тільки на певних підмережах/ASN (наприклад, CDN блокує відомі проксі/VPN-пули);
• робите A/B testing або перевіряєте різні креативи/лендинги за країною.

Тип проксі	Переваги для гео-QA	Ризики / обмеження	Коли обирати
Mobile (carrier)	Найближче до «живого» трафіку, менше блоків, часто кращі стор-редіректи	Дорожче, IP може змінюватись, потрібна sticky session	Deep link + store flow, ретаргет, перевірка антифроду
Residential	Добре для веб-частини (лендинги, реєстрації), відносно «натуральні» IP	Нестабільна швидкість, інколи спільні пули	Web-to-app, перевірка локалізованих лендингів
Datacenter	Дешево і швидко	Найчастіше блочиться, «підозрілий» трафік	Чернеткові перевірки, smoke-тести без геочутливих сценаріїв

Де задається проксі «на рівні профілю» і що саме налаштовувати в AppsFlyer

Важливо: у веб-інтерфейсі AppsFlyer немає поля «Proxy host/port», яке б змушувало AppsFlyer «ходити через проксі». AppsFlyer лише приймає дані про події й IP пристрою. Тому проксі задається у вашому тестовому середовищі:

• на тестовому смартфоні (мережевий проксі / VPN-рішення),
• у browser profiles (антидетект/ізольовані профілі) для частини «клік → редірект»,
• в емуляторі/девайс-фермі, якщо ви там тестуєте.

Кроки в AppsFlyer (потрібно для «чистого» QA)

• Створіть OneLink (або app-specific link) для ваших сценаріїв: редірект у стор + deep link / deferred deep link.
• Зареєструйте тестові пристрої, щоб можна було перевстановлювати застосунок і не ловити фрод-фільтри під час тестів. У AppsFlyer це робиться з меню профілю: у правому верхньому куті натисніть email → Test devices і додайте/видаліть пристрої. (Ліміт — 200 пристроїв на акаунт.)
• Для ретаргет-тестів увімкніть ретаргетинг в налаштуваннях застосунку та використовуйте лінки з is_retargeting=true.

Кроки в профілі браузера/тест-оточенні (де живе проксі)

У більшості менеджерів профілів логіка однакова: створюєте профіль → обираєте тип проксі → заповнюєте реквізити → робите Check proxy. Типові поля:

• Host (IP або домен проксі)
• Port
• Login / Username
• Password
• Protocol: HTTP(S) або SOCKS5 (залежить від провайдера і вашого інструмента)

Якщо проксі мобільні з ротацією, додатково зверніть увагу на режим sticky session (фіксація IP на час тесту) і на обмеження по кількості запитів (rate limiting).

Як валідовувати, що проксі у потрібній країні і що сесія не «пригнула»

Гео-QA розвалюється, коли ви думаєте, що «це Франція», а насправді IP вже в Нідерландах або взагалі в датацентрі. Тому мінімальний чек-лист має включати IP→Country і ASN.

1) IP→Country (дві незалежні перевірки)

• відкрийте 2 різні сервіси «what is my IP» і звірте IP та Country;
• якщо країни різні — не робіть висновків по одному джерелу (геобази оновлюються з різною швидкістю);
• зафіксуйте IP в тест-репорті: «до кліку», «перед установкою», «перед першим запуском».

2) ASN check (хто власник підмережі)

ASN (Autonomous System Number) показує, якому оператору/провайдеру належить мережа. Це критично, бо блокування і гео-політики часто застосовують не лише по країні, а й по ASN або по IP-діапазонах. Наприклад, CDN може відмовляти трафіку з відомих VPN/проксі-пулів або цілих підмереж.

3) Session persistence: як впевнитись, що IP не змінився посеред тесту

• для mobile proxy увімкніть sticky session на час, який покриває «клік → стор → інсталл → перший запуск»;
• не робіть довгих пауз між кроками: деякі провайдери «скидають» IP після таймауту;
• використовуйте один профіль браузера/один девайс на один сценарій, щоб не змішувати куки/кеш/ідентифікатори;
• якщо тестуєте кілька країн підряд — робіть повний reset: інший профіль + інший проксі + чистий девайс/окремий user session.

Перевірка	Що фіксуємо	Навіщо	Ознака проблеми
IP→Country	IP, країна, місто (якщо є)	Підтвердити гео тесту	Різні країни у різних сервісах
ASN	ASN + назва провайдера	Відрізнити carrier від датацентра/VPN	ASN хмарного провайдера замість оператора
Стабільність IP	IP на кожному кроці	Не зламати атрибуцію і гео-логіку	IP змінився до інсталу або до first_open
Fingerprint consistency	Timezone, locale, Accept-Language	Уникнути «штучних» редіректів/блоків	Timezone ≠ країна IP, сайт показує інший регіон

Чому «ламаються» віджети, пікселі та редіректи під час гео-QA

Коли ви тестуєте «як користувач з іншої країни», ви заходите в зону, де багато сторонніх компонентів мають власні гео-правила та антифрод:

• 3rd-party гео-політики: стор або CDN може обмежувати доступ по країні/ASN або відсікати відомі проксі-пули;
• блокування підмереж: деякі платформи прямо вміють denylist’ити IP-діапазони або ASNs (типовий кейс — мінімізувати «обхід ліцензій» через VPN/проксі);
• in-app browser обмеження: вебв’ю може блокувати cookies/скрипти, що ламає трекінг кліків і пікселів;
• помилки в HTML-обгортці: навіть дрібниця на кшталт відкриття OneLink у новій вкладці (target="_blank") може дати білу сторінку і зірвати редірект;
• браузер-специфічні баги: наприклад, deferred deep linking може поводитись інакше в окремих браузерах.

Практичний висновок для QA: тестуйте критичні сценарії мінімум у двох браузерах (Safari/Chrome), фіксуйте, де саме «ламається» (клік, редірект, стор, перший запуск), і відокремлюйте проблеми атрибуції від проблем UX/веб-компонентів.

Кейс: команда UA-застосунку перевіряє deep link та атрибуцію в ЄС і Україні

Уявімо сценарій: команда має рекламні кампанії в Україні та кількох країнах ЄС. Потрібно перевірити, що:

• deep link веде у правильний екран (наприклад, промо-пейвол або конкретний розділ),
• інсталл і ключова подія (наприклад, af_complete_registration або purchase) коректно атрибутуються,
• локалізація і стор-лендинг відповідають країні.

Крок 1. Матриця тестів і очікувані результати

Складіть таблицю «OS × браузер × стан застосунку» (встановлено/не встановлено) і додайте гео. Це зменшує ризик пропустити edge cases, яких у deep linking дуже багато.

Крок 2. Підготовка лінків і параметрів

• Створіть OneLink, де налаштовано редірект у правильний стор і deep/deferred deep linking.
• Додайте UTM (для наскрізної аналітики) та параметри кампанії (pid, c, af_adset, af_ad, af_sub1-5 для тестових міток).
• Для ретаргету підготуйте окремий лінк з is_retargeting=true.

Крок 3. Підготовка тестових пристроїв у AppsFlyer

• Зареєструйте тестові девайси в AppsFlyer (профіль → Test devices), щоб повторні інстали не виглядали як фрод і коректно потрапляли в звіти.
• Для iOS визначте, чи тестуєте як consenting user (IDFA/ATT) чи як non-consenting (частіше використовують IDFV у тестах).

Крок 4. Налаштування проксі та профілю середовища

• Для кожної країни створіть окремий профіль браузера з прив’язаним mobile proxy (sticky session).
• Вирівняйте «контекст» під країну: timezone, locale, Accept-Language. Це не про «обхід» — це про те, щоб не отримати хибні результати через очевидні невідповідності.
• Переконайтесь, що CDN/стор не віддає інший контент через geo redirect.

Крок 5. Прогін сценарію та збір доказів

• Перед кліком: зафіксуйте IP, Country та ASN.
• Клік по OneLink з профілю країни → перевірка стор-лендингу → інсталл → перший запуск.
• У застосунку: тригерніть контрольну подію (реєстрація/покупка) і зафіксуйте таймстемпи.
• В AppsFlyer: звірте, що інсталл і подія прийшли з правильними параметрами кампанії та країною (якщо країна «поїхала» — повертаємось до IP/ASN і стабільності сесії).

Типові помилки та як їх уникати

Помилка	Як проявляється	Причина	Що робити
Країна в AppsFlyer не та	EU тест, а в репорті інша країна	IP замаскована, змінена сесія, Private Relay/VPN	Перевірити IP→Country + ASN, ввімкнути sticky session, фіксувати IP на кроках
OneLink відкриває «білу сторінку»	Немає редіректу у стор	Відкриття через target="_blank" або обмеження браузера	Відкрити лінк без target, перевірити в іншому браузері
Deferred deep link не спрацював	Після інсталу відкривається головний екран	Механізм deep linking не налаштований або браузер/контекст обмежує	Перевірити Universal Links/App Links, зробити матрицю тестів OS×браузер×стан
Подія є в застосунку, але немає в AppsFlyer	SDK не відправляє/не приймає event	Неправильна інтеграція, блок доменів, consent	SDK debug, перевірка мережі, звірка схем подій
Ретаргет не атрибутується	Немає re-attribution / re-engagement	Не увімкнений ретаргетинг або немає is_retargeting=true	Увімкнути ретаргетинг, використати правильний тестовий лінк

FAQ

Мобільні проксі для AppsFlyer: як зрозуміти, що вони потрібні саме вам?

мобільні проксі для AppsFlyer потрібні, коли ви тестуєте геозалежний шлях користувача (стор-лендинги, доступність застосунку, редіректи, deferred deep links) і хочете максимально наблизити тест до реального мобільного трафіку, мінімізувавши блоки датасентрових IP.

Чи можна налаштувати проксі прямо в AppsFlyer?

Ні, AppsFlyer не «виходить у мережу» від вашого імені — він отримує події від SDK і бачить IP пристрою. Проксі налаштовується на тестовому девайсі або в профілі браузера/емулятора, а в AppsFlyer ви налаштовуєте лінки та реєструєте тестові пристрої.

Як перевірити, що проксі не зламала атрибуцію?

Переконайтесь у стабільності IP на всіх кроках (клік, стор, перший запуск), звірте країну по IP, а також ASN (щоб зрозуміти тип мережі). Якщо IP змінився до first_open — атрибуція може «розсипатись».

Чому OneLink інколи не редіректить у стор?

Причини бувають як технічні (обмеження браузера/вебв’ю), так і «дрібні» — наприклад, відкриття OneLink у новій вкладці через target="_blank" може призвести до порожньої сторінки. Тому тестуйте у кількох браузерах і контролюйте спосіб відкриття лінка.

Що робити, якщо в ЄС стор показує іншу сторінку або застосунок недоступний?

Перевірте налаштування доступності по країнах у Google Play Console/App Store Connect, а також те, чи не блокує CDN ваші IP/ASN. Для таких кейсів індивідуальні mobile proxy зазвичай дають більш «реалістичний» результат, ніж датасентрові IP.

Джерела та корисні посилання

• AppsFlyer: attribution links, структура та параметри
• AppsFlyer: модель атрибуції та device ID matching (IDFA/IDFV/GAID)
• AppsFlyer: визначення локації користувача за IP та обмеження (VPN/Private Relay/SKAN)
• AppsFlyer: створення OneLink та сценарії deep/deferred deep linking
• AppsFlyer: реєстрація тестових пристроїв (профіль → Test devices)
• AppsFlyer: тестування SDK та ретаргетинг-ланцюжків
• AppsFlyer: OneLink troubleshooting (blank page, Brave та інші нюанси)
• Browser profiles: приклад полів проксі (Host/Port/Username/Password, Check proxy)
• Google Play Console: таргетинг/доступність по країнах (важливо для гео-QA)
• Google Cloud Media CDN: політики безпеки (блокування по IP-діапазонах/країні/ASN)
• Пояснення поняття browser fingerprinting (контекст для fingerprint consistency)
• AppsFlyer: deep linking guide (про складність QA та edge cases)