What is affiliate fraud?
Affiliate fraud is the inflation of clicks, leads, installs, or conversions in a partner or paid-acquisition program so a fraudster collects payouts on traffic that has no real value, often through masked IPs, recycled devices, or a single person posing as many fresh visitors. Each padded event looks like an independent visitor but traces back to a small number of real devices or networks.How ShieldLabs surfaces it
ShieldLabs answers the two questions affiliate quality turns on:| Question | What reads it | Where |
|---|---|---|
| ”Which source delivers masked traffic?” | Per-visit Risk Score + channel/UTM attribution | Traffic Sources view |
| ”Is this one device posing as many?” | The durable DeviceID under every visit | Webhook / History API |
local_ip) still surfaces the network behind the exit, so rotated public IPs that share one Local IP betray a single person.
Prevent affiliate fraud
The rule your payout code applies: on every affiliate visit and conversion, read the per-visitscore and its signals, the durable device_id, and the channel and UTM attribution, and contrast public_ip.country against local_ip.country for the masked-network case. Then:
- Dedup on
device_idinside your attribution window, so one device cannot be paid as a crowd. - Withhold or queue High-band conversions for review, and approve Medium ones on a clawback delay.
- Rank each affiliate by its masked-traffic share and device-inflation rate, so a partner sending mostly anonymous or recycled traffic moves from auto-pay to manual review.
Build it
Capture the source on every visit
Install the snippet on the landing pages affiliate and paid traffic arrives on. It records channel, referrer, and UTM attribution for every request, so the Traffic Sources tables populate with no extra work. You only need to stash the Make sure inbound affiliate links carry UTM parameters. ShieldLabs records
requestID so a later conversion ties back to the scored visit, plus the inbound UTM, since the webhook and History API return the score and identity but not the channel/UTM.landing.html
utm_source, utm_medium, utm_campaign, the referrer_domain, and the resolved channel per request; for paid traffic it also records traffic_source.click_id_type (for example gclid), surfaced in the Data export. Most affiliate traffic lands under the Referral channel, where you drill into the referrer host or utm_source to find the partner.Rank sources by risk on the dashboard
Rank each source by the anonymous-traffic share it delivers on Traffic Sources, so you measure cost per real visit instead of cost per click. The Channels table, per-referrer drill-down, and free per-request export are walked through in Measure Traffic Quality; this page covers the payout decision built on top of it.
Tie a conversion to its scored visit
When a conversion fires, read the score for the
requestID you stashed and record it alongside the affiliate and UTM. The score arrives on the webhook; cache it indexed by request_id, or fall back to a History API read by request_id. Both return the same shape: score, the explainable signals array ([{ name, weight }]), device_id, and the visit’s public_ip. Your payout logic then withholds or routes to review instead of paying automatically.api/conversion.js
Dedup one device arriving under rotated IPs
The hardest abuse to see is a single device that clears cookies and rotates its public IP between events, so each visit looks like a fresh user from a fresh location. Cookie- and IP-based dedup both fail. The durable For one network behind rotated IPs, contrast the two addresses on the webhook: two conversions with different
device_id defeats it: the same browser produces the same DeviceID after a cookie clear, an incognito window, or an IP rotation. Dedup conversions on device_id inside your attribution window, not on IP or cookie.api/webhook.js
public_ip values but the same local_ip (or local_ip.country) are a strong tell that one person is rotating exit IPs from a single network. The ip_mismatch flag already marks the disagreement for your code. A person who spreads across several separate browsers shows up as several devices, so pair device dedup with the source-level risk ranking so coordinated traffic across browsers still surfaces.Rank affiliates from the recorded conversions
With the score and DeviceID stored on every conversion, a daily job ranks each affiliate by the quality it actually delivered. This feeds your manual review queue and payout terms — there is no in-product rules engine; the ranking and the action both live in your code.A partner at the top of that list — high masked share and high device inflation — is the one to move from auto-pay to manual review, renegotiate, or hold. The decision and the threshold are yours.
jobs/rank-affiliates.js
Read a device's full history when you need it
For a borderline source, reconstruct what a single device has been doing across your whole site. Read the History API by The response is
device_id.Read a device's history
{ "data": [ ... ], "total": N }, newest first in snake_case. Distinct user_hid values on one DeviceID can mean one device behind many accounts; many countries on one DeviceID can mean a single person masking location — contrast the public country against the real internal IP country before you read it as real spread. The Patterns “Many Devices on One Account” and “Many Accounts on One Device” surface this shape automatically on the dashboard.Account History reads on
account.shieldlabs.ai are free; the Management History path bills 1 request per returned row (an empty result still bills 1). Webhooks, dashboard views, and exports are free. For high-volume affiliate flows, lean on the free webhook stream and dashboard export, and reserve billed Management reads for the cases you are about to action.Test it
Click through one of your affiliate links, then reload it in an incognito window, after clearing cookies, and again in a second browser on the same machine. Thecookie_id and visitor_id change each time, but the device_id on the webhook stays the same across the incognito and cleared-cookie runs, so the dedup above counts those as one device. A genuinely separate machine returns a new device_id — the line your payout logic relies on.
Where this fits
Measure Traffic Quality
Compute cost per real visitor by source, the reporting layer this payout logic sits on top of.
Traffic Sources view
Rank channels, referrers, and UTM by risk badge and anonymous-traffic share.
Patterns
Background detection of one-device-many-accounts and many-devices-one-account shapes.
Acting on the Risk Score
The full per-band decision playbook, including signal-aware decisioning.