Most. Help

Bot Traffic Filtering Before It Reaches Your Pixel

Published Sep 14, 2026Updated Sep 24, 20266 min readIntermediate
Hand-drawn funnel with an orange clean stream flowing through a tracker gear into a pixel flag, while a tangled bot stream bounces off a filter gate marked with a minus sign
What you'll learn
  • What a bot conversion costs before it ever shows in a report
  • Which tracker-side filters separate junk from real visitors
  • How to wire filtered traffic into your event policy
  • How to verify the event stream stays clean after filtering
Intermediate
4views

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:

  1. The tracker's reports. Junk conversions inflate lead counts and distort per-offer ROI, which makes every rotation and budget decision downstream wrong.
  2. 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.
  3. 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:

FilterWhat it separatesJunk pattern it catches
UniquenessFirst-time versus returning visitorsSame visitor clicking repeatedly to inflate counts
Device typeDesktop versus mobile versus tabletDevice profiles that never match real traffic distributions
Country / geoClick origin versus campaign targetOff-target geography from proxies and bot farms
Click limitsFirst X clicks per unitVolume spikes from scripted traffic
Bot listsKnown bad sources against a listDatacenter 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:

  1. 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.
  2. 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).
  3. 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.
  4. 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:

  1. Track the junk share per campaign over time - the tracker's bot statistics give the trend line; a spike means investigate, not ignore.
  2. 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.
  3. 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.
  4. 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

Clean stream automation
  • 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.
Was this guide helpful?
Author
Most Team
Справочная служба

Официальные руководства и глоссарий для платформы Most и Активатора пикселей.

Topic
Affiliate Conversion Tracking: The Complete Guide
Main article of the topic
Related articles

Related guides

Affiliate Conversion Tracking: The Complete Guide

The entry point to our affiliate tracking cluster: how a conversion that lands on someone else's offer travels through a postback, a tracker, and a Conversions API call, and where each specific failure has its own deep-dive guide.

16 min

Pixel Warming Without Burning Budget: A Practical Sequence

Warming is not a ritual - it is an ordering problem. Verify delivery before spend, feed clean well-attributed events while the baseline forms, and scale on evidence. This guide turns pixel warming into the sequence buyers actually follow, with the platform documentation behind each step and the affiliate-specific twists of warming a pixel you feed by postback.

7 min

Keitaro Macros: The S2S Postback and Sub ID Reference

Every Keitaro S2S postback is a template, and the placeholders are its vocabulary. This reference collects the documented macros in working groups - identifiers, money, statuses with mappings, timestamps, campaigns and offers, geo and device - plus the sub ID fields and the encoding and currency rules that keep substituted URLs intact.

6 min

Conversion Value Payout: Passing Affiliate Payout as Event Value

A flat Purchase counts actions; a Purchase with the network's payout counts money. This guide traces the payout number from the network postback into the event's value and currency fields, then through the messy parts - partial approvals, rebills, clawbacks, and currency mismatches - to a value policy the algorithm can actually optimize on.

8 min