CloakerHQ

How it works

Three layers, one URL

You add one script to your landing page. The first layer is what every filter in this category has. The second is the one we built, and the third is what makes it pay for itself.

What the three layers do

Network attribution, before your page renders

Runs on the request itself, using the IP address, the network it belongs to and the headers it carried.

Platform-owned ranges, declared crawler identities and datacentre networks are resolved here. This is the layer that catches the traffic which announces itself: TikTok's scanner arrives entirely on ByteDance networks, and Meta's automated crawler on Meta's own.

Two things this layer gets right that most implementations do not. Network number lookup silently returns nothing for some large ranges, so it is never the only thing checked. And the same crawler token appearing on home broadband is treated as a customer in an in-app browser, because that is what it is.

The browser environment engine, once the page has loaded

Runs for visitors the first layer could not attribute either way. This is the layer the rest of the category does not have.

Review traffic arriving from ordinary cloud addresses, with complete headers and an entirely normal user agent, is invisible to anything that decides from the request. We see it on live campaigns. No amount of server-side inspection separates it from a real visitor, because server-side there is genuinely nothing to separate.

What we run against it is a browser-environment engine built originally for the opposite problem: working out when a browser is lying about what it is. A review environment is a machine presenting itself as somebody's phone, which is the same question asked from the other side. We do not publish which signals it uses or how well each one performs, for the obvious reason.

When this layer clears a visitor, the offer is swapped in on the same URL. When it does not, or when it never runs, the compliant page is what stays on screen.

Propagation, so one verdict is not spent on one visit

Runs continuously, turning a confirmed browser verdict into an address-level label.

A browser verdict needs the visitor to stay a few seconds, which makes it precise and rare at the same time. Reading it as a verdict about a single visit throws away almost everything it is worth.

Instead, a confirmed review environment becomes a label on the address it came from, and that label covers every request from the same address afterwards, including the ones that arrive in a tenth of a second and never execute a script. It is the only route from a rare, high-precision signal to coverage of your actual traffic.

The order matters, in both directions. A filter that leads with browser fingerprinting is solving the easy half twice and the hard half not at all. A filter that only ever looks at the request never reaches the hard half. The first layer is cheap and certain, the second is expensive and rare, and the third is what makes the second worth paying for.

Why the decision happens in the browser

There are three ways to build this, and they differ in when the decision is made, which decides what evidence exists to make it with.

Request arrives First byte sent Page loaded 3-7 s dwell 10 s+ dwell The timeline a request has Redirect: IP, ASN, TLS, headers Redirect IP, ASN, TLS, headers On-page: the above, plus browser self-report On-page the above, plus browser self-report Iframe: the above, outer page stands alone Iframe the above, outer page stands alone = the moment that architecture decides; the bar is what it can see up to then
The median automated crawler session is 0.1 s, which lands before the first byte is even out. The evidence on-page filtering relies on is never produced for it.

A server-side redirect has to choose before the first byte goes out, so it only ever knows the address, the handshake and the headers. That is enough for traffic that announces itself and nothing else. Deciding on the page costs a few hundred milliseconds and buys the layer that actually separates an unattributable reviewer from a buyer.

It also inverts the default in a useful direction. A redirect has to actively recognise a crawler to withhold the offer. A page that swaps the offer in withholds it from everything that does not run scripts, without recognising anything: which is most review traffic, measurably.

What one browser sample is worth Layer two: the browser environment engine One visit runs the probes Needs seconds of dwell Rare by construction A high-confidence verdict Verdict: review environment High confidence, and rare Worth more than one visit Layer three: the label covers every later request That address enters the list Every later request from it is covered including the ones that never run a script at all
A browser verdict is expensive to obtain and therefore rare. It does not stop at the visit that produced it: it becomes an address-level label applied backwards and forwards, which is the only path from a precise but rare signal to coverage of your whole traffic.
A filter log listing visits with their origin, the reason each was filtered, which layer decided, and which page was served
Every filtered visit, with the reason and the layer that decided it. The banner at the top is the alarm that fires when a rule stops matching anything, because a rule that quietly stopped working looks exactly like a quiet week.

What you actually do

Put both pages on one URL

Your compliant page is the page. The offer is the thing that gets swapped in.

Add the script

One tag in the head. No build step, no server to run, no DNS change.

Watch the log

Every filtered visit is recorded with the reason it was filtered, so you can see whether the filter is catching review traffic or quietly hiding your offer from buyers. The second failure is the expensive one and it is the one nobody instruments.

Questions

Why decide in JavaScript rather than on the server?
Because the hardest case only shows itself in the browser. Review traffic arriving from ordinary cloud addresses with complete, unremarkable headers is invisible server-side. Deciding in the browser also means the default outcome for anything that does not run scripts is the compliant page, and most review traffic does not run scripts.
What happens if JavaScript is disabled?
The visitor sees the compliant page. That is the intended failure direction: the offer is what gets withheld when we are unsure, never the other way round.
Does the URL change?
No. The swap happens on the page. There is no redirect, no second domain and no chain for anyone to follow.
How fast is the decision?
Layer one resolves before your page renders. Layer two runs as soon as the script has loaded and does not wait for a fallback timer, because a buyer should not be looking at the compliant page while the filter makes up its mind.
What does it not catch?
A human reviewer arriving from an address we cannot attribute, on a real browser, behaving normally. Nothing in this category honestly catches that, and we would rather say so than sell you a number.

Join the waitlist

There is nothing to sign into yet. Leave an email and we will write once the private beta opens, with setup notes for the traffic source you run.

One email when it opens. Nothing else, and you can reply to be removed.