Ad blockers and affiliate tracking: what is actually true

What an ad blocker actually blocks

An ad blocker has no opinion. It applies a list of rules written by volunteers, published in the open, that anyone can read. The most widely used — EasyList, EasyPrivacy, the uBlock Origin lists — run to a few tens of thousands of lines, and a line looks like this:

||example-affiliate.com^$third-party
||tracking.example.net^
/affiliate-click.php$script

Three shapes, and they matter, because they are not worked around the same way.

• A domain. Everything coming from example-affiliate.com is refused. It is the most common rule and the bluntest: it looks at neither the path nor the content.
• A pattern in the address. /affiliate-click, /track/, utm_, ref=. The domain can be anything; it is the word that fires.
• A suspect hostname. track., pixel., analytics., stats., tag. used as a subdomain. Several lists treat those as tracking hosts even on a site they have never seen.

There is a fourth family, cosmetic, which hides elements of a page without blocking a request. It has nothing to do with affiliate tracking and can be set aside here.

Why affiliate platforms are on those lists

A conventional affiliate platform serves all of its customers from its own domain. Your affiliate's link looks like go.theplatform.com/xyz123, and so does your competitor's. For someone writing a filter list, that is the ideal case: one line, and tracking stops working for several thousand merchants. The effort-to-effect ratio is unbeatable, so the line gets written, and it stays.

It is not hostility towards you. It is a mechanical consequence of the platform's architecture: sharing a domain also shares the risk of being catalogued.

What it costs in practice

The visitor clicks. The browser refuses the request to the blocked domain. Two situations, depending on how the link is built:

• If the redirect goes through the blocked domain, the visitor does not arrive. They see an error page, or nothing. You lose the whole visit.
• If the link points straight at your site and only a tracking script is blocked, the visitor arrives but the click is not recorded. The sale happens, and nobody is credited.

The second case is the expensive one, because it is invisible. Your sales look normal, your affiliate does not understand why their dashboard is empty, and you have no way to decide between "they brought nothing" and "we did not count it".

The fix: serve the link from your own domain

If your affiliate's link is acme.com/a7f3c2/marie, there is nothing to block without blocking acme.com — that is, your whole site, which no list does. The cookie that gets set is a first-party cookie, on the same domain as the page the visitor is reading.

Two ways to get there, and a third worth knowing about so you can avoid it.

A reverse-proxy rule on your server

You add a rule that says: anything arriving on /a7f3c2/… is forwarded to the tracking service. One line in nginx, one rule in Cloudflare, one config file in Vercel, one form in Shopify. The visitor never sees anything but your domain, and the request has no pattern to match.

The prefix matters. /track/ or /pixel/ on your own domain gets caught by the second family of rules, the one that looks at patterns. An opaque prefix — six characters that mean nothing — is in none of them.

A subdomain you delegate

One CNAME record, and go.acme.com points at the service. Nothing to install, and the certificate is issued for you. The browser sees a subdomain of yours.

It is slightly less solid than the first option, for one specific reason: a few lists flag subdomains whose name belongs to the tracking vocabulary. Hence the simple rule: do not call that subdomain track, analytics, pixel, tag or stats.

The platform's shared domain

This is the starting case, the one that gets blocked. It has one use: checking in ten minutes that everything works before touching your DNS or your server. It is not a place to stay.

What first-party does not fix

You have to be honest about the limits, or the promise falls apart within six months.

Safari caps at seven days the cookies set by a script on a delegated domain — that is ITP behaviour, and it does not care about the attribution window you chose. On a recurring commission, seven days is obviously not enough. Browsers will also keep shortening cookie lifetimes: that is the general direction, and betting against it is a bad idea.

The conclusion is not that first-party tracking is pointless. It is that attribution should stop resting on the cookie alone.

What outlasts a cookie

The cookie does one job: connecting the click to the sale that follows it a few days later. At checkout, your server knows two things at the same time — the click id, read from the cookie, and the id you give that customer in your own system. One call saying "this click belongs to this customer" is enough to turn fragile attribution into durable attribution.

After that the cookie can disappear. The renewal in month eleven, made on another device, arrives with the customer id, and the commission lands in the right place.

The cookie brings the first sale. The customer id pays for the eleven that follow.

How to check for yourself, tonight

1. Install uBlock Origin in a clean browser.
2. Open an affiliate link from your current program. If it does not open, or if the dashboard has not seen the click a minute later, you have your answer.
3. Open the ad blocker's request log — in uBlock, the "Logger" tab. Refused requests appear there with the exact rule that refused them. That is proof, not an estimate.
4. Run the same test with a link served by your own domain.

The test takes ten minutes and requires taking nobody's word for anything. It is about the only honest thing there is to say on the subject.

Read next