Traffic Filtering

An experiment result is only worth acting on if the visitors behind it were real customers making real decisions. Traffic that isn't real (a search engine crawler, a teammate checking the new headline, a marketer clicking a preview link) still gets counted unless something stops it. A vs B stops it.

Every event A vs B collects is labelled with where it came from. Results only count visitors labelled live. Everything else is kept, but kept out.

What gets excluded

There are three kinds of traffic A vs B keeps out of your results.

Bots

Crawlers, uptime monitors, headless browsers, and scripted tools are detected automatically from what the visitor's browser reports about itself. You don't have to configure anything.

This matters more than it sounds. A crawler visits every page and never buys anything. Because it lands in every variation roughly equally, it drags every variation's conversion rate down together, which makes a real difference between them look smaller than it is. Enough bot traffic and a genuine winner reads as "no clear difference".

Bot detection happens on our side, not in the browser, so it can't be faked by the visitor.

Preview traffic

When someone opens a preview link to review a variation before launch, they are seeing the experiment on the real site. Those visits are tagged as preview and excluded automatically.

Without this, the people reviewing an experiment would be quietly skewing the very experiment they're reviewing.

Internal traffic

Your own team. There are two ways to mark it, and you can use both:

  • A marker link: anyone on your team opens the site once with ?avsb_internal=1 on the end of the URL, and that browser is excluded from then on.
  • Project rules: office IP ranges and browser markers, set once for the whole project, so nobody has to remember to do anything.

Marking your own browser as internal

Add ?avsb_internal=1 to any page on your site and load it once:

Plain text
https://www.example.com/?avsb_internal=1
Plain text1 line

That's it. A vs B remembers this browser for a year and leaves everything it does out of your results: every page, every experiment, not just the page you marked. The marked visit itself is excluded too, so you don't need to load the link before doing anything.

To undo it and be counted as a normal visitor again:

Plain text
https://www.example.com/?avsb_internal=0
Plain text1 line

A few things worth knowing:

  • It's per browser, not per person. Mark Chrome and your Safari visits still count. Same for a second laptop, or a phone.
  • It's remembered with a cookie. If someone clears their cookies, they'll need to open the marker link again.
  • It's per site, so mark each domain you test on.

This is the quickest option for a small team, and it works with no setup.

Project rules for internal traffic

For anything bigger than "a few people, a few browsers", set rules once at the project level and stop thinking about it.

Go to Settings → Traffic. You'll find two lists there, and both are optional. Two kinds:

The Traffic tab: set up internal IP ranges and browser markers to keep your own team out of results.
  1. The Traffic tab, in the settings tab strip.
  2. The Internal IP addresses list and its add input.
  3. The Browser markers list and its add input.
  4. The Save rules button.

Internal IP addresses: visitors coming from these addresses are treated as internal. Written in CIDR notation, which is the standard way to describe a block of addresses:

RuleWhat it covers
203.0.113.42One specific address
203.0.113.0/24256 addresses: 203.0.113.0 to 203.0.113.255
10.0.0.0/8A large private range, common for office networks
2001:db8::/32An IPv6 range

If you don't know your office's IP address, search the web for "what is my IP" from an office connection, or ask whoever runs your network.

Browser markers: text to look for in what the browser reports about itself. Useful when your team is remote and has no shared IP: a QA tool or a browser extension that adds a recognisable word can be matched here. Matching ignores capitalisation, and a match anywhere in the text is enough.

Both lists are optional. Leave them empty and bot and preview traffic are still excluded, those never need configuration.

Rules are checked as you add them. If a range is written in a way A vs B can't read, the entry is refused on the spot and tells you what a valid range looks like, rather than accepting it and quietly never matching anything. You can have up to 50 of each.

Saved rules take effect for new visits within about 30 seconds.

What happens to excluded traffic

Excluded visits are not deleted. They're stored with a label and left out of the numbers.

This is deliberate. If A vs B threw the data away, "excluded" would be invisible, and you'd have no way to tell a quiet week apart from a week where half your traffic was a crawler. Keeping the rows means the platform can show you what was excluded and why, and it means an over-eager rule is something you can spot and fix, not a silent hole in your data.

Seeing what was excluded

When a result has had traffic filtered out, the results page says so, just under the filter bar:

20 visitors excluded (bots, preview traffic, internal traffic)

Click it for the breakdown: how many of each. If nothing was excluded, nothing is shown.

This line is the point of the whole feature. A number that quietly changed is worse than a number with a caveat: if your visitor count drops after you add an office IP range, you should be able to see that it was your rule that did it, not a bad week. The same line appears on experiment results and on feature-flag rule results.

Warning

Very occasionally the results page may say "Traffic filtering is not active". That means the platform could not apply the filter for this read, so the numbers you're looking at do include bots, preview visits, and internal traffic. It's a caveat on a real number, not an error: the counts are genuine, they're just unfiltered. It clears itself up; if it persists, it's a configuration issue on our side rather than anything you can fix from here.

Info

Changing your internal-traffic rules only affects traffic collected from that point on. Visits already recorded keep the label they were given when they happened. Rules are not applied retroactively, so results you've already looked at won't shift under you.

Common questions

Does excluding traffic slow my experiment down? It changes what counts, not how fast you collect. If a lot of your traffic was bots, your visitor numbers will look lower than before, but they'll be honest, and the decision you make from them will be sound. A smaller true number beats a bigger false one.

I marked my browser but I'm still seeing my own visits counted. Check that you're on the same browser you marked, that cookies haven't been cleared since, and that you marked the same domain you're testing on. If your team is on a shared office network, project IP rules are more reliable than per-browser markers.

Can a visitor exclude themselves to skew my results? Someone could mark their own browser, which only removes their own visits. They can't mark anyone else, and they can't add themselves back into results they were excluded from: bot detection runs on our side and isn't something the browser can talk its way out of.

Do excluded visitors still see the experiment? Yes. Filtering changes what gets counted, not what gets shown. A teammate marked as internal still sees whichever variation they'd normally get, which is exactly what you want when they're checking that it looks right.

Was this helpful?