# Ad blockers and your tracker domain

What ad blockers do to affiliate tracking, why a first-party tracker host answers most of it, and what nothing can fix.

Somewhere between a quarter and half of technical audiences browse with an ad blocker or a privacy
extension. If your partners write for developers, that's your traffic.

This page covers four things:

- what a blocker does to attribution (how a sale gets matched to the partner who sent it)
- what our tracker already handles
- what a tracker host of your own adds
- where the limit is

## What an ad blocker does to a tracker

Blockers work from filter lists: lists of domains and patterns to block. A filter can:

- stop a page loading a script from a known tracking domain
- block requests to that domain
- delete its cookies
- strip parameters from URLs

The big commercial lists mostly target third-party ad networks. An affiliate tracker gets caught in
two ways. Its script is served from a domain on a list, or its click report is sent to one.

The damage isn't always total. Let's say a blocker stops the click report but not the script. You
lose a click row and keep the sale. A blocker that stops the script entirely costs you both.

The strictest setups strip `?ref=` style parameters before any script sees them. Then there was
never anything to track.

## What the design already absorbs

Some of this is handled by how the tracker is built, before you configure anything:

- **One script, one origin.** The script is served from the same host as its click endpoint, under
  one versioned path. There's no separate CDN domain, no second beacon host, and nothing fetched
  from a third party at runtime. Fewer origins means fewer entries a filter list can match.
- **The referral survives a blocked report.** The script stores the referral in the cookie and in
  localStorage before it calls us. A blocked click request loses a row in your click count and
  keeps the attribution. The sale still binds when it arrives. This is why the
  [click count is the soft number](/guides/attribution#why-the-click-count-is-the-soft-number-and-commissions-arent).
- **Two places to store it.** A blocker or browser that clears the cookie or localStorage still
  leaves the other one carrying the referral.
- **The click report is a plain POST.** It sends no preflight request, and it survives the visitor
  leaving the page mid-request.

## The real answer: serve it from your own name

The most effective step already has a screen in the dashboard: **Reports**, **Attribution**,
**Your own tracker host**.

1. Pick a subdomain of your own site, such as `go.yourdomain.com`.
2. Follow the DNS step the dashboard gives you.
3. The script and its click endpoint are now both served from your name.

Filter lists block trackers by domain, and `go.yourdomain.com` isn't on any list. To a blocker it
looks like your site talking to itself, because that's what it is.

On Safari, it doesn't give you a longer attribution window. Here's why:

- The referral cookie moves out of the script and into the click response. Our server sets it on
  your registrable domain.
- The DNS record we issue is a CNAME, which points your subdomain at our host.
- WebKit, Safari's engine, caps cookies set through a subdomain like that at seven days. That's the
  same cap it puts on a cookie the script sets.

What carries a sale past caps like that is the billing reference, which doesn't depend on storage
surviving at all.
[The detail is on the setup page](/guides/links-and-domains#a-tracker-host-of-your-own).

Setup details, including what the dashboard checks before and after, are in
[Links and domains](/guides/links-and-domains#a-tracker-host-of-your-own). After switching, press
**Check my install** on the same page to prove the whole path works.

## What nothing can fix

A determined blocker wins, and no tracker of any brand changes that.

A visitor can:

- turn off JavaScript for your site
- use a content blocker that strips referral parameters from URLs before the page loads
- block first-party storage entirely
- browse in a mode that throws everything away on close

In each case there's no referral to capture, nowhere to keep it, or no way to report it. A vendor
claiming to recover attribution from that visitor is describing fingerprinting. We
[don't do that](/guides/attribution#consent-mode).

The practical goal has three parts:

- The ordinary majority of visitors track reliably.
- The privacy-conscious minority fail cleanly, with no half-attributed sales.
- Your commission numbers stay exact for every sale that does bind.

If a partner says their own clicks don't show, an ad blocker on their browser is the most common
cause. Their link still works for their audience. Suggest they test it in a private window with
extensions off, or watch **Attribution health** while they click.