How a sale gets creditedHow a sale gets credited

Every affiliate commission is the end of a chain. A shopper clicks a link, the network notes who sent them, something remembers that click, and when an order is placed the network matches the two. If the chain breaks, nobody is credited. If two publishers' chains both reach the order, the programme's rules pick one.

The tracking link

Each approved publisher gets tracking links from the network. A link points at the network's domain, not yours, and typically carries:

• the publisher's id, which says whose click it is;
• the page on your site to send the shopper to (a deep link, when it isn't the home page);
• one or more click references, which the publisher fills in itself.

That last field causes the most confusion. A sub ID (some networks say click ref) is free text the publisher adds to its own link, and neither the brand nor the network sets it. A publisher might put in the page the link sat on, a placement, a campaign name or an internal code for one of its own members. It describes a click. It doesn't say who ran an ad, which Google Ads account paid for it or which keyword it showed on.

How much of it you see depends on your network. On some, a link can carry several click references and the brand sees only the first. On others, the sub IDs are visible only to the publisher, and the brand sees a separate shared field. Ask your network which field reaches your reports. Behind the network covers what sub-networks put there.

The redirect

A plain affiliate link works by redirect. The shopper clicks, their browser calls the network's server, and the network records the click and sends the browser on to your page. The record holds the time, the publisher and the link's details and, depending on the network, the device and the page the click came from.

A network can also add its own identifier to the address your site receives, for its code on your pages to read. Ask your network which parameter to look for in your landing URLs.

Remembering the click

The order may come weeks later, and cookies are the usual way the click is remembered until then. A first-party cookie is stored under your own domain, set by the network's code running on your pages. A third-party cookie is stored under the network's domain, and is read when your pages call the network. Browsers treat the two very differently. Some block third-party cookies outright. Others partition them, so a cookie set in one site's context can't be read from another. Chrome still allows them by default, after a decision Google announced in April 2025.

So a chain that rests only on a third-party cookie can break for some shoppers, depending on their browser. That's one reason networks ask for their code on your pages: it can keep the click under your own domain. Ask your network which cookies it uses, and how it credits a sale when a browser kept none.

The tag on your pages

The network's tag is the code it asks you to add to your site. Networks usually want it on your pages, to pick up the click as the shopper lands, and on the order confirmation page, where it reports the sale: typically the order reference and value and, depending on your set-up, the currency, any discount code and a customer type or channel. If the browser carries an eligible click inside the cookie window, the sale is recorded against that publisher as pending.

Server to server

Many networks also offer server-to-server tracking, where your systems report the sale instead of the shopper's browser. Your site keeps the network's click identifier from the landing URL with the visit, and when the shopper orders, your server sends the network the order reference, the value and that identifier. Nothing depends on a browser cookie. Ask your network whether your programme uses it, alongside the tag or instead.

The order reference

However the sale is reported, it arrives with your order reference, the id your shop gave the order. It joins your records to the network's: your order system knows what was bought, when, for how much and whether it came back, and the network knows which click it credited.

De-duplication, validation and declining

If your programme de-duplicates against other channels, the sale also carries a value saying which channel won under your rules. Ask your network what yours de-duplicates against, and which field carries it.

Then validation. Each sale waits as pending while you check it against your own records (returns, cancellations, test orders, anything outside your terms) and validate or decline it. The window to decide has a fixed end, and network documentation varies:

• one network defaults to 30 days, after which a sale can't be cancelled or adjusted;
• one suggests your returns period plus seven days, up to 67 days on its entry plan;
• one recommends locking 27 days after the end of the month the sale was tracked.

A decline needs a clear reason the network accepts, and one network lists paid search outside the programme's rules among them. Paid commission rarely comes back, and on one network even approved commission can't be reversed on its entry plan. So look, record, ask, and decide while the sale is still pending. What you can do sets out the steps.

When the click starts on a Google ad

A publisher who runs paid search starts the chain from a Google ad, and Google Ads has its own fields for where a click goes:

• The final URL is the page the shopper lands on. Google takes the ad's display domain from it; the path after the domain is editable text.
• The tracking template is an address Google calls for tracking, with {lpurl} standing in for the final URL. At account, campaign and ad group level, a template must include {lpurl}. Google's Destination requirements say the template must lead to the same content as the final URL.
• The final URL suffix holds parameters Google adds to the final URL when the shopper lands, so your page can read them. ValueTrack values such as {keyword} can go there too.
• Auto-tagging adds Google's click id, gclid, to the landing URL and to the tracking template's URL. Some iOS traffic carries gbraid or wbraid instead.

So a publisher can set your page as its final URL and put its network link in the tracking template, with {lpurl} as the destination. Its ad shows your domain because it really does lead to your shop. Whether that's allowed is for your terms on direct linking. Looks like yours covers this case.

Parallel tracking

Parallel tracking has been mandatory for Search and Shopping campaigns since 30 October 2018. Today it covers Search, Shopping, Display, Video and Performance Max, and only Hotel campaigns can opt out.

When a shopper clicks the ad, their browser goes straight to the final URL. At the same time, in the background, the browser calls Google's click tracker and then the tracking template, through a browser function called sendBeacon. That background chain never reaches your shop: Google swaps {lpurl} for an address of its own, which sends back an empty response, and adds gb=1 to these calls so trackers can recognise them. Browsers that can't run parallel tracking fall back to the old way, one redirect after another.

Two things follow. First, the address bar never shows a network: the shopper sees Google's redirect, then your page with the gclid and any suffix values on it. Second, a click id the network's server creates in the background can't reach your page, because Google says that call doesn't forward to the website. Google's answer is to use {gclid} as the click id. Auto-tagging puts the same gclid on the landing URL and in the background call, so a network's tag on your page can use it as the shared key.

So following an ad's click won't show you whether anyone was credited. Only some clicks looks at what that hidden request carries. You don't need to click anyone's ad to understand a sale; your records do it better.

What you hold, and what the network holds

For every order, your own systems hold:

• the order reference, the value, the basket and whether it came back;
• the time it was placed, in your shop's time zone;
• the entry URL, if your site or analytics keeps it, with every parameter on it: a gclid, gbraid or wbraid, a network's identifier, UTM tags, values your team never set;
• GA4's session source / medium for the visit, and its Google Ads campaign.

A click from a Google Ads account that isn't linked to your GA4 property arrives as google / cpc with its Google Ads campaign (not set), and GA4 doesn't use it for Google paid-channel attribution. So a sale that began with a publisher's ad can sit in your paid search figures while the network credits a publisher. Link every Google Ads account of your own first, so that what's left unmatched is worth a look.

The network holds the other half: the click's time, the publisher id, the click references you can see and, depending on the network, the device and the referring page. A gclid belongs to the Google Ads account that paid for the click, so you can't look it up if the account isn't yours.

An order with a gclid and an affiliate credit has plenty of ordinary explanations. The shopper may have clicked your own ad on an earlier visit and come back through a publisher. An approved partner may run paid search on generic terms. Your agency may run an account you haven't linked to GA4. Side by side, the records tell you which.

1. Pick a handful of recent commissioned orders and pull your record for each: order reference, time, value, entry URL, GA4 session source / medium.
2. Put the network's record beside each: the publisher, the click time and the click reference you can see.
3. Mark any publisher-credited order whose entry URL carries a gclid, or whose GA4 session reads google / cpc with campaign (not set).
4. Send those order references to the network with a specific question, well inside the validation window.