Fraud detection for offerwall networks: score every publisher
A network pays its publishers for conversions and gets paid by advertisers who audit them later. When a publisher sends fraud, the network is caught in the middle: it already paid the publisher, and the advertiser takes the money back. This guide shows how to see the fraud per publisher before either happens.
Short answer
Score fraud per publisher, not only per user: rank publishers by flagged payout and flagged share, keep each publisher's users apart with publisher:user account IDs, and check both the click and the postback. Run a week in shadow mode and compare the flags with last month's reversals before acting.
- Per-publisher metrics
- Flagged share, flagged payout, linked accounts and offer speed.
- Account namespaces
- publisher:user, so accounts are only linked inside the same publisher.
- Integration points
- The offer click and the postback; both calls fail open after two seconds.
- Plan for networks
- Pro covers 400,000 monthly active users and 10 sites; larger networks get volume pricing.
Why the network is the one that pays
Fraud on an offerwall rarely starts at the network. It starts on a publisher: a GPT site or a rewards app where someone runs dozens of accounts behind VPNs or on emulators. Those accounts complete offers, the network records the conversions and pays the publisher on its normal schedule.
Weeks later the advertiser runs its own checks, finds installs from the same devices, IPs that do not match the targeted country and users who never opened the app again, and reverses the conversions. The publisher has been paid. The network absorbs the reversal or starts a slow dispute.
Look at fraud per publisher, not per user
A network sees millions of end users across hundreds of publishers. Reviewing users one by one does not scale. The useful unit is the publisher: what share of its conversions came from VPNs, emulators, linked accounts or offers completed impossibly fast, and how much money that represents.
- Flagged share. The percentage of a publisher's conversions flagged for review or block. Honest publishers sit low and stable; a sudden jump usually means a farm found them.
- Flagged payout. The dollars behind those conversions. A small publisher with 60% flagged matters less than a large one with 15%.
- Linked accounts. How many of the publisher's users share a device or a payout address. Multi-accounting is the most common pattern on GPT sites.
- Offer speed. Conversions that arrive faster than the offer allows point to bots or incentivised shortcuts.
Keep each publisher's users apart
User IDs are only unique inside a publisher. User 1001 on one GPT site has nothing to do with user 1001 on another. If the fraud engine mixes them, it links strangers and floods you with false positives.
CashoutGuard's network mode namespaces accounts as publisher:user, so accounts are only linked within the same publisher, while devices and networks are still checked across everything the network sees. A phone farm that moves from one publisher to another is still the same set of devices.
The signals that matter for networks
| Signal | What it catches | Why advertisers care |
|---|---|---|
| VPN, Tor, datacenter IP | Traffic hiding its real country | Geo-targeted offers paid for the wrong country |
| Residential proxy patterns | Timezone and language that do not match the IP, WebRTC leaks | The same, but invisible to IP lists |
| Emulators and VMs | Android emulators, virtual machines, automation tools | Installs that never become real users |
| Device shared by accounts | One phone or browser behind many accounts | Duplicate installs and bonus abuse |
| Payout address shared | Several accounts cashing out to one wallet | Clear multi-accounting on the publisher side |
| Offer completed too fast | Conversions faster than the offer allows | Fake completions and forged postbacks |
Patterns networks see most often
The farm that changes publishers
A group of devices signs up on one GPT site, burns through the high-paying offers and moves on when the site starts holding cashouts. On the network side the same phones and emulators reappear under a new publisher a few days later. Comparing devices across publishers catches the move on the first conversions instead of after the next reversal.
The publisher who is the farm
Some "publishers" are the fraud: a site built to send traffic from a room of phones. The signs are a very high share of emulators or shared devices from the first day, almost no organic growth and offers completed at the same minute of every hour.
Bonus hunters and incentive abuse
Real people can still be fraud. Users who create a new account for every sign-up bonus, or who complete an app install and uninstall within minutes, are real humans but worthless to advertisers. Linked accounts and offer speed expose them.
Reading the per-publisher report
The report ranks publishers by flagged payout. For each one you see conversions, the flagged share, the dollars at risk and how many flagged accounts are linked. Start at the top: a publisher with a high flagged payout and a rising share is where a conversation, a hold or a pause saves the most money.
Treat a flagged share as a question, not a verdict. Some audiences use VPNs for privacy and some countries route mobile traffic through carrier proxies. When one reason dominates a publisher's flags, open a few accounts and check whether it is fraud or simply how that audience connects. Rules let you lower the weight of a reason for your network if it turns out to be normal there.
Integration: the click and the postback
A network already handles two moments: the click, when the user leaves the offerwall for the advertiser, and the postback, when the advertiser confirms the conversion. Those are the two calls to add.
- Offerwall page: load the browser script so each user's device is scanned while they browse offers.
- Click handler: send an offer_click event with the publisher, the user and the offer before redirecting.
- Postback handler: send a conversion event with the payout and transaction ID. The answer tells you whether to credit it normally, hold it or flag it.
$r = $cg->evaluate([
'event' => 'conversion',
'account_id' => $publisherId.':'.$userId, // publisher:user namespace
'source' => (string) $publisherId,
'offer_id' => $offerId,
'transaction_id' => $transId,
'amount' => $payoutUsd,
'currency' => 'USD',
]);
$status = $r->isBlocked() ? 'hold' : 'approved';Both calls fail open: if CashoutGuard is slow or unreachable, the SDK answers allow after two seconds and your postbacks keep flowing.
Rolling it out without upsetting publishers
- Shadow mode for a week. Nothing is held or blocked. You get the per-publisher report and can compare it with the reversals you already know about.
- Talk to the worst publishers first. Show them the data. Most honest publishers are glad to hear about a farm on their site, and many will fix it themselves.
- Hold, do not reject. Put blocked conversions on hold until the advertiser's validation window closes. Release them if the advertiser approves.
- Adjust payouts by quality. Publishers with consistently clean traffic can get faster payments; risky ones wait for validation.
Next steps
Read the case study of a US offerwall network that ran CashoutGuard in shadow mode for 24 hours, the postback security guide and the chargebacks guide. The Pro plan covers several sites and 400,000 monthly users; see pricing or contact us for network volumes.