Last updated: 8 September 2026
The three shapes push ads fraud actually takes once a campaign is live
Invalid traffic on this format rarely looks like the crude bot swarm most fraud explainers describe. Push ads fraud usually hides inside a stale subscriber list, a data centre range disguised as residential, or a click farm working through real devices on rotation, and all three pass a basic click and impression audit without triggering anything. Understanding which shape applies to a given source changes what filtering setting actually catches it, because a rule built for one type does almost nothing against the other two.
Stale lists as the quietest form of push ads fraud
A list sold as active can include a large share of subscribers who uninstalled the browser, revoked the permission at the operating system level, or simply stopped opening notifications from anywhere months ago. None of that shows up as a bounce or an error, because the send still registers with the platform even when nothing renders on the device at all.
Push ads fraud of this kind rarely involves any deliberate manipulation on the part of whoever collected the list originally. It accumulates naturally as browsers tighten permission handling and users clear stored data, and a network reselling the same base for a year without pruning it is passing that decay directly onto every buyer who trusts the stated size of the list.
The commercial incentive runs the wrong way for the seller to fix it voluntarily, since a larger list justifies a higher price regardless of how much of it actually renders anything, and pruning reduces the headline number a sales page can advertise.
A subscriber that never sees the notification still counts as reached
Delivery rate, the share of sends that actually reach a live device, is the metric that exposes this specific shape of push ads fraud, and very few networks publish it unprompted. Asking for it directly, and asking again after thirty days on the same base, reveals decay that a raw subscriber count will never show on its own.
A platform reporting delivery rate above the high nineties on a base older than six months deserves scepticism rather than confidence, since that figure would be unusual even on freshly collected inventory under ideal conditions.
Requesting that figure once is useful. Requesting it again on the same base after a further month of spend is more useful still, because the trend line tells a buyer whether the platform is actively pruning dead subscribers or simply letting the list decay until enough buyers complain to force a cleanup.
| Fraud shape | How it looks in reporting | What actually happened |
|---|---|---|
| Stale list | Normal send volume, weak click rate | Subscription revoked or browser uninstalled |
| Data centre traffic | Clicks with no meaningful engagement after | Server-hosted IP posing as a residential device |
| Click farm rotation | Steady click rate across many sources | Real devices cycling through paid click tasks |
Data centre ranges disguised inside push ads fraud
A click originating from a data centre IP range can still report a plausible device string and a plausible browser version, because the automation running behind it renders a normal looking user agent alongside the request. Device level filtering alone therefore misses this category of push ads fraud entirely, since nothing about the reported device looks unusual on its own.
IP range filtering against known hosting providers catches most of what device filtering leaves behind, and the better networks in this category maintain and update that list rather than shipping a static one that ages out within a few months of being built.
A source generating clicks with almost no time on page afterward, regardless of the offer, is the behavioural signature to watch for once the obvious IP ranges are excluded, since a genuine subscriber interested enough to click typically spends some measurable time on the landing page that follows.
Why an IP range check catches what a device check misses
Proxy and VPN exclusion sits alongside data centre filtering as a standard setting on most platforms now, and turning it on costs nothing in legitimate volume while removing a category of traffic that exists specifically to obscure its own origin from exactly this kind of check.
A network unable to explain what its IP filtering actually excludes, beyond a vague reference to fraud protection, is a weaker signal of protection than one able to name the specific ranges and the update frequency behind the list it maintains.
Residential proxy services complicate this further, since they route traffic through genuine home connections rather than a data centre, which defeats a simple IP range check entirely and pushes the useful signal back toward behavioural patterns rather than network origin alone.
Click farms and the limits of automated push ads fraud detection
The hardest category to catch involves genuine devices operated by real people paid to click through campaigns on rotation, since every individual signal, the device, the browser, the IP, the click itself, looks legitimate in isolation. push ads sold through lower tier resellers carry a disproportionate share of this specific risk, because the economics of cheap volume reward exactly this kind of supply.
The pattern that exposes it sits at the aggregate level rather than the individual click level: a source converting on click through rate but never converting on any downstream action, across every offer run against it regardless of vertical, geo or creative. A genuine audience segment behaves inconsistently across different offers, while a paid click farm behaves consistently badly across all of them.
push notification ads bought at a bid too low to sustain genuine subscriber engagement create the exact price point where farm traffic becomes commercially attractive to whoever is supplying it, which is part of why the very cheapest inventory in a tier correlates with the highest share of this specific fraud type.
Real devices, paid attention and why the pattern still shows
Cohort based reporting, tracking a source's conversion behaviour across multiple separate campaigns rather than a single one, is the most reliable way to surface this pattern, since a farm cannot fake genuine variance across unrelated offers the way it can fake a single campaign's numbers in isolation. Building that report takes little more than tagging each source consistently across every campaign it appears in, which most tracking platforms already support without any extra integration work.
Blacklisting a source after one bad campaign risks removing a genuinely weak but honest audience segment. Blacklisting after the same source underperforms across three unrelated offers is a much safer basis for the decision, and the extra patience costs little at any reasonable budget.
Keeping a shared blacklist across every campaign a team runs, rather than rebuilding it per offer, compounds the value of every source cut this way, since a farm identified on one vertical rarely behaves better when it shows up bidding into a completely different one a month later.
| Detection method | Catches | Limitation |
|---|---|---|
| IP range filtering | Data centre and known proxy traffic | Misses residential click farms entirely |
| Delivery rate audit | Stale or dead subscriber lists | Requires the network to report it honestly |
| Cross campaign cohorting | Click farms and paid engagement rings | Needs volume across multiple offers to work |
Building a push ads fraud checklist that actually gets used
Most fraud prevention conversations happen after a campaign has already lost money, which is exactly backwards, since every filter described here works better set in advance than applied retroactively to a source list already burning budget. A short pre launch checklist covering all three shapes takes less time to write than a single afternoon spent disputing an invoice after the fact.
What to ask a network before funding an account
Ask for delivery rate on the specific segment being bought, not a blended platform average. Ask which IP ranges are excluded by default and how often that list updates. Ask whether refunds exist for traffic confirmed fraudulent after the fact, and under what evidence standard a claim gets approved. A network answering all three specifically, rather than with a general assurance about taking fraud seriously, is worth funding first.
Putting together a client onboarding checklist meant working through several networks' filtering pages side by side, and push-ads.io stood out for how explicitly it separated the three fraud shapes covered here rather than treating invalid traffic as a single undifferentiated category, which is the more common approach across competing rate cards and one that makes the underlying protection much harder to evaluate from outside.
Push ads fraud rarely announces itself through an obvious spike anyone would notice immediately. It shows up as a click through rate that looks acceptable and a conversion rate that never quite explains itself, and catching it earlier than the third or fourth unprofitable campaign depends entirely on asking these questions before the first dollar clears rather than after. The three shapes covered here account for most of what a buyer will ever encounter on this format, and none of them require anything more sophisticated than the checklist above to catch reliably.