Спільне об'єднання трафіку

(Розділ: Екосистема та Мережа)

1) Що таке «спільне об'єднання трафіку»

• Максимізація конверсії і LTV за рахунок динамічної маршрутизації до «найкращого приймача».
• Зниження витрат на залучення через утилізацію незатребуваних сегментів і перехресне заповнення.
• Стійкість до сезонності і сплесків - пули згладжують піки/провали.
• Справедливий розподіл цінності при детермінованій атрибуції та прозорих правилах.

2) Моделі кооперації

1. Open Pool (публічний пул) - всі учасники з базовою сертифікацією і SLO допускаються, правила загальні, тарифи - прозорі.
2. Federated Pools (федерації) - тематичні/регіональні пули з локальними SLO/політиками (наприклад, «TR Sports», «EU Live-ігри»).
3. Private Exchange (закритий обмін) - двосторонні/багатосторонні угоди з кастомними KPI і NDA.
4. Hybrid Brokered - центральний брокер маршрутизує за правилами QoS/комплаєнсу, а розрахунок цінності робить незалежний кліринг.

Рекомендація: починати з федеративної моделі + брокер, потім розширювати до публічного пулу в міру зрілості анти-фрода і атрибуції.

3) Стандарти подій і приватність

Єдина схема подій: `view`, `click`, `signup`, `kyc_pass`, `first_deposit`, `session`, `purchase`, `churn_signal`.
Ідентифікатори: псевдонімний PID (hash/EC-псевдонім), session-id, device-фінгерпринт (строго за згодою).
Consent & Purpose: прапори згоди (ads, analytics, attribution) і TTL зберігання.
PII-мінімізація: зберігати токени і хеші; PII - тільки у первинного контролера даних.
Data residency: маршрутизація по юрисдикціях; сегрегація європейських/третіх країн.
Право на видалення: tombstone-події та redaction-журнали.

4) Скоринг якості та фільтри

• Валідність (бот-фільтри, аномалії швидкості/гео/IP-репутація).
• Намір (глибина сесій, повторні візити, pre-qualify події).
• Комплаєнс (наявність згоди, віковий прапорець, регіональна допустимість).
• Прогноз конверсії (ML score: signup→KYC→1st action→N -день утримання).

Політика допуску в пул: QoT ≥ X; підозрілі сегменти - в карантинний під-пул з ручною ревізією.

5) Маршрутизація трафіку (Traffic SOR)

Мета: віддати кожен запит/користувача кращому приймачу з урахуванням SLA і ризику.

• `TotalCost = -(Expected_LTV) + CPA/CPE + RiskAdj + TimePenalty + SaturationPenalty`

Expected_LTV - прогноз по PID/сегменту у конкретного приймача.
CPA/CPE - фактична ціна угоди/показу.
RiskAdj - санкції/юрисдикції/країна, ймовірність chargeback/fraud.
TimePenalty - затримка онбордингу/верифікацій.
SaturationPenalty - штраф при перевищенні квот або пікових навантажень.

Тактики: split-routing A/B, sticky-routing по когорті (щоб не ламати воронку), backoff/alt-path при відмовах, «warm-up» нових приймачів.

6) Квоти, ліміти та SLO

Квоти за сегментами: країна × пристрій × QoT-діапазон × годину.
Бюджети: денні/тижневі ліміти по CPA/RevShare і числу лідів.

• Fraud Rate ≤ 0. 3% лідів;
• Valid Signup Rate ≥ 75%;
• KYC Pass p95 ≤ 15 хв;
• First-Action Conversion ≥ 35%;
• ROI uplift vs control ≥ +5 п.п.
• Алерти (burn-rate): погодинні/добові гейти по Fraud/Return/Invalid-traffic, auto-throttle джерела.

7) Атрибуція і розрулювання конфліктів

Модель: last-touch з вікном, position-based (40-20-40), data-driven (Markov/Shapley) для федерацій.
Дедуплікація: `attribution_key = PID|campaign|time_bucket`.
Правила колізій: при рівному внеску - поділ за вагами довіри (QoT, історична точність).
Сертифікація джерел: рейтинг точності постбеків, штрафи за розбіжності.
Арбітраж: незалежний кліринг; raw-логи з підписами, незмінні журнали.

8) Економічна модель

CPA/RevShare/CPE гібрид: базовий CPA + бонус за утримання (D7/D30), понижуючий коефіцієнт при високому Fraud/Invalid.
Tier-pricing: нижче для стабільних QoT, вище - для «новачків».
Surge-multiplier: підвищення ціни в пік, зниження при недозавантаженні приймача.
Кешбек/кредити: часткова компенсація за ліди, які не пройшли KYC (за обумовленими правилами).
Фонд якості: загальний резерв на покриття арбітражів і force-majeure (з прозорою звітністю).

9) Анти-фрод і безпека

Device/IP/ASN граф: виявлення кластерів, повторів, семплювання ручної перевірки.
Velocity-ліміти: частота кліків/реєстрацій/депозитів, burst-детекція.
Підписи та квитанції: всі події підписані ключами джерела; крос-перевірка таймштампів.
Greylisting: джерела з аномаліями - в «сірий» пул з обмеженою часткою.
Kill-switch: миттєве відключення джерела/приймача по класах інцидентів.

10) Спостережуваність, вітрини і дашборди

SLI (приклад): Valid Traffic%, Fraud Rate, QoT середній/перцентиль, Signup/KYC/First-Action Conversion, ROI uplift, Time-to-KYC p95, Postback Accuracy.

• Ops (година): Success-rate маршрутизації, QoT, Invalid/Fraud spikes, burn-rate SLO.
• Growth (день/тиждень): конверсії за сегментами, атрибуція, ROI за джерелами, завантаження квот.
• Compliance (тиждень): санкційні хіти, регіональні порушення, SLA за запитами суб'єктів даних.
• Partner Health: рейтинг джерел/приймачів, точність постбеків, частка арбітражів.

11) Приклад схеми даних (псевдо-SQL)

sql
CREATE TABLE traffic_events (
id TEXT PRIMARY KEY,
observed_at TIMESTAMPTZ,
pid TEXT, -- alias user id source_id TEXT, sink_id TEXT,
event_type TEXT,      -- view    click    signup    kyc_pass    first_action...
qot_score NUMERIC,
attrs JSONB
);

CREATE TABLE routing_decisions (
id TEXT PRIMARY KEY,
pid TEXT, source_id TEXT, sink_id TEXT,
expected_ltv NUMERIC, cpa NUMERIC,
total_cost NUMERIC, policy TEXT,
decided_at TIMESTAMPTZ
);

CREATE TABLE attribution (
pid TEXT, conversion_event TEXT, ts TIMESTAMPTZ,
model TEXT, key TEXT, winner_source TEXT, share NUMERIC,
PRIMARY KEY (pid, conversion_event, key)
);

12) Псевдо-конфігурації (YAML)

Політика допуску та квот

yaml pool_policy:
min_qot: 60 quarantine_qot: 45 fraud_max_pct: 0. 3 quotas:
- segment: "TR    mobile    high_intent"
hour_cap: 5000
- segment: "EU    desktop    mid_intent"
hour_cap: 3000

Маршрутизація (Traffic SOR)

yaml routing:
split_max_parts: 3 stickiness_hours: 72 penalties:
saturation_perc_start: 80 saturation_bps_per_perc: 15 time_ms_per_minute: 3 backoff:
errors_threshold_pct: 2. 0 cooldown_sec: 900

Алерти SLO

yaml alerts:
- name: "fraud_spike"
when: "fraud_rate>0. 4%"
action: ["throttle_source","notify_security"]
- name: "qot_drop"
when: "qot_p50<55"
action: ["greylist_source","raise_cpa_multiplier"]
- name: "postback_mismatch"
when: "postback_accuracy<98%"
action: ["open_arbitrage","reduce_quota"]

13) Приклади аналітичних запитів

QoT розподіл за джерелами

sql
SELECT source_id,
PERCENTILE_CONT(0. 5) WITHIN GROUP (ORDER BY qot_score) AS qot_p50,
PERCENTILE_CONT(0. 9) WITHIN GROUP (ORDER BY qot_score) AS qot_p90,
AVG(CASE WHEN event_type='signup' THEN 1 ELSE 0 END) AS signup_rate
FROM traffic_events
WHERE observed_at >= now() - INTERVAL '7 days'
GROUP BY source_id;

Точність постбеків

sql
SELECT sink_id,
100. 0 SUM(CASE WHEN report. conversion_ts BETWEEN ev. observed_at - INTERVAL '5m'
AND ev. observed_at + INTERVAL '5m'
THEN 1 ELSE 0 END) / COUNT() AS postback_accuracy_pct
FROM conversions ev
JOIN partner_reports report USING (pid)
GROUP BY sink_id;

ROI uplift vs контроль

sql
WITH scored AS (
SELECT pid, sink_id, expected_ltv, actual_ltv, cohort
FROM ltv_eval WHERE date >= current_date - INTERVAL '30 days'
)
SELECT sink_id, cohort,
AVG(actual_ltv) - AVG(expected_ltv) AS uplift
FROM scored
GROUP BY sink_id, cohort;

14) Операційні регламенти

Щодня: звірка звітів атрибуції, аудит постбеків, коригування квот/цін.
Щотижня: комітет якості - перегляд min QoT, оновлення анти-фрод правил, звіт по арбітражах.
Щомісяця: калібрування ML-скорингів, ревізія моделей атрибуції, бенчмарки приймачів.
Інциденти: єдиний канал статусів, шаблони комунікацій для джерел/приймачів.

15) Playbook інцидентів

Сплеск Fraud/Invalid-traffic

Авто-throttle джерела, переклад в «сірий» пул, посилення velocity-лімітів, ручна вибірка 100 кейсів, звіт ≤ 24 год.

Провал постбеків/розбіжності

Включити дублюючі вебхуки, порівняти контрольні логи, відкрити арбітраж, тимчасово знизити ціни/квоти джерелу.

Стрибок затримок КУС/онбордингу

Перемаршрутизація на приймачі з швидким KYC, повідомлення джерел, тимчасове зниження stickiness.

Перевантаження приймача (saturation)

Спрацював штраф маршрутизації → перерозподілити частку, включити split-routing, підняти ціну для пріоритетних сегментів.

16) Чек-лист впровадження

1. Затвердіть єдину схему подій і політику приватності/згоди.
2. Запустіть QoT-скоринг і карантинний під-пул.
3. Увімкніть Traffic SOR з квотами/лімітами та stickiness.
4. Налаштуйте SLO/алерти якості та постбеків, заведіть дашборди.
5. Визначте економіку (CPA/RevShare гібрид, штрафи/бонуси, фонд якості).
6. Введіть процеси арбітражу, підписів логів і незалежний кліринг.
7. Щоквартально ревізуйте моделі атрибуції та скоринги.

17) Глосарій

QoT - інтегральний показник якості трафіку.
Traffic SOR - «розумна» маршрутизація трафіку за повною вартістю/ризиком.
Stickiness - закріплення користувача за приймачем для стабільності воронки.
Postback Accuracy - точність звітів приймача про конверсії.
Attribution Arbitration - процедура вирішення конфліктів атрибуції.
Saturation - ступінь завантаження приймача/каналу.

Підсумок: спільне об'єднання трафіку перетворює розрізнені потоки в керовану, справедливу і ефективну систему зростання. Комбінація єдиних подій і приватності, QoT-скорингу, SOR-маршрутизації, строгих SLO і чесної економіки створює «загальний ринок попиту», де виграють і джерела, і приймачі, і користувачі екосистеми.