How to read an affiliate link: redirects, IDs and cookiesHow to read an affiliate link: redirects, IDs and cookies

A review site's “Shop now” button reaches Yourbrand's affiliate manager by email. Copied, not clicked, it reads https://trk.network.example/c?pid=41207&mid=8812&clickref=autumn-guide&url=https%3A%2F%2Fyourbrand.example%2Fsale%3Fsrc%3Daff. She wants to know whose link it is, where it goes and what it leaves behind.

Everything she needs is in the address and in what happens when it's followed. This guide takes a link apart piece by piece, then follows it hop by hop, then looks at the cookies and at what each browser does with them.

The parts of the address

• Scheme: https, the protocol the browser uses.
• Host: trk.network.example, the server that answers first. On an affiliate link it's usually the network's, not yours.
• Path: /c, the page on that server.
• Query: everything after ?, a list of key and value pairs separated by &. This is where the IDs live.
• Fragment: anything after #. It's never sent to the server, so a click server can't read it unless a script on the page does.

The destination is the awkward part. Your page's address has its own ? and =, which would break the outer link, so it's percent-encoded: each awkward character becomes % and its code. %3A is :, %2F is /, %3F is ?, %3D is = and %26 is &. Decoded, url=https%3A%2F%2Fyourbrand.example%2Fsale%3Fsrc%3Daff is https://yourbrand.example/sale?src=aff, a deep link to the sale page. If you see %253A, it's been encoded twice: %25 is the percent sign itself.

The IDs

• The publisher's id (pid=41207 here): whose click it is. Every network has one, under its own parameter name.
• The programme or advertiser id (mid=8812): which brand's programme the click belongs to.
• Click references (clickref=autumn-guide): free text the publisher adds itself. A sub ID describes the click, such as a page, a placement or one of its own members. It doesn't say who ran an ad.
• The destination (url=…): the page on your site. Without one, the network sends the shopper to your programme's default page.

Parameter names differ by network, and some put IDs in the path instead of the query. Your network's documentation, or its support team, can tell you which is which. A gclid on a landing address means the visit came from a Google ad: Google's auto-tagging adds it. Some iOS traffic carries gbraid or wbraid instead.

The hops

A redirect is how one address hands the browser on to the next. There are three kinds, and a link can use all of them.

• HTTP redirects: the server answers with a status code starting with 3 and a Location header naming the next address. 301 and 308 mean permanent, 302 and 307 temporary, and 303 points the browser at a different resource. Browsers can cache a 301 or 308, so a second click may skip that hop.
• Meta refresh: the page itself carries a tag telling the browser to load another address after a number of seconds, often zero.
• Script redirects: the page's JavaScript sets window.location. A plain request that doesn't run scripts never sees this hop.

HTTP redirects run first, then script redirects, then meta refresh. A chain can be long: a short link, the publisher's own click tracker, the network, a sub-network, and only then your page. Each hop is a request to a different server, which sees the browser, the IP address and any cookies it holds for its own domain.

The cookies

Any hop can set a cookie with a Set-Cookie header: a name, a value, and attributes that say where and for how long it's sent. Domain and Path say which addresses get it back. Expires or Max-Age say how long it lasts, and without either it's a session cookie. Secure keeps it to https, HttpOnly hides it from scripts, and SameSite limits when it's sent from other sites.

Whether a cookie is first-party or third-party depends on the page you're on, not on who set it. While the browser is on trk.network.example mid-redirect, the network's cookie is first-party. When the network's tag later loads on your order confirmation page, the same cookie is a third-party cookie, and that's where browsers differ.

• Safari blocks all third-party cookies by default. It also deletes cookies written by a page's scripts after seven days of browser use without interaction with the site, and caps them at 24 hours when a known tracking domain sent the visitor to a page with a query string or fragment.
• Firefox has kept a separate cookie jar for each site since Total Cookie Protection became the default on 14 June 2022, so a cookie set in one site's context can't be read from another.
• Chrome still allows third-party cookies by default. On 22 April 2025 Google said it wouldn't introduce a new prompt for them, and in October 2025 it retired most of its Privacy Sandbox technologies.

That's why networks ask for their tag on your own pages, and many offer server-to-server tracking, where your systems report the sale with the network's click identifier taken from the landing address. Neither depends on a third-party cookie. Ask your network which your programme uses.

How to read a link, step by step

1. Copy the link without opening it: right-click the button and copy the link address, or ask the sender for the address as text.
2. Split the address at ? and &, and decode anything with % in it, so you can see each parameter and the destination.
3. List the IDs: the publisher's id, the programme id, each click reference and the destination page. Look them up in your network account.
4. Paste the link into a tracer that follows it the way a browser would, and stops at ad click links. Note every hop, how it moved on and how long it took.
5. Note each cookie set on the way by its name and the domain that set it. You don't need its value.
6. Read the final address: is it the page the destination parameter promised, and which parameters reached it?
7. Compare with your own records: does your site keep that landing address with the order, and does the network's tag fire on that page?
8. Send the network anything you can't explain, with the link, the hops and the date you traced it.

The ordinary explanations

• Extra hops: a short link from a social post, a link management tool, the publisher's own click tracker or a sub-network. Most chains have one or two.
• An unfamiliar domain setting a cookie: often the publisher's own analytics, or the network's alternative tracking domain.
• A different landing page from the one promised: an old deep link to a product that's gone, sent on to your home page by your own site.
• A parameter missing at the end: your own site may drop unknown parameters on its redirects, or the browser may strip some known tracking parameters.
• No network at all: a partner you work with directly, linking with your own tags.
• A different publisher id from the one you expected: a sub-network's members click through under the sub-network's id.

If the link came from a paid search ad, the question is a different one: where the publisher's tracking template sends the background request. Only some clicks explains that, and the glossary defines each Google Ads field involved.