Excluding your own traffic

Why there is no IP allowlist

Every other analytics product in this category offers one, and we cannot. Excluding traffic by IP address means holding a list of IP addresses and comparing every incoming request against it — which means having the visitor's IP address at the moment of comparison and keeping yours on file. Neither is something this product does.

So the three mechanisms below all make their decision in the browser, before anything is sent. That is worse in one way: a rule does not follow you to a new laptop. It is better in another: the excluded request never happens, so there is no "we filtered it afterwards" to take on trust.

Excluding yourself

Set one flag in your browser's storage, on your own site's origin, and that browser stops sending anything at all.

localStorage.setItem('aa_ignore', 'true');

localStorage.removeItem('aa_ignore');

The value must be exactly the string true. Anything else is treated as absent, which is deliberate — a half-set flag that silently stops collecting would be far worse than one that plainly does nothing.

Send those two lines to everyone on your team. It is per browser, per profile and per device, so each person does it once on each machine they use.

This is not the same as the visitor opt-out. The opt-out is a privacy control you offer to your visitors and expose through a real interface; this is a data-quality flag for you and your colleagues. They are separate flags and neither one implies the other.

Local addresses, already excluded

Development traffic is ignored by default, with no configuration. The script sends nothing when the page is served from:

• the file: protocol, whatever the path
• localhost, 127.0.0.1 or [::1]
• any hostname ending in .local
• a page with no hostname at all

Add data-local="true" to the tag if you are deliberately testing the install and want to see events arrive. Take it out again before it ships.

The list above is exact. A dev server on 0.0.0.0, on a private LAN address like 192.168.1.20, or on a .test domain is not covered and will be counted. If your team develops against any of those, use a separate registered site for development rather than relying on this.

Excluding pages by path

Admin areas, previews, internal tools and anything behind a login are usually noise. The exclusions build lets you list paths that are never counted.

<script defer data-domain="example.com"
  data-exclude="/admin/**,/preview/**"
  src="https://cdn.absolutelyanalytics.com/aa.exclusions.js"></script>

The mirror image is data-include, which counts only the paths you name — useful when one section of a large site is the only part you care about.

<script defer data-domain="example.com"
  data-include="/blog/**"
  src="https://cdn.absolutelyanalytics.com/aa.exclusions.js"></script>

Pattern rules

• * matches within one path segment; ** crosses /.
• Patterns are separated by commas, and spaces around them are trimmed.
• A pattern matches the whole path, with one optional trailing slash. It is not a "starts with" test.
• Matching is case-sensitive, and applies to the path only — the query string and the fragment are not considered, so there is no way to exclude by query parameter here.
• Where both lists match a path, data-exclude wins.

The commonest mistake: /admin/** does not match the bare /admin index page, because there is no trailing segment for ** to match. Write data-exclude="/admin,/admin/**" to cover the section and its index together.

Checking a rule

Add a callback to a manual pageview and the script tells you which rule suppressed it — excluded for a path on the exclude list, not-included for a path missing from the include list, self-excluded for the browser flag, local for a local address. It is considerably faster than staring at an empty dashboard.

window.aa('pageview', {
  callback: (r) => console.log(r.ignored ?? 'sent'),
});