Крипто-казино
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-фингерпринт, списки источников.
Рег-фрод: совпадения документов/KYC, пачки ночных регистраций, низкий engagement.
FTD-фрод: «бонусные» депозиты, возвраты, «карусель» платежей.
Реакция: авто-заморозка выплат по офферу/сабу, расследование, акты-сверки, корректировки payout.
9) Дашборды офферной аналитики (обязательный набор)
1. Воронка по офферу: клики→рег→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. Еженедельная рутина
- Сверка «оператор↔сеть» по событиям и суммам
- Обновление брекетов по качеству (по когортам)
- Ретро по креативам/лендам/источникам в разрезе оффера
- Обновление 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.