Крипто-казино
Torrent Gear
Як працює офферна аналітика в CPA-системах
1) Що таке офферна аналітика і де вона живе
У CPA-системах «оффер» - це конфігурація продукту (бренд/гео/ленд/модель виплат/правила валідності), для якої платформа вважає конверсію, вартість і якість. Оферна аналітика - це збір і обробка подій по кожному офферу, порівняння джерел/креативів, індексація ставок і прийняття рішень про масштабування/стопу.
Ключові завдання:- Бачити ефективність: CTR, CR (click→reg→KYC→FTD), CPA, ROAS/ROI.
- Контролювати якість: D7/D30 retention, 2nd-dep rate, chargeback/refund, NGR.
- Управляти економікою: брекети payout, caps/пейсинг, заморозки/спори.
- Захищатися: дедуплікація, антифрод, правила валідності FTD.
2) Схема даних оффера (мінімальний контракт)
Offer: `offer_id`, `brand`, `geo`, `device`, `landing_id`, `payout_model (CPL/CPA/Hybrid/RS)`, `payout_rules`, `cap/day`, `compliance_guides`.
Traffic touchpoints: `click_id`, `sub_id/aff_id`, `utm_`, `creative_id`, `placement`, `device/os`, `ip/asn`.
Events (S2S): `registration`, `kyc_approved`, `deposit_success {amount,currency,is_ftd}`, `second_deposit`, `refund/chargeback`.
Finance: `payout_calc`, `hold`, `schedule`, `currency`, `fx_rate(date)`.
Quality: `risk_flags`, `fraud_score`, `cohort_metrics`.
3) Атрибуція, дедуплікація і валідність
Ключ атрибуції: 'click _ id'( створюється редиректором мережі/партнера).
Ідемпотентність подій: унікальний'event _ id'→ повтор ≡ «вже врахований».
Дедуплікація FTD: по'( account_id OR payment_fingerprint) + оффер + вікно 30-90 днів)'.
Правила валідності FTD (в оффері): мінімальний депозит, заборона бонусних/нульових поповнень, KYC-статус.
Перетин джерел: при декількох кліках до FTD - політика (last click всередині вікна атрибуції) або data-driven на стороні трекера.
4) Метрики оферної аналітики (операційний шар)
Воронка:- `CTR = Clicks / Impressions`
- `CR1 = Reg / Clicks`
- `CR2 = KYC / Reg`
- 'CR3 = FTD/Reg'( або'FTD/KYC'для суворої воронки)
- `CPA = Spend / FTD`
- `ARPU_Dn = NGR_Dn / FTD`
- `Payback = min{n: Cum_ARPU_Dn ≥ CPA}`
- `ROAS = NGR / Spend`, `ROI = (NGR − Spend − Direct_Opex) / Spend`
- `2nd_dep_rate = Users_with_2nd_dep / FTD`
- `Retention_D7/D30`, `Chargeback_rate`, `Refund_rate`
5) Пайплайн подій: від кліка до виплати
1. Клік: редиректор створює'click _ id', нормалізує UTM, пише лог.
2. Перехід на ленд: прокидання'click _ id '/шифр; фронт без чутливих даних.
3. Серверні події від оператора: 'registration/kyc/deposit/...'на S2S-ендпойнт мережі → в чергу → обробник.
4. Правила оффера: перевірка валідності, вікно атрибуції, дедуплікація.
5. Вітрини BI: когорти FTD (D1/D7/D30), NGR, Payback, списання/спори.
6. Білінг і виплати: розрахунок за моделлю (CPA/Hybrid/RS), hold, акти-звірки.
6) Індексація payout і «брекети якості»
CPA-платіж по офферу часто пов'язують з якістю когорти. Приклад правил:- Базовий брекет: 'CPA = $120', якщо'2nd _ dep ≥ 25%'і'ARPU _ D30 ≥ $90'.
- Зниження: 'CPA = $100', якщо'2nd _ dep <20%'або'Chargeback> 3%'.
- Підвищення: 'CPA = $140', якщо'ARPU _ D30 ≥ $110'і'D7 _ ret ≥ 40%'.
- Індексація перераховується за когортами і джерелами. Рішення фіксуються в додатковій угоді до офферу.
7) SmartLink і авто-рутація офферів
SmartLink розподіляє потік між оферами всередині класу (одне GEO/вертикаль). Оферна аналітика дає фідбек рутеру:- Сигнали: eCPA, CR до FTD, ARPU-проксі, частка відмов/суперечок, комплаєнс-прапори.
- Управління: white/black-list офферів, ручні «піни», caps, pacing, пріоритети.
- Мета: максимізувати Payback/якість при дотриманні правил валідності.
8) Антифрод і якість на рівні оффера
Клік-фрод: IP/ASN-скоринг, velocity-правила, device-фінгерпринт, списки джерел.
Рег-фрод: збіги документів/КУС, пачки нічних реєстрацій, низький engagement.
FTD-фрод: «бонусні» депозити, повернення, «карусель» платежів.
Реакція: авто-заморожування виплат по офферу/сабу, розслідування, акти-звірки, коригування payout.
9) Дашборди офферної аналітики (обов'язковий набір)
1. Воронка по офферу: kliki→reg→KYC→FTD по'source/creative/placement/device'.
2. Якість/когорти: ARPU D1/D7/D30, 2nd-dep, Retention, Payback.
3. Списання/суперечки: відхилення, chargeback/refund з причин і джерел.
4. Стабільність трекінгу: затримка постбеків, частка дублікатів, EMQ/частка подій без'click _ id'.
5. Економіка виплат: фактичний CPA/Hybrid/RS vs брекети, прогноз кеш-флоу (hold, schedule).
10) Алерти і SLA по офферу
Трек-SLA: затримка S2S> 15 хвилин, error-rate> 1%, частка дублікатів> 0,5%.
Бізнес-SLA: падіння'CR (reg→FTD)'на X σ, сплеск chargeback, просадка ARPU.
Комплаєнс: відхилення креативів/лендів, скарги, brand-bidding - авто-ескалація.
Реакція: авто-стоп/кап, повідомлення менеджера, запуск розслідування.
11) Спори та акти-звірки
Стандартна процедура:1. Звірка обсягів по'click _ id/event _ id'за період (UTC).
2. Порівняння валідності FTD за правилами оффера.
3. Вивантаження «прикордонних» кейсів (відхилені/chargeback).
4. Підсумковий акт, коригування payout/RS, оновлення брекетів якості.
12) Формули і міні-приклад
Вихідні: за 30 днів по офферу'BR-Android '
Spend = 25 000; Clicks = 50 000; Reg = 4 000; KYC = 2 600; FTD = 600
GGR_D30/FTD = 130; бонуси = 15%; провайдери ігор = 10% GGR; платіжки = 3% від депозитів; chargeback = 1% депозитів
CPA за договором = $110 (базовий брекет)
Розрахунок NGR_D30 (на 1 FTD):- GGR = 130 → мінус бонуси 19,5 (15%) → мінус провайдери 13 (10%) → мінус платіжки ~ 3,6 → мінус chargeback ~ 1,2 ⇒ NGR ≈ 92,7
- ARPU_D30 = 92,7; CPA факт = 25 000/600 = 41,7 (для мережі)
- Payback (грубо): середньодобовий ARPU ≈ 92,7/30 = 3,09 ⇒ 41,7/3,09 ≈ 14 днів
- Брекет якості: якщо 2nd-dep_rate ≥ 25% і ARPU_D30 ≥ 90 → індексація CPA до $120.
13) Часті помилки в офферній аналітиці
1. Рахувати по GGR, не враховуючи бонуси/комісії → помилковий ROAS.
2. Немає idempotency → дублі FTD при ретраях.
3. Змішування гео/девайсів в одному оффері → «середня температура», погані рішення.
4. Відсутність chargeback/refund подій → завищений ARPU.
5. Нечіткі правила валідності FTD → вічні суперечки, заморозки виплат.
6. Тільки EPC без когорт і 2nd-dep → крихка економіка.
7. Немає алертів на затримки S2S → провали в даних, зрив білінгу.
14) Чек-листи
14. 1. Перед запуском оффера
- Описані'payout _ model','payout _ rules', вікно атрибуції, валідність FTD
- s2s-схема: `registration/KYC/FTD/2nd_dep/refund/chargeback`
- UTC, валюти, fx-таблиця; idempotency по `event_id`
- Антифрод-поріг, white/black-лист джерел
- Дашборди: воронка, когорти, списання, SLA-метрики
- Альберти: затримка> 15 хв, CR-аномалії, chargeback-сплески
14. 2. Щотижнева рутина
- Звірка «operator↔set» по подіям і сумам
- Оновлення брекетів за якістю (за когортами)
- Ретро за креативами/лендами/джерелами в розрізі оффера
- Оновлення white/black-листів, розбір спірних кейсів
15) 30-60-90 план впровадження офферної аналітики
0-30 днів - Каркас і гігієна
Стандартизуйте модель оффера і події S2S; увімкніть idempotency, UTC, валюти.
Підніміть базові дашборди: воронка, когорти D7/D30, SLA-трекінг.
Введіть мінімальні брекети payout і пороги антифроду.
31-60 днів - Якість і економіка
Додайте chargeback/refund, 2nd-dep, Retention у звіти.
Налаштуйте індексацію CPA за якістю когорти, автоматизуйте капи і пейсинг.
Підключіть SmartLink-сигнали (white/black-лист, пріоритети).
61-90 днів - Стійкість і аудит
Впроваджуйте логи з кореляцією'click _ id/event _ id', DLQ і ретраї.
Проведіть стрес-тести S2S і звірку з BI/фінансами (NGR-консистентність).
Формалізуйте плейбуки спірних кейсів і квартальні аудити офферів.
Оферна аналітика - це не «таблиця лідів», а система: надійний S2S-контур, суворі правила валідності, когортна економіка і прозорі брекети виплат. Коли кожен оффер описаний як об'єкт з подіями, якістю і фінансами, ви швидко відрізняєте «шум» від зростання, захищаєте маржу і масштабуєте тільки ті зв'язки, які дійсно дають Payback і довгий LTV.