Воронка PWA: від кліка до депозиту

Що таке PWA і як воно працює

PWA (Progressive Web App) — веб-додаток, який встановлюється на головний екран телефону і працює як нативний додаток: іконка, повноекранний режим, push-сповіщення.

Чому арбітражники використовують PWA замість нативних додатків:

• Обхід модерації: рекламні мережі (FB, TikTok) перевіряють вміст за URL. PWA встановлюється з нейтрального домену, а money-офер відкривається вже в установленому додатку

• Швидкий запуск: не потрібен Google Play / App Store, не потрібен підпис розробника. Конструктор PWA в Adset.Pro — створив за хвилини

• Push-сповіщення: після установки запитується дозвіл на пуші — безкоштовна база для ретаргетингу

• Не потрібно завантаження APK: установка через браузер (Add to Home Screen) — швидше і безпечніше з точки зору користувача

Типи PWA в Adset.Pro:

---

Повна воронка PWA

Кожен крок воронки фіксується як окрема подія в трекері:

[Рекламне оголошення FB/TikTok/Push]
        ↓
SOURCE_CLICK            ← трекер генерує event_click_id (UUID), визначає GEO/device/IP
        ↓
  SOURCE_FILTER         ← [якщо не пройшов фільтри] клік заблоковано → White Page
        ↓
[In-App WebView?]       ← FB/Instagram/TikTok/Telegram?
        ↓ YES                         ↓ NO
  Bridge Page              Лендинг / PWA
  (кік в Chrome/Safari)
        ↓
LAND_VIEW               ← користувач відкрив прелендинг
        ↓
LAND_CLICK              ← клікнув кнопку "Встановити" / "Далі"
        ↓
PWA_VIEW                ← відкрив сторінку PWA (бачить install prompt)
        ↓
PWA_INSTALL             ← прийняв install prompt, PWA встановлено на головний екран
        ↓
[Сторінка підписки]      ← запит пуш-сповіщень
        ↓
NOTIFICATION_REQUEST    ← показано нативний запит на пуші
NOTIFICATION_SUBSCRIBE  ← користувач погодився (або DECLINE — відмовився)
        ↓
[Redirect на офер]     ← click_id передається партнерці через paramTemplate
        ↓
CPA_HOLD                ← реєстрація на сайті партнерки (постбек)
        ↓
CPA_ACCEPT              ← перший депозит / FTD (постбек)
        ↓
CPA_REDEP               ← повторний депозит (постбек)

Додаткові події:

• PWA_OPEN — повторне відкриття вже встановленого PWA (через дні/тижні)

• IOS_INSTALL — установка на iOS (Redis-дедуплікація, один раз на clickId)

• POSTLANDING_VIEW / POSTLANDING_CLICK — сторінка між PWA-підпискою і редиректом на офер

---

Ключові метрики воронки

Усі метрики доступні в статистиці Adset.Pro:

Базові метрики

Конверсійні метрики

Postlanding метрики

---

Де втрачаються користувачі: аналіз воронки

Кожен ступінь воронки — потенційна точка втрат. Розбираємо по порядку:

Клік → PWA_VIEW (втрата на прелендингу/перехід)

Типові причини втрат:

• Повільне завантаження — мобільний трафік, поганий інтернет у Tier-3 GEO. PWA-шаблон важкий (JS, картинки)

• In-App WebView — FB/Instagram/TikTok відкривають посилання у вбудованому WebView. Adset.Pro віддає Bridge Page для кіка у зовнішній браузер, але частина користувачів втрачається

• Cloak-фільтри — якщо бот-фільтрація або фільтри Stream Set спрацювали, користувач йде на White Page замість PWA

Як діагностувати:

• Порівняй LAND_VIEW / clicks ratio

• Дивись SOURCE_FILTER — скільки кліків заблоковано

• Group by user_device / user_browser — де втрати більше

PWA_VIEW → PWA_INSTALL (конверсія сторінки PWA)

Фактори, що впливають на install_rate:

• Дизайн PWA: іконка (виглядає як справжній додаток?), назва, кольорова схема

• Install prompt: На Android (Chrome) — нативний банер «Add to Home Screen». На iOS (Safari) — немає нативного промпту, потрібні інструкції через UI

• Браузер: Chrome > Samsung Browser > Safari (по install_rate)

iOS специфіка:

• Немає beforeinstallprompt події — PWA використовує PwaManager з fallback-інструкціями

• Установка фіксується через IOS_INSTALL з Redis-дедуплікацією (один раз на clickId)

• Install rate на iOS значно нижче — зазвичай у 3-5 разів нижче Android

Як діагностувати:

• pwa_view_to_instal_rate з group by user_device / user_os / user_browser

• Порівняй Android vs iOS — різниця повинна бути очікуваною (якщо ні — проблема в iOS-воронці)

PWA_INSTALL → CPA_HOLD (install → реєстрація)

Типові причини втрат:

• Якість офера: лендинг партнерки не мотивує зареєструватися

• Бонусна пропозиція: нерелевантна валюта для GEO, застарілий бонус

• Швидкість редиректу: після установки PWA → редирект на офер. Якщо повільний — користувач йде

• Сторінка підписки: після PWA_INSTALL показується сторінка запиту пуш-сповіщень (subscribe-template). Якщо користувач закриває на цьому етапі — він не доходить до офера

Як діагностувати:

• pwa_install_to_hold_rate — типове значення 20-50% для gambling

• Group by cmp_offer / cmp_cpa — який офер конвертує краще

CPA_HOLD → CPA_ACCEPT (реєстрація → депозит)

Типовий % для gambling/betting:

• Tier-1 GEO (DE, UK, CA): 30-50% реєстрацій → депозит

• Tier-2 GEO (UA, KZ, PL): 20-40%

• Tier-3 GEO (NG, IN, BD): 10-25%

Що впливає:

• Маппінг статусів: якщо hold не налаштований у CPA-мережі — конверсія «пропадає»

• Платіжні методи: доступність локальних способів оплати для користувача

• Онбординг партнерки: верифікація, KYC, мінімальний депозит

Метрика: cpa_accept / cpa_hold або click_to_dep / click_to_reg

---

Аналіз за групуваннями

Воронку можна розбити по будь-якому зрізу:

Кейс: A/B тест двох PWA

Задача: Запущена одна кампанія з двома PWA через Flow 50/50.

Як дивитися:

1. Статистика → період last 7 days

2. Метрика: pwa_view_to_instal_rate

3. Group by: cmp_pwa

4. Додатково: click_to_instal_rate, pwa_install_to_accept_rate

Інтерпретація: Якщо PWA-1 показує install_rate 35%, а PWA-2 — 25%, при зіставному CPA → масштабуй PWA-1.

---

iOS vs Android: важливі відмінності

iOS App в Adset.Pro:

• Окремий тип PWA (ios-app) — спеціальна обробка для iOS

• Використовує IOS_INSTALL замість PWA_INSTALL для обліку установок

• Redis-дедуплікація через acquireInstallGate(clickId) — гарантує один install-івент на clickId

• Підтримка ios26 query-параметра для специфіки iOS 26

Практична порада: Розділяй трафік iOS і Android в різні кампанії або різні Stream Sets. Причини:

• Різний install_rate (Android 30-40%, iOS 5-15%)

• Різна воронка (нативний промпт vs інструкції)

• Різні PWA-дизайни оптимальні для кожної платформи

---

Пуш-підписка в воронці PWA

Після установки PWA користувач потрапляє на сторінку підписки (subscribe-template), де показується запит на пуш-сповіщення:

Поведінка після підписки:

• Якщо SUBSCRIBE → редирект на офер + запис в Subscription (clickId, country, campaign, pwa, fcmToken)

• Якщо DECLINE → все одно редирект на офер (але без пуш-підписки)

• Якщо PWA вже в standalone mode + вже підписаний → відразу відкриває офер через Chrome Custom Tab

Бізнес-цінність пуш-бази:

• Зазвичай 40-70% тих, хто встановив PWA, підписуються на пуші

• Підписники — це ретаргетингова аудиторія: безкоштовні повторні дотики через push-кампанії

• Зв'язок з LTV: користувачі, які отримують пуші, роблять більше редепозитів (тригерні пуші після REGISTRATION і DEPOSIT)

• Push-база «старіє» (~10-20% FAIL на місяць) — потрібно постійно поповнювати новими підписниками

Standalone mode (встановлене PWA):

• Якщо користувач відкрив PWA з домашнього екрану (standalone) і вже підписаний на пуші — сторінка підписки пропускається

• Перехід на офер через Chrome Custom Tab (CCT) — URL відкривається в Chrome поверх PWA, не втрачається контекст

• Cookie push_status використовується для визначення статусу підписки при повторних візитах

---

Конфігурація воронки в кампанії

На рівні Flow в Stream Set налаштовується:

Варіанти воронки:

1. Повна: Landing → PWA → Subscribe → Postlanding → Offer

2. Без прелендинга: PWA → Subscribe → Offer (коротка воронка)

3. Landing as PWA: Landing (в режимі PWA) → Subscribe → Offer

4. Без PWA: Landing → Offer (якщо pwa = null)

---

Часті питання

Q: Чому pwa_installs в статистиці Adset.Pro більше, ніж FTD в кабінеті партнерки?

Це нормально. Установка PWA ≠ депозит. Між ними ще кілька кроків:

• PWA встановлено → потрібно перейти на офер

• Офер відкрився → потрібно зареєструватися

• Зареєструвався → потрібно задепозити

Типова конверсія install → FTD: 10-30% (залежить від GEO, офера, якості PWA).

Q: Користувач встановив PWA, але депозит атрибутувався не до нашого кліку — чому?

Можливі причини:

1. click_id не передався — paramTemplate налаштований неправильно, або користувач перейшов на офер за іншим посиланням

2. Sticky Flow вимкнений — при повторному вході через PWA_OPEN генерується новий click_id, якщо stickyFlowKeepClickId = false

3. Вікно атрибуції сплинуло — користувач задепозив через тиждень, а cookie з click_id очистився

4. Користувач відкрив офер безпосередньо — зайшов на сайт партнерки через браузер, минаючи PWA

Q: Як перевірити, що paramTemplate правильно передає click_id?

1. Створи тестовий клік за трекінговим посиланням

2. Перевір URL, на який тебе редиректить (URL офера)

3. Упевнись, що параметр з click_id присутній і містить UUID

4. Приклад: якщо paramTemplate = ?sub1={event.event_click_id}, то URL офера повинен бути https://partner.com/offer?sub1=35d542f6-56ec-...

5. Якщо click_id відсутній — перевір, що CPA-шаблон і paramTemplate налаштовані правильно

Q: В чому різниця між PWA_INSTALL і IOS_INSTALL?

• PWA_INSTALL — стандартна подія установки через beforeinstallprompt (Android: Chrome, Samsung Browser)

• IOS_INSTALL — спеціальна подія для iOS, де немає нативного install prompt. Фіксується через Redis-дедуплікацію (гарантує один івент на clickId). Використовується коли user_os = iOS або передано ?ios=1

Q: Що таке landingAsPwa і коли використовувати?

Якщо landingAsPwa = true, лендинг працює в режимі PWA — користувач бачить лендинг, йому пропонується встановити на Home Screen, а після установки відбувається редирект на офер. Це спрощена воронка без створення окремого PWA в конструкторі. Підходить для швидкого тестування.