Referrer
Referrer is the HTTP header a browser sends along with a request, showing which page the visit came from. It's what tells you whether a click came from an in-app ad, a mobile browser, or a direct visit that bypassed the ad entirely. In arbitrage, referrer is one of the signals used to separate a genuine visitor from a moderator's direct hit or a scanning bot.
What referrer confirms, and what it hides
A matching referrer confirms a click actually originated from the expected source — a specific ad network or publisher. But referrer is trivial to spoof or strip: many browsers and in-app webviews trim it to a bare domain or drop it entirely under their referrer policy. That makes it a useful signal, never a standalone one — it should always be checked alongside other click parameters.
Referrer inside APEX's cloaking and antibot logic
A missing referrer where one is expected — say, a direct hit on the PWA link with no ad click behind it — is a classic sign of an ad-network reviewer or a scanner, and APEX's antibot factors that in when choosing between the offer and the white page. Combining referrer with user agent, IP-intel, and carrier gives a far more reliable read than any single parameter. That's the same cloaking logic already built into APEX, with no separate scripts to wire up.
FAQ
- Can referrer alone be trusted to flag a bot?
- No — referrer is routinely stripped by browsers and webviews under privacy policies, so it should always be weighed together with other signals like user agent, IP, and carrier, not on its own.
- Why is referrer sometimes empty for real users too?
- Because of browser or messenger referrer policy — some platforms and in-app browsers don't pass the header by default, which is a normal case, not automatically a sign of tampering.
Cloaking, anti-bot, push, split tests and your own domains — in one service.
Get started free