Offer completion speed: how fast is too fast on an offerwall
A game that takes real players three days to reach level 30 does not get finished in eleven minutes. Speed is one of the clearest fraud signals on an offerwall, and one of the easiest to measure if you log the right events. This guide shows how.
Short answer
Log the offer click and the conversion, measure the time between them and compare it with a baseline for that offer, never with a global number. A practical rule is to flag conversions that took less than half of the offer's 10th percentile time and review them before crediting.
- Short survey
- Real users take 5 to 15 minutes; under 30 seconds is almost certainly fraud.
- App install and open
- Real users take 2 to 10 minutes; a few seconds is almost certainly fraud.
- Game level milestone
- Real players take hours to days; minutes is almost certainly fraud.
- Related signals
- Conversions without a click, duplicate transaction IDs, conversion velocity and country changes.
Why speed gives fraud away
Every offer has a natural pace. A short survey takes a few minutes. An app install with registration takes five or ten. A game milestone can take days. Real users spread around that pace. Some are quick, some slow, but very few are dramatically faster than everyone else.
Fraud breaks that pattern. Bots, scripts, modded apps, reused survey answers and forged postbacks all produce conversions that arrive far sooner than a human could finish. Networks and advertisers know this. Time to install and time to event are among the first things they check before paying.
Measure click-to-conversion time
You cannot judge speed without a start time. The start is the moment the user opens the offer from your wall. The end is the moment the network postback arrives.
- Log every offer click with the user ID, the offer ID, the time and the IP country.
- Log every conversion with the same user ID and offer ID, the network transaction ID and the amount.
- Match them. For each conversion, find the most recent click by the same user on the same offer, within a sensible window such as 30 days.
- Store the difference in seconds. That number is your click-to-conversion time.
-- Click-to-conversion time per conversion
SELECT c.id, c.user_id, c.offer_id,
TIMESTAMPDIFF(SECOND, k.created_at, c.created_at) AS seconds
FROM conversions c
JOIN offer_clicks k
ON k.user_id = c.user_id AND k.offer_id = c.offer_id
AND k.created_at = (
SELECT MAX(created_at) FROM offer_clicks
WHERE user_id = c.user_id AND offer_id = c.offer_id
AND created_at <= c.created_at)
ORDER BY seconds ASC;Build a baseline per offer
Once you have times, work out what normal looks like for each offer. The median tells you the typical pace. More useful for fraud is the fast end: the time that only the quickest 10 percent of users beat, the 10th percentile.
A practical rule: flag conversions that took less than half of that 10th percentile time. Even the fastest honest users rarely get there. Add a floor, such as 60 seconds, for offers with too little history to trust the baseline.
| Offer type | Typical real time | Suspicious | Almost certainly fraud |
|---|---|---|---|
| Short survey | 5 to 15 minutes | Under 2 minutes | Under 30 seconds |
| App install and open | 2 to 10 minutes | Under 1 minute | A few seconds |
| Install and register | 5 to 20 minutes | Under 2 minutes | Under 1 minute |
| Game level milestone | Hours to days | Under 1 hour | Minutes |
| Trial or purchase offer | Minutes to days | Depends on the offer | Seconds after click |
The numbers above are only a starting point. Your own data, per offer, will always be better. Recalculate baselines regularly, because offers change their requirements.
Signals that travel with speed
Conversions without a click
If a user gets paid for an offer they never opened from your wall, there is no start time at all. That can mean a forged or replayed postback, a user completing offers through another route, or a bug in your click logging. Check the logging first. Once you trust it, a paid conversion with no click is a strong signal.
Duplicate transaction IDs
Every network conversion has a transaction ID. The same ID arriving twice for the same offer means a replay or a duplicate. Store the IDs and ignore repeats, but also record them. A user who benefits from repeated IDs deserves a look.
Velocity
Many conversions from one account in a short time is its own warning, even if each one looks fine. Ten conversions in an hour is a lot for a real person doing real offers.
Country changes
An offer clicked from one country and converted from another is often a VPN or proxy switched on after the click. Combined with a fast conversion, it is a clear pattern.
How networks see fast conversions
Offerwall networks and advertisers look at the same data from their side. They see install time, event time and device data from the app. When your traffic shows many impossibly fast events, they reverse those conversions and may mark your site as low quality.
That matters beyond the single conversion. Networks can lower payouts, remove premium offers or pause a publisher with persistent speed problems. Catching fast conversions yourself, before the cashout, protects both your margin and your standing.
- Share what you catch. Tell your account manager which offers attract fast fraud. They often have the same problem with other publishers.
- Ask for reasons on reversals. Some networks can tell you when a reversal was for speed, which helps you tune your baselines.
What to do with a fast conversion
- Do not credit instantly when the conversion is under the threshold. Mark it pending.
- Review the account at cashout. One fast conversion may be luck; a pattern is not.
- Look at the cluster. Fast conversions on the same offer from linked accounts point to one operator.
- Deduct if the network reverses, and let the balance go negative if needed.
Keep the evidence with each decision: the click time, the conversion time, the offer baseline at that moment and the IP country of both events. When a network questions a batch, you can answer with numbers. When a user appeals, you can show exactly why the conversion was held.
A worked example
Say an install-and-reach-level-10 game offer has a 10th percentile of 40 minutes across your users. Half of that is 20 minutes. A conversion that arrives 6 minutes after the click is well under the line, so it goes to review. A conversion at 25 minutes is fast but plausible, so it is credited. If the same account also shows three other fast conversions in the same hour, the pattern matters more than any single one.
How CashoutGuard automates it
Send CashoutGuard an offer_click event when a user opens an offer and a conversion event when the postback arrives, with the offer ID and transaction ID. It matches them and builds a baseline for each offer from your own traffic.
offer_completed_too_fastwhen the time is under half the fast end of that offer, with a minimum you can set yourself.conversion_without_clickonce your site sends click events.duplicate_transactionfor repeated transaction IDs.conversion_velocityandclick_conversion_country_mismatchfor bursts and country switches.
The offer stats page shows each offer by name with its click-to-conversion speed, conversions without a click and earnings spikes, so you can see which offers attract fraud. Details are in the docs, and plans start free on the pricing page.