Bot Traffic Filtering Before It Reaches Your Pixel
There is one reason bot traffic filtering belongs before the Conversions API hop: a conversion event cannot be un-sent. Every junk lead that reaches your delivery layer becomes a counted event at the platform, a poisoned training example for the optimizer, and a fake line in your reports - three costs from one bot. Your tracker is the last checkpoint where filtering is still possible, and this guide wires it: what junk traffic actually costs, which tracker filters separate bots from visitors, how filtered labels integrate with your event policy, and how to verify the stream stays clean at scale.
After delivery, what the platforms grade lives in the event quality glossary; this page stays upstream of delivery, on the filtering side. How a TDS detects bots mechanically gets its own guide in the tracker-filtering cluster.
What a Bot Conversion Actually Costs
Bots that complete forms cost money in three books at once:
- The tracker's reports. Junk conversions inflate lead counts and distort per-offer ROI, which makes every rotation and budget decision downstream wrong.
- The network's approve rate. Junk leads get rejected by the advertiser, dragging the campaign's approve rate down - and with it your standing on some networks.
- The optimizer's training data. Sent as events, junk leads teach the platform to find more of exactly what will never pay. Meta's match-quality and delivery systems grade and use what you transmit (About Event Match Quality) - a baseline period fed on junk is the most expensive case, as the warming guide explains.
The third cost is the reason filtering belongs before the CAPI hop, not after: the delivery layer can only choose what to send - once sent, the platform keeps the event. Filtering is the last moment where junk is still cheap.
What the Tracker Can Catch
Keitaro's documentation shows the filter primitives that decide which flow - or which rejection - a click meets. Its flows "distribute clicks and forward clicks to content," come in Forced, Regular, and Default types, and are gated by filters including Uniqueness, Country, Device type, and click Limits; the statistics track a Bots count, and a Bot lists setting exists among the settings (Keitaro streams documentation).
Each primitive catches a different junk pattern:
| Filter | What it separates | Junk pattern it catches |
|---|---|---|
| Uniqueness | First-time versus returning visitors | Same visitor clicking repeatedly to inflate counts |
| Device type | Desktop versus mobile versus tablet | Device profiles that never match real traffic distributions |
| Country / geo | Click origin versus campaign target | Off-target geography from proxies and bot farms |
| Click limits | First X clicks per unit | Volume spikes from scripted traffic |
| Bot lists | Known bad sources against a list | Datacenter ranges and known crawler signatures |
Filters compose: a flow chain that checks uniqueness, then device, then geo, then bot lists creates a sequence where junk fails early and real visitors pass through. Tracked Bots statistics then measure how much the chain is catching - a number worth watching per campaign, because a sudden jump in bot share usually means a new junk source, not a sudden wave of bots.
Wire Filters Before Delivery, Not After
Filtering only helps the pixel if the event policy respects it:
- Filter at the flow level. Junk clicks diverted by filters never become conversions at all - the cleanest outcome, because there is nothing to un-send later.
- Junk that converts gets a junk status. When suspicious traffic slips through and converts, the tracker's status marks it - the
trash-style status documented in Keitaro's postback contract - and the status never maps to a platform event (postback URL). - The delivery layer reads statuses, not raw rows. If the event policy from the hold status guide only maps clean statuses to events, junk conversions stay tracker-side reports by construction.
- Keep the filters monitored. The Bots statistics and the postback log - which shows "which subid initiates S2S sending, which link converted" and the source's response (S2S postbacks) - are the daily check that filtering works and nothing clean is being caught by mistake.
One boundary matters for the whole design: filtering decides what your pixel learns. It is a data-quality practice inside your own funnel - and this guide stays exactly there.
Verify the Stream Stays Clean
Filtering drifts: sources change, networks change parameters, filters over-tighten and start eating real visitors. The verification loop:
- Track the junk share per campaign over time - the tracker's bot statistics give the trend line; a spike means investigate, not ignore.
- Sample the unmatched rows in the postback log weekly: a rise in "Click for subid not found" alongside rising junk means a broken parameter on a junk-heavy branch - see the postback troubleshooting checklist.
- After every filter change, walk one real conversion through the funnel to confirm clean traffic still passes - the same test ritual as any postback change.
- Watch the platform-side quality signals in Events Manager: match quality drifting down while volumes hold is a classic sign that junk is slipping through with better-faked identifiers.
For free spot-checks of what actually reaches the platform, Pixel Activator fires named test events on demand.
Bot Traffic Filtering: Frequently Asked Questions
Frequently asked questions
Sources
Sources
- Spot-check the platform leg: Pixel Activator fires free named test events any time.
- Clean conversions only: Most delivers the events your policy approves - junk stays in reports, never in the pixel.
