Excluded IPs
Keep your team's traffic out of test results. Account-wide list of exact IPv4 or IPv6 addresses to mark as bot traffic.
Excluded IPs
Keep your team's traffic out of test results. Maintain an account-wide list of IPs (IPv4 or IPv6) whose visits are marked as bot traffic and excluded from variant assignment and reporting.
Your QA visits, your developers refreshing the staging build, your marketing team previewing copy in the office Wi-Fi — none of that is real conversion data, but all of it can quietly skew a test. Excluded IPs are the simplest way to keep that noise out of the numbers: add the IP, and Otter A/B treats requests from it the same as a known bot — tracked in raw logs but excluded from results.
Exclusion is exact-IP only. There's no CIDR or subnet matching today, so you add one address at a time. For most teams that's fine — usually you only need the public IP of your office router. For more dynamic situations, see “What if my IP changes” in the FAQ below.
Add an exclusion
- 1
Find the IP you want to exclude
Open a browser on the network you want to exclude and visitwhatismyip.com(or any equivalent). Copy the address shown — IPv4 or IPv6 both work. - 2
Open Account → IP exclusions
In Account Settings, switch to the IP exclusions tab. You'll see the existing list (if any) and a form to add a new one. - 3
Paste the IP and add a label
Paste the IP address. Add an optional label like Office Wi-Fi, VPN exit node, or Home network so future-you knows what each entry is for. Click Add. - 4
Confirm in the list
The new exclusion appears at the top of the list. Effective immediately — the next request from that IP is marked as bot traffic. Remove by clicking the trash icon next to the entry.
How matching works
- Exact string match only. If you exclude
203.0.113.42, the IP203.0.113.43is not excluded. CIDR ranges and subnets are not supported. - IPv4 and IPv6 both work. The validator accepts anything Ruby's IP library can parse. IPv6 should be entered in standard form (e.g.
2001:db8::1). - Account-wide. Exclusions apply to every project in the account. There's no per-project IP list.
- Not retroactive. Adding an IP today excludes future visits only; historical data is unaffected.
- Matches the visitor's public IP. The SDK sees the public IP of the requesting browser — not internal LAN addresses. Exclude the public IP your office router presents, not the 192.168.* or 10.* internal addresses.
Excluded IPs vs other ways to bypass tests
- Excluded IPs — persistent and automatic. Anyone on the network is excluded. Best for offices, VPNs, and known internal traffic sources.
?optimo-optout— per-page-load, works from any IP. Best when you're on a network that isn't pre-excluded (coffee shop, hotel) and still want to bypass the SDK.- Impersonation sessions — when a logged-in Otter A/B teammate “becomes” a user for support purposes, that session is automatically excluded from results too. You don't need to do anything.
Exclusion hygiene
Exclude the office router's public IP, not individual devices. The SDK sees one public IP per network regardless of how many people are behind it, so one entry covers everyone in the office.
Label every entry. A list of bare IP addresses is unreadable a year later. Label entries with the network they represent so future maintenance is easy.
Audit the list when your network changes. Office moves, new VPN provider, ISP switch — all of these can change your public IP. Re-verify the list when the underlying network changes; stale entries do nothing useful.
Don't rely on exclusion for non-team traffic. If you suspect bot traffic is leaking into results from elsewhere, that's a job for the built-in bot detection, not for IP exclusion. Reach out to support if results look skewed.
Frequently asked questions
Quick answers to the questions teams ask most about this part of Otter A/B.