Every invalid-traffic tool has to answer one question: where do you make the decision? On the visitor's browser, with JavaScript? Or on your own servers, after the request arrives? The two approaches see completely different things, fail in completely different ways, and — this is the part most write-ups miss — neither one is sufficient alone.
This post breaks down what each layer can and can't see, why the timing of the verdict is as important as its accuracy, and how PubSentry uses both so that the obvious fraud gets blocked before the ad fires while nothing escapes the record.
What client-side detection sees
Client-side detection runs in the page, in the visitor's browser, while it loads. That vantage point is unique: it's the only place that can observe the actual runtime environment of the visitor.
A browser-side collector can read things that never leave the device otherwise:
- Automation tells —
navigator.webdriver, CDP markers, automation globals, native functions that have been monkey-patched by Puppeteer or Selenium. - Environment coherence — does the screen geometry, timezone, language, and capability set match the user agent's story? A "Chrome on Windows" UA with contradictory
WebGLrenderer strings is a tell you can only catch in the runtime. - Behavioral and temporal signals — pointer movement, scroll cadence, the timing between events.
- Honeypot traps — invisible elements a real user never touches but a naive automation script will.
The other thing client-side gives you is time. The browser is where the ad call originates, so it's the only place you can decide before the ad request fires. That's the premise of block-before-serve: a local verdict in under 5ms lets the tag suppress the GPT slot, the AdSense push, the apstag bid, or the Prebid auction before an invalid visitor ever consumes an impression.
The catch is that the client is hostile territory. Your code runs on the attacker's machine. A sophisticated bot can patch the very functions you use to inspect it, feed you a fabricated environment, and read your detection logic to learn what to fake. Anything observed client-side can, in principle, be spoofed client-side. That doesn't make the signals worthless — most invalid traffic doesn't bother — but it means you can never fully trust the browser to be honest about itself.
What server-side detection sees
Server-side detection runs on your infrastructure, after the request arrives. It can't see the runtime environment the way the browser can, but it sees things the browser will never volunteer.
When a beacon hits the ingest service, the server has the real connecting IP and the raw request headers. From those it can derive:
- Network intelligence — is this a datacenter IP (AWS, GCP, Azure, a hosting range) that no normal reader browses from? What ASN and geography does it map to? PubSentry resolves this from an offline iptoasn dataset, so there's no per-request API cost and no key. (Honest caveat: an offline ASN feed does not identify residential-proxy, VPN, or Tor exits; those stay
unknownuntil you add a paid IP-intelligence feed behind the same interface.) - Header coherence — the true ordering and contents of request headers, which an automation framework often gets subtly wrong, independent of whatever the JavaScript reported.
- Velocity and reputation across requests — how many requests this entity has made, how fast, and what its history is. A single browser can lie about itself; it cannot easily hide the aggregate pattern of a thousand requests.
- A tamper-resistant re-score. The server runs the same engine again on enriched data. If the client-side beacon was forged, the server's view of the network and velocity won't match the story the browser told.
Server-side is authoritative because it sits outside the attacker's reach. But it has one structural limitation: by the time the server sees the beacon, the page has already loaded. A purely server-side tool is a measurement layer — it can tally invalid traffic and feed reputation, but on its own it cannot stop the impression that already served.
Why the timing gap matters
Put the two limitations side by side and the trade-off is stark:
- Client-side can decide in time to block the ad, but runs on hardware the attacker controls.
- Server-side is trustworthy but arrives after the ad request has already left the page.
A tool that is only client-side can be gamed by a determined bot. A tool that is only server-side is always one beat too late to prevent the impression — and the dangerous thing about invalid traffic isn't the wasted impression, it's the invalid click landing on your AdSense or ad-network account, the kind that triggers suspensions. You want that stopped before it happens, not logged after. The resolution isn't to pick one — it's to run both as layers with different jobs.
How PubSentry uses both layers
PubSentry runs one shared scoring engine in three places — browser, edge, and server — so the verdict logic is identical everywhere and there's no drift between "what the tag thinks" and "what the dashboard shows."
Client-side: the fast gate. The tag scores the visitor locally in under 5ms and, on hard evidence, blocks the ad across GPT, AdSense, apstag, and Prebid before the request fires. Every collector is fail-open — any error means the visitor is treated as valid and the ad serves, because the tag must never break or delay the host page.
Edge: the cached verdict. A worker returns a known entity's reputation verdict in tens of milliseconds, so a repeat bad actor is recognized fast.
Server-side: the authoritative record. The beacon hits ingest, which enriches the request with network/ASN/geo intelligence, re-scores with the same engine, updates reputation and velocity, and persists the event. Raw IP and user-agent are hashed with HMAC-SHA256 and then dropped — never stored in the clear. This is the layer that catches a forged beacon, feeds the cross-site reputation network, and makes every verdict auditable.
The division of labor is deliberate: the client gates in time, and the server keeps everyone honest — including a client that's been tampered with.
The honest boundary
Two layers are stronger than one, but they don't make the hard problem disappear. Obvious, tell-leaving invalid traffic (GIVT) is caught at near-100% recall with zero false positives across both layers — that's what protects your account today. Sophisticated mimicry (SIVT) — residential-IP bots that scrub every client-side tell and present a clean-looking network origin — is only partially caught from any single request, by design: blocking it harder would mean blocking real humans on VPNs and mobile carrier NAT, and a false-positive rate of zero comes first. That gap closes through the reputation network, anomaly-at-scale, and the ML layer growing over time — never by claiming 100%.
The takeaway
Client-side detection has the timing to block before the ad fires but runs on untrusted hardware. Server-side detection is authoritative but arrives after the impression. PubSentry runs the same engine on both: the tag gates in under 5ms on hard evidence, and ingest re-scores on enriched, tamper-resistant data to keep the record honest and feed the network. One layer for speed, one for trust.
Want to see both layers run on your own traffic? You can start free — one async JS 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.