Tracking guide
Fraud signals overview
How click and conversion fraud is scored, the signal catalogue, rule packs, lists, partner risk and what happens to flagged traffic.
Fraud detection is built into the click path and the conversion path, scores everything the same way, and explains every decision. The engine is the shared go-shared/fraud package used by the edge, ingest and the nightly batch.
Scoring model
Each signal that fires contributes a weight between 0 and 100. The click or conversion score is a noisy-OR of the fired weights, 1 - product(1 - weight/100), rounded and capped at 100, so several weak signals add up without a single one dominating. The score and the list of fired signals ("reasons") are stored on the event, and the explain view in the admin portal shows each reason with its weight.
A rule pack maps score bands to actions:
| Mode | Intent |
|---|---|
strict | Lower thresholds, higher weights. |
balanced | Default weights and bands. |
lenient | Only clear abuse is acted on. |
custom | Your own weights, disabled signals and bands. |
Packs can be scoped to the whole tenant, an offer or a partner (the most specific wins, then lower priority number). A pack in dry-run scores and records but does not act. Without any pack the engine runs in dry-run, so you can watch scores before turning enforcement on. Click bands map to mark (flag only), block (invalid click) or fail_traffic (reroute); conversion bands escalate the conversion status (for example to flagged) and never downgrade it.
Tunable parameters include the minimum click-to-install time (default 10 s), flood windows and limits (default 60 s window; 30 clicks per IP, 300 per sub1, 3000 per partner), device repeat limit, conversion velocity per partner, duplicate-IP limit per day, the conversion-rate baseline and anomaly factor, night-time hours and the SDK version floor.
Signals
Click-time signals run on the edge in microseconds; conversion signals run in ingest; some run in the nightly batch over recent history (DT_FRAUD_BATCH_HOUR, DT_FRAUD_WINDOW_DAYS).
| Group | Signal codes |
|---|---|
| Network | ip_datacenter, ip_proxy, ip_vpn, ip_tor, ip_blocklist |
| Device and client | bot_ua, headless, ua_anomaly, ua_missing, duplicate_device |
| Click behaviour | click_flooding_ip, click_flooding_sub, click_flooding_partner, click_spam_frequency, time_of_day_anomaly |
| Source | geo_not_targeted, referer_missing, referer_mismatch_declared_source, referer_blocked |
| Lists, partners and vendors | deny_list, partner_risk_blocked, vendor_score |
| Conversion timing | ctit_too_short, ctit_too_uniform, event_before_click |
| Conversion patterns | conversion_burst, cr_anomaly, txn_id_pattern, subid_concentration, geo_mismatch |
| Identity | duplicate_device_conversion, duplicate_email_hash, duplicate_ip_conversion, repeat_user_id, disposable_email, self_referral |
| Mobile | install_hijack_pattern, sdk_spoofing, device_id_empty |
| Carry-over | click_fraud_score (half of the click's score carries into the conversion) |
The authoritative list, with default weights and which side each signal applies to, is the catalogue the admin rule-pack editor reads; the default weights for each mode are in packages/go-shared/fraud.
Lists and partner risk
- Allow and deny lists hold values of type
ip,ip_cidr,device,email_hash,user_id,sub_id,asn,isporreferrer_domain, for every partner or one partner. They feedip_blocklistanddeny_list. Manage them under Fraud and through/fraud/lists. - Partner risk is a 0 to 100 score with a letter grade (A under 20, B, C, D, F at 80 and above), computed by the nightly batch from the flagged-conversion rate, fraud-rejected rate, share of very short click-to-install times, datacenter/proxy/VPN/Tor click rate, bot rate, multi-partner cluster hits, click-to-install divergence, a Benford's-law test and conversion-rate anomaly, each weighted. A partner whose score reaches the pack's
block_partner_scoreis blocked at the edge. - Vendor adapters (IPQS, Anura, 24metrics, Forensiq) enrich asynchronously from the review queue; no vendor call is made while a click is being redirected.
What happens to flagged traffic
- A blocked click is stored as invalid with the fraud reason and routed to fail traffic. It is never billed.
- A flagged conversion gets status
flagged(reasonfraud_scorewhen the matched click's score is 80 or more) and appears in the fraud queue for review. - Reviewers approve, reject or open a case that groups related items. Bulk decisions re-state conversions through ingest, and the ledger consumer reverses any earnings already booked.
- Clawbacks reverse conversions that were already paid; restating them through ingest makes the ledger consumer post the reversal against the partner balance.
- Reporting exposes
fraud_scoreand fraud reason dimensions, and thefraud_findingstable records every finding for audit. Alerts such as "fraud spike" can be created from the automation presets.
Everything is explainable: for any click or conversion, Insights, Logs shows the score, each signal that fired and the pack that applied. See the fraud API reference for queue, cases, packs, lists, vendors and clawbacks.