How Fraud Defense works
Every tap on a tracking link passes our traffic checks before the user reaches the advertiser’s store page or site. A tap we refuse never reaches the advertiser, so nobody pays for it, and the offer stays live for everyone else.
See also: Fraud Defense
On this page
At the tap
Before we send the user on, the tap goes through our checks. A refused user sees “This offer isn’t available for your account” and is asked to choose another offer. It never reads as an ended offer, so a screenshot tells us the tap was refused, not that the offer is gone.
The usual reasons: several users behind one device or connection, or the user is on the publisher’s reject list.
On the user
When a user’s traffic fails our checks, they go on the publisher’s reject list for 30 days. Their conversions are still recorded, with the status rejected: they pay $0, send no postback and don’t count in reports. Their later taps are refused.
Publishers see each rejected user, the offer and the reason in plain words under Reporting, then Traffic Quality.
On the publisher and offer pair
We keep comparing each publisher’s traffic on each offer with other traffic and with its own history. When it looks wrong, the pair is held: the users behind the flagged taps are rejected, other users keep converting as normal and our team reviews the pair. Releasing it pays the rejected users again. Rejecting it pauses that offer for that publisher; conversions from taps already sent still settle.
On the conversion
For some publishers and offers, a conversion waits for a person to approve it. While it waits, it pays nobody, sends no postback and doesn’t appear in the publisher’s reports. Approved, it settles as normal. Rejected, it is never paid.
Some rejections also take back what was already paid on that user’s earlier conversions, each as a standard reversal with the reason in plain words.
| Reason the publisher sees | How far back |
|---|---|
| Multiple accounts detected on the same device | 7 days before the rejection |
| Emulated devices | 30 days |
| Duplicate accounts detected | 30 days |
| IP mismatch / VPN or proxy detected | 30 days |
| Role | What you see |
|---|---|
| Publisher | Refused users see the message after a tap. Rejected users are on Traffic Quality and show rejected on Conversions. Take-backs arrive as reversals with a reason. |
| Advertiser | Nothing from a refused tap: it never reaches your store page or site, so it never carries an afos_click_id and no event can be charged against it. If a channel looks wrong, choose File a report under Reports, or Report an issue on the channel’s row. A report doesn’t pause traffic by itself; our team investigates. |
| Network | Your publishers’ taps go through the same checks as any publisher’s. |
Example, made up: one phone in Texas opens Pebble Rewards under several user IDs in one afternoon and taps Harbor Blocks under each of them.
- The phone is blocked for 30 days. Every tap from it now shows “This offer isn’t available for your account”, whatever user ID it carries.
- The user IDs go on Pebble Rewards’ reject list. Pebble Rewards sees them on Traffic Quality, each with its reason and the date it expires.
- Any conversion they still produce is recorded as
rejected: $0, no postback. - Harbor Blocks stays live for every other Pebble Rewards user.
- Testing on one phone. Trying many test user IDs on one device looks the same as the example above. Use one test user per device. If your test phone gets blocked, tell us the user IDs you tried and our team can lift it.
- A refused tap is not an ended offer. “This offer has ended” means the offer is gone. “This offer isn’t available for your account” means this tap, from this user or device, was refused.
- No thresholds here. We don’t publish the signals or limits our checks use. A published limit is one people stay just under.
- Our own team decides holds. The monitor can raise a pair to held; only a person releases or rejects it.