Block-Before-Serve: Stopping Ad Fraud Before the Impression Fires

Most invalid-traffic tools tell you about fraud after it has already happened. They sit downstream, tally the bad impressions and invalid clicks, and hand you a report. By then the impression is spent, the advertiser has a record of it, and — the part that actually matters — the invalid click is already on your ad-network account's ledger. A report doesn't undo any of that.

Block-before-serve flips the order. Instead of measuring fraud after the fact, it decides whether a visitor is valid before the ad call ever fires, and suppresses the ad request when the answer is no. This post explains how that works, why the timing is the whole game, and how PubSentry implements it without ever risking a real reader.

Why "after the fact" is too late

Think about what an ad impression actually is. When a page loads, your ad stack — Google Publisher Tag, AdSense Auto Ads, Amazon's apstag, Prebid — fires a request into the auction. A bid comes back, a creative renders, and an impression is logged on the advertiser's side, on your network's side, and in your own analytics.

If a bot triggered that sequence, three irreversible things have already happened by the time a downstream tool notices:

• The impression is wasted. Inventory that should have served a real reader was consumed by nobody.
• The advertiser has a record of an invalid impression sourced from your inventory — the kind of thing that drives clawbacks and quietly lowers your bids.
• An invalid click or impression is on your account. This is the dangerous one. Ad networks, AdSense above all, monitor your traffic for invalid activity and can suspend an account over it. For an ad-funded site, that's not a bad day — that's the business.

You cannot retract an impression that already fired. The only place to win is before the ad request leaves the page.

How block-before-serve works

PubSentry installs as a single async JavaScript tag — no SDK, no plugin:

<script async src="https://pubsentry.com/t.js" data-site="st_xxxx"></script>

When the page loads, the tag does three things in the right order.

1. Score the visitor locally, in under 5ms

The tag runs a battery of browser collectors — automation tells (navigator.webdriver, tampered native functions, automation globals), environment and fingerprint coherence, behavioral and temporal signals, and honeypot traps — and feeds them into the shared scoring engine on the page itself. No network round-trip is required for the verdict, so the gate decision lands in single-digit milliseconds. Every collector is fail-open: if anything errors, the visitor is treated as valid and the ad serves. The tag must never delay or break the host page.

2. Gate the ad stack before it fires

This is the mechanism that makes "block" meaningful. When the score says a visitor is invalid, the tag doesn't just log it — it holds the ad call back at the source, across every major ad path:

• Google Publisher Tag (GPT): requested slots are destroyed inside the googletag.cmd queue, so the slot never goes to auction.
• AdSense / Auto Ads: adsbygoogle.push() is wrapped so pushes are swallowed while blocked.
• Amazon apstag: fetchBids returns no bids.
• Prebid.js: the auction is short-circuited with an empty bid set.
• A universal MutationObserver fallback catches anything else that tries to inject an ad slot.

The result: for an invalid visitor, no ad request is ever made. There's no impression to waste, no invalid click to defend, and nothing for your account to be penalized for. The fraud is stopped at the only point where stopping it is still possible.

3. Beacon the verdict server-side for the record

After the gate decision, the tag sends a lightweight beacon to the ingest service. There the request is enriched (datacenter / ASN / geo from an offline IP dataset), re-scored by the same engine, and persisted so your dashboard can explain every verdict. Raw IP and user-agent are hashed server-side with HMAC-SHA256 and then dropped — never stored in the clear. The verdict that protected the page came from the local gate; the beacon is what makes it auditable.

For repeat and cross-page visitors, an edge worker can return a cached reputation verdict in tens of milliseconds, so a known-bad entity is recognized fast without re-deriving everything from scratch.

The non-negotiable: this only works if it never blocks a human

A gate that suppresses ads is powerful, which means it's also dangerous if it's wrong. Blocking a real reader is the single worst outcome an IVT tool can produce: it's lost revenue and lost trust, with no upside, and it churns the exact visitor you wanted to keep. So block-before-serve is governed by one principle above all others: a false-positive rate of zero comes first.

In practice that means the gate only blocks on hard evidence — a request that is provably inconsistent with a real human on a real browser. An automation flag. A tampered native function. A honeypot hit. A spoofed Chrome fingerprint with contradictory geometry. A datacenter IP that no normal reader browses from. These are facts, not probabilities, and they're safe to act on without touching genuine readers.

Here is the honest boundary, because it's a product principle and not fine print:

• Obvious / GIVT invalid traffic — the tell-leaving stuff above — is gated at near-100% recall with zero false positives. This is what protects your account from invalid-traffic suspensions today.
• Sophisticated / SIVT mimicry — bots on residential proxies that scrub every tell and look identical to a human per request — is only partially caught by deterministic rules, by design. You cannot block it from a single request without also blocking the real human on a VPN, on mobile carrier NAT, or in a privacy browser. That gap closes through the cross-site reputation network, velocity-and-anomaly detection at scale, and the ML layer as the network grows — not by blocking more aggressively.

We will never tell you block-before-serve stops 100% of fraud. Anyone who claims that is either over-blocking real humans to inflate the number or not measuring honestly. What it does do is stop the obvious invalid traffic at the only moment that counts, and protect the account that the dangerous clicks would otherwise threaten.

The takeaway

Counting fraud after the ad serves is a postmortem. Block-before-serve is prevention: a sub-5ms local verdict that suppresses the ad call across GPT, AdSense, apstag, and Prebid before an invalid visitor can cost you an impression, an advertiser's trust, or — worst of all — your ad-network account. And because it only fires on hard evidence, it does that without ever blocking a real reader.

Want to watch it run on your own traffic? You can start free — one async tag, 500 pageviews on the house, every detection feature included, no card. Drop in the tag and watch the verdicts land in real time at app.pubsentry.com.