Traffic pooling
(Section: Ecosystem and Network)
1) What is "traffic pooling"
Collaborative traffic pooling is a mechanism in which ecosystem participants (operators, studios, storefronts, affiliates/aggregators, ad networks, payment/identity providers) share the flow of users/requests/events into a common pool according to the agreed rules of quality, privacy and remuneration. Objectives:- Maximize conversion and LTV by dynamically routing to the "best receiver."
- Reduce acquisition costs by disposing of unclaimed segments and cross-filling.
- Resistance to seasonality and bursts - pools smooth out peaks/dips.
- Fair value distribution under deterministic attribution and transparent rules.
2) Cooperation models
1. Open Pool (public pool) - all participants with basic certification and SLO are allowed, general rules, tariffs are transparent.
2. Federated Pools (federations) - thematic/regional pools with local SLO/policies (for example, "TR Sports," "EU Live Games").
3. Private Exchange - bilateral/multilateral transactions with custom KPIs and NDAs.
4. Hybrid Brokered - the central broker routes according to QoS/compliance rules, and the value calculation makes independent clearing.
Recommendation: start with a federated model + broker, then expand to a public pool as anti-fraud and attribution matures.
3) Event standards and privacy
Single event schema: 'view', 'click', 'signup', 'kyc _ pass', 'first _ deposit', 'session', 'purchase', 'churn _ signal'.
Identifiers: pseudonymous PID (hash/EC-pseudonym), session-id, device-fingerprint (strictly by consent).
Consent & Purpose: consent flags (ads, analytics, attribution) and TTL storage.
PII minimization: store tokens and hashes; PII - primary data controller only.
Data residency: routing by jurisdictions; segregation of European/third countries.
Right to delete: tombstone events and redaction logs.
4) Quality scoring and filters
Quality of Traffic (QoT) - integral score 0-100, composition:- Validity (bot filters, velocity anomalies/geo/IP reputation).
- Intent (depth of sessions, repeat visits, pre-qualify events).
- Compliance (availability of consents, age flag, regional admissibility).
- Conversion forecast (ML score: signup→KYC→1st action→N -day hold).
Pool admission policy: QoT ≥ X; suspicious segments - to a quarantine sub-pool with manual revision.
5) Traffic SOR
The goal: to give each request/user to the best receiver, taking into account SLA and risk.
Path cost function:- `TotalCost = -(Expected_LTV) + CPA/CPE + RiskAdj + TimePenalty + SaturationPenalty`
Expected_LTV is the PID/segment prediction for a particular receiver.
CPA/CPE is the actual deal/display price.
RiskAdj - sanctions/jurisdictions/country, probability chargeback/fraud.
TimePenalty - onboarding/verification delay.
SaturationPenalty - penalty when exceeding quotas or peak loads.
Tactics: split-routing A/B, sticky-routing by cohort (so as not to break the funnel), backoff/alt-path in case of failures, warm-up of new receivers.
6) Quotas, limits and SLOs
Segment quotas: country × device × QoT range × hour.
Budgets: daily/weekly limits on CPA/RevShare and lead count.
- Fraud Rate ≤ 0. 3% leads;
- Valid Signup Rate ≥ 75%;
- KYC Pass p95 ≤ 15 min;
- First-Action Conversion ≥ 35%;
- ROI uplift vs control ≥ +5 п.п.
- Alert (burn-rate): hourly/daily gates for Fraud/Return/Invalid-traffic, auto-throttle source.
7) Attribution and resolution of conflicts
Model: last-touch with window, position-based (40-20-40), data-driven (Markov/Shapley) for federations.
Deduplication: 'attribution _ key = PID' campaign 'time _ bucket'.
Collision rules: with equal contribution - division by confidence weights (QoT, historical accuracy).
Source certification: postback accuracy rating, discrepancy penalties.
Arbitration: independent clearing; signed raw logs, unchanging logs.
8) Economic model
CPA/RevShare/CPE hybrid: basic CPA + retention bonus (D7/D30), reduction factor at high Fraud/Invalid.
Tier-pricing: lower for stable QoT, higher for "beginners."
Surge-multiplier: increase in price at peak, decrease in case of underutilization of the receiver.
Cashbacks/credits: partial compensation for leads that have not passed KYC (according to the agreed rules).
Quality fund: general reserve for arbitration and force-majeure (with transparent reporting).
9) Anti-fraud and safety
Device/IP/ASN graph: identifying clusters, repetitions, sampling manual verification.
Velocity limits: frequency of clicks/registrations/deposits, burst detection.
Signatures and receipts: all events are signed with source keys; cross-checking timestamps.
Greylisting: sources with anomalies - in the "gray" pool with a limited share.
Kill-switch: instantaneous disconnection of the source/receiver by incident class.
10) Observability, display cases and dashboards
SLI (example): Valid Traffic%, Fraud Rate, QoT mid/percentile, Signup/KYC/First-Action Conversion, ROI uplift, Time-to-KYC p95, Postback Accuracy.
Dashboards:- Ops (hour): Success-rate routing, QoT, Invalid/Fraud spikes, burn-rate SLO.
- Growth (day/week): conversions by segment, attribution, ROI by source, quota load.
- Compliance (week): sanctioned hits, regional violations, SLAs at the request of data subjects.
- Partner Health: source/receiver rating, postback accuracy, arbitrage share.
11) Data Schema Example (Pseudo-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) Pseudo Configurations (YAML)
Tolerance and quota policy
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
Routing (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 Alerts
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) Examples of analytical queries
QoT distribution by source
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;
Postback accuracy
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 control
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) Operating Regulations
Daily: reconciliation of attribution reports, audit of postbacks, adjustment of quotas/prices.
Weekly: quality committee - revision of min QoT, update of anti-fraud rules, report on arbitrations.
Monthly: calibration of ML scoring, revision of attribution models, receiver benchmarks.
Incidents: single status channel, communication templates for sources/receivers.
15) Playbook incidents
Fraud/Invalid-traffic spike
Auto-throttle source, transfer to the "gray" pool, increase in velocity limits, manual sampling of 100 cases, report ≤ 24 hours.
Failure of postbacks/discrepancies
Enable duplicate webhooks, compare control logs, open arbitration, temporarily lower prices/quotas for the source.
CSC/onboarding delay jump
Rerouting to fast KYC receivers, reporting sources, temporarily reducing stickiness.
Receiver overload (saturation)
The routing penalty worked → redistribute the share, enable split-routing, raise the price for priority segments.
16) Implementation checklist
1. Approve a unified event schema and privacy/consent policy.
2. Run QoT scoring and quarantine sub-pool.
3. Enable Traffic SOR with quotas/limits and stickiness.
4. Set up SLO/quality alerts and postbacks, start dashboards.
5. Identify the economy (CPA/RevShare hybrid, penalties/bonuses, quality fund).
6. Enter arbitration processes, log signatures and independent clearing.
7. Review attribution and scoring models quarterly.
17) Glossary
QoT is an integral indicator of traffic quality.
Traffic SOR - smart routing of traffic at full cost/risk.
Stickiness - assigning the user to the receiver for funnel stability.
Postback Accuracy - Accuracy of receiver conversion reports.
Attribution Arbitration is a procedure for resolving attribution conflicts.
Saturation - receiver/channel utilization.
Bottom line: Pooling traffic together turns disparate flows into a managed, fair and efficient growth system. The combination of unified events and privacy, QoT scoring, SOR routing, strict SLOs and a fair economy creates a "common demand market" where sources, receivers, and ecosystem users win.