Home / Blog

How Affiliate Tracking Works

Cookies, click IDs, server postbacks and mobile attribution, explained without the marketing: what each one measures, where each one fails, and why a 30 day window is a promise your server has to keep.

By Nora Ellis, Affiliate Marketing & Creator Economy Writer · with Wooly Network, Editorial · 16 September 2026 · 7 min · Tracking & Attribution

Affiliate tracking works by attaching a unique reference to a partner's link, storing that reference when the visitor lands, and sending it back to the network when a conversion happens. There are three ways to send it back: from the browser, from the advertiser's server, or from a mobile attribution provider. Only the last two are reliable, and the reason is worth understanding in detail.

Three methods compared: browser tag, server to server postback, and MMP postback

One of these runs in a browser you do not control. The other two do not.

The click: where the reference comes from

A tracked link carries an identifier, usually as a query parameter. The redirect through the network records the click and issues a unique click ID, then sends the visitor on to the landing page, typically with that ID appended.

At the moment of the click, a well built network also freezes the campaign terms onto it: commission rate, payout model, attribution window and validation rules as they stand right then. That freeze is what makes the commission calculation defensible weeks later, and it is covered in how affiliate commissions work.

The whole redirect should take a few tens of milliseconds. If a network's redirect is slow, you lose real conversions on mobile before the page ever renders, which is a good thing to test rather than assume.

Storing the reference: the cookie, and its problems

Classically, the landing page stores the click ID in a first-party cookie for the length of the attribution window. This works, right up until it does not, and the reasons it does not are now the normal case rather than the edge case.

Obstacle	What actually happens
Safari Intelligent Tracking Prevention	Any cookie written by JavaScript is capped at seven days, and at 24 hours when the visitor arrived on a link carrying tracking parameters from a classified domain. Your 30 day window silently becomes a 7 day one.
Ad and content blockers	The script never loads, so nothing is stored and no conversion is ever reported.
Cross-device journeys	Clicked on a phone at lunchtime, bought on a laptop that evening. The cookie is on the wrong machine.
In-app browsers	Taps from social apps often open a sandboxed browser whose storage does not survive the app being closed.
Third-party cookies	Blocked by default in Safari and Firefox. Google kept them in Chrome after reversing its deprecation plan in April 2025, and later wound down most of Privacy Sandbox, so the landscape stays split rather than settled.

The honest summary: browser storage is a convenience layer, not a system of record. Designing a payout system on top of it means paying partners less than they earned, silently, and mostly on the platforms where your best traffic comes from.

Server to server postbacks, which is the actual answer

The durable design is to capture the click ID once, store it with the order in your own database, and have your server tell the network when the order is confirmed.

The flow:

The visitor lands with a click ID in the URL. Your site stores it, ideally in a server-set cookie rather than a JavaScript one, since server-set cookies are not subject to the same client-side lifetime caps.
When an order is created, you save that click ID as a field on the order, next to the total and the customer.
When the order is confirmed, your backend calls the network's endpoint with the click ID, the order reference and the value, authenticated with a shared secret.
When an order is refunded, your backend calls the refund endpoint the same way.

What this buys you is everything the browser cannot do: sales completed by phone, by invoice, on a payment link, or by a customer with an ad blocker; subscription renewals that happen with no browser present at all; and refunds, which are the difference between a programme that reconciles and one that argues.

Two implementation details that separate working setups from broken ones:

Sign the request. An unauthenticated conversion endpoint is an endpoint anyone can post fake sales to. The usual shape is an HMAC signature over a timestamp, the request and the body, checked inside a short window so a captured request cannot be replayed tomorrow.
Send an order reference and deduplicate on it. Retries happen. Without a stable reference, a retry becomes a second commission.

On Wooly Network: the tag and the signed server webhook are set up on the same Integration page, and both doors are documented step by step in installing your tracking tag and connecting the server webhook.

Mobile: a different problem entirely

There is no thank-you page in an app install, and the tap happens in a browser while the install happens in the App Store or Play Store. That gap is what mobile measurement partners exist to close: AppsFlyer, Adjust and Branch match the click to the install, then forward the install and any in-app events to your partners by postback.

Practically, if you are running app install campaigns, your affiliate tracking is an integration between your MMP and the network, not a tag on a website. Wooly Network's version of that is documented in how to track app installs.

Attribution: deciding who gets credit

Tracking answers "did it happen". Attribution answers "who gets paid", and it is a policy decision rather than a technical one.

Rule	Credit goes to	Consequence
Last click	The most recent partner before the sale	Industry default. Favours partners near the checkout, like coupon sites.
First click	The partner who introduced the customer	Favours content and discovery. Harder to enforce across devices.
Split	Divided between partners in the path	Fairer in principle, and much harder to explain in a payout statement.

Most programmes run last click because it is simple and unambiguous. If you run it, the honest move is to control the partner mix through your campaign terms rather than to complain about the rule you chose. The brands guide covers the incrementality version of this argument.

Fraud, and the signals that catch it

Click fraud in affiliate marketing is ordinary. The patterns that give it away are usually behavioural rather than technical:

Impossible speed. A conversion seconds after a click, repeatedly. Nobody reads a checkout page that fast.
Repetition from one source. Many clicks from a single address or device fingerprint in a short window.
No interaction. A session with a click and a conversion and nothing in between: no scroll, no movement, no time on page.
Cookie stuffing. Clicks recorded for people who never clicked anything, often through hidden frames or auto-loading images.
Brand bidding. Not fraud exactly, but it intercepts customers who were already yours, which is why it belongs in the validation rules.

These signals are far more useful pooled across many campaigns than they are inside a single advertiser's data, which is one of the less obvious arguments for a network over a self-hosted script.

Testing that it actually works, before you recruit anyone

Click your own tracked link and confirm the click is recorded, with the click ID visible in the landing URL.
Complete a real test order, ideally with a real payment you refund afterwards.
Confirm the conversion appears, with the correct value and the correct commission.
Refund the test order and confirm the reversal arrives.
Repeat the whole thing in Safari on a phone, with cookies restricted. This is the test that finds the problem.

Doing this before recruiting is not caution, it is economics: a partner who publishes into broken tracking has spent their credibility on you and got nothing back, and they will not do it twice.

Once all five checks pass, you are ready to recruit. On Wooly Network the tag, the server webhook and the creator marketplace sit in one account; see the affiliate tracking and campaign tools for brands.

Common questions

How long do affiliate cookies last?

The programme sets a window, commonly 30 days, but the browser sets the real limit. Safari caps JavaScript-written cookies at seven days. If the window matters commercially, it has to be enforced server side.

Does affiliate tracking work without cookies?

Yes, and increasingly it has to. The click ID is stored with the order in the advertiser's own database and reported from the server, which never touches the browser's storage after the first page load.

Will a tracking tag slow down my site?

A properly built one loads asynchronously and adds no render-blocking work. If a vendor's tag is synchronous, that is a reason to ask questions.

What is a click ID?

A unique reference generated at click time that identifies the partner, the campaign and that specific visit. It is what your server sends back at conversion, and it is what makes attribution possible without cookies surviving.

Can two partners be credited for the same sale?

Under a standard last-click rule, no. Under a split model, yes, by design. Whichever applies, it should be stated in the campaign terms rather than discovered in a payout statement.