Most people who check whether an ad on their brand name is a problem do it wrong: they click it, watch where it lands, and judge the destination. The destination is usually the least useful part of the whole chain.
By [Author name] · 18 September 2026 · 8 min read
A branded search ad almost never links straight to a landing page. It links to a redirect, which sends the browser to another redirect, which eventually, after anywhere from one to four hops, lands somewhere a shopper can actually buy something. Knowing the shape of that chain before you go looking saves you from mistaking the wrong hop for the whole story.
The first hop, on Google, is usually the search engine's own click tracker: a URL on a Google ad-serving domain carrying a gclid parameter. That gclid belongs to Google. It's how Google's own ad platform attributes the click back to the campaign that bought it, and it tells you precisely nothing about who the advertiser is or whether they're an affiliate. I've seen people treat a gclid like it's evidence of an affiliate identity. It isn't. It's a Google-internal bookkeeping token.
The second hop is where it starts getting interesting: a redirect through the affiliate network's own tracking domain, or occasionally the affiliate's own link shortener sitting in front of that. This is the hop that usually, not always, carries the parameter that identifies who gets paid.
Sometimes there's a third hop that does nothing but decide where hop four should actually go, based on something about the request: the visitor's country, their device, whether their user agent looks like a real browser or a script. Not every chain has this hop. When it's there, it's worth paying attention to, for reasons I'll get to.
The last hop is the merchant landing page itself, the page a shopper can actually buy from. It's also, unhelpfully, the page most people write down when they're trying to document a problem, because it's the one that's visible without any extra effort.
The parameter name is different on every network, and sometimes on every program within the same network. I've seen a_aid, subid, clickref, affid, and a dozen opaque variants that are just a short alphanumeric string with no obvious meaning until you look it up against the network's own reporting. Most networks I've dealt with use something in this family; I wouldn't assume any specific one applies to yours without checking a known-good link from an affiliate you already approved.
utm_source is a separate thing entirely, and conflating it with an affiliate ID is the single most common mistake I see. A utm parameter is a labeling convention the person building the link chooses to apply. It's not issued by anyone, not verified by anyone, and trivially easy to omit, spoof, or copy from someone else's link. Treat it as a hint at best, never as proof of who's actually running an ad.
Here's the part that trips up almost everyone doing this for the first time: the identifying parameter usually lives on the second hop, the network's own tracking domain, not on the final URL. By the time the network redirects onward to the merchant, it has often already read that parameter, logged it, dropped a cookie carrying the same information, and stripped it from the URL before sending the browser on. The final landing page URL, the one everyone instinctively copies and pastes into an email as "proof," frequently carries no trace of the affiliate at all.
A chain worth documenting reads something like this, hop by hop, not summarized into a single line: the ad's own link, a googleadservices.com URL carrying Google's gclid; then a redirect to something like track.[network].com/click?a_aid=4471&subid=coupon-hub-2; then, if there's a cloaking hop, a third URL that resolves differently depending on who's asking; then the merchant's own domain, landing on a page with no affiliate parameter visible anywhere in its address bar.
The case is the second line. Everything before it is context; everything after it is where a naive check stops looking, which is exactly backwards. a_aid=4471 (or whatever the equivalent parameter and value are on your chain) is the thing you hand to the network and ask them to identify. Not the merchant URL. Not the ad's display text. That one parameter, on that one hop.
This is why a screenshot of just the landing page, with a caption like "look who's advertising on our brand," rarely survives a real conversation with a network's compliance team. It shows an ad existed and a page loaded. It doesn't show who placed the ad, and without that, there's no partner ID to check against a roster and nothing for a network to act on.
You need the whole chain, every hop, with full querystrings intact, not just the last one. In a browser, that means opening devtools, turning on "preserve log" in the network tab before you click anything, then clicking the ad and reading every request with a 301 or 302 status in order, noting the full URL of each. From a terminal, curl -sI -L on the ad's URL, read one Location header at a time rather than following blindly to the end, does roughly the same job for chains built entirely on HTTP redirects.
That caveat matters: not every hop is an HTTP redirect. Some are a meta-refresh tag or a bit of JavaScript setting window.location after the page has already loaded, invisibly to a plain curl request, which just sees a 200 and stops looking. If a chain seems to end early compared to what you'd expect, that's usually why, and you need an actual browser, or a headless one that executes JavaScript, to see the rest of it.
A timestamp, to the minute, in a timezone you note down rather than assume. The full hop sequence, in order, with querystrings intact, not summarized. A screenshot of the search results page showing the ad exactly as it rendered. A separate screenshot of the landing page it led to. That's the standard I've seen a network's own compliance team expect before they'll act on a complaint, and it's not a high bar once you know to clear it, it's just a bar almost nobody clears by accident.
Do the capture from an ordinary browsing context: logged out, not on an office IP that's been searching your own brand name all week, no ad blocker quietly rewriting the page before you screenshot it. You're trying to reproduce what an anonymous shopper actually saw, and anything that makes your request look unusual is a reason for the other side to argue the evidence doesn't reflect a real click.
Redirects that check geography or device before deciding where to send the click are the first one. An ad that behaves cleanly from a US desktop IP can send a mobile visitor in a different country somewhere else entirely, sometimes to a page with no branding at all, sometimes to a straightforwardly cloaked page built to look harmless to anyone who isn't the intended audience. If you only ever check from one location and one device, you are only ever seeing one version of a chain that may have several.
The second is subtler: some chains behave differently for a browser that's never visited before versus one carrying a cookie from an earlier visit, which matters enormously if you're re-checking a case a week after you first found it and get a cleaner-looking result the second time. That's not the problem going away. It's very possibly the chain recognizing you.
The third is the one I've personally gotten wrong before: assuming the identifier you extracted names the affiliate, when a lot of network structures allow a top-level affiliate to run sub-affiliates or sub-IDs underneath their own account. The parameter you pulled off the chain might identify a small publisher operating under someone else's umbrella, not the account holder you'd naturally assume is responsible. Whether that distinction matters to you depends on your program's terms, but it's worth checking before you name a specific partner in a complaint, because getting it wrong is the kind of mistake that's hard to walk back gracefully.
This is, mechanically, what a monitoring pass automates: following every hop, pulling the parameter, checking it against a roster, before anything reaches a person's inbox as a finished case. See how it works for the longer version of that pipeline. But the manual version above is worth knowing cold regardless of whether you ever buy anything, because sooner or later you'll need to check one chain yourself, on a weekend, without waiting on a scheduled scan.
I'll admit I still open devtools and do this by hand occasionally, on cases that look unusual enough that I don't fully trust an automated trace until I've watched the hops happen myself. That's not a knock on automating it. It's just that a chain with a cloaking hop in it is exactly the kind of thing worth seeing with your own eyes at least once, so you know what normal looks like when you're not looking at it.
Tell us your domain and the keywords that matter. We'll scope the monitoring and quote based on your program size.
Get a quote