Google Tag Manager Conversion Linker: Complete Setup Guide

Between 20 and 40% of your paid traffic will never fire the conversion linker tag. You can configure it perfectly, publish it, watch it turn green in preview mode, and it will still be dead on arrival for a fifth to two-fifths of the visitors you are paying Google to send you.

I have set up the conversion linker more times than I can count, across client accounts, agency builds, and my own projects. The mechanical part takes four minutes. The part nobody documents is what happens after you publish, on the real traffic, in the wild. That is where the honest version of this guide lives.

This is not a "here is where to click in GTM" post, although I will give you that too, because you need it. This is a post about a tag that the entire internet treats as a solved problem and that is, for a significant slice of your traffic, structurally broken before it ever runs.

The honest read: the conversion linker fixes a real attribution problem for the users who can run it, and it does nothing at all for the users whose browser blocked the GTM container in the first place. The standard setup is necessary and incomplete. The complete fix is architectural, and that is the part DataCops addresses.

Quick stuff people keep asking

What does the conversion linker do in Google Tag Manager? It reads ad-click identifiers, mainly the GCLID for Google Ads, from the landing-page URL and writes them into first-party cookies, the _gcl_* cookies. Later, when a conversion fires, your conversion tags read those cookies so Google can attribute the conversion to the click that caused it. Without it, the click identifier is lost after the first page and attribution breaks.

Do I need a conversion linker tag in GTM? If you run Google Ads conversion tracking or Floodlight through GTM, yes. It is what carries click attribution across pages and across the cookie-lifetime gap. Skip it and you will systematically under-report conversions and feed Google a broken signal.

Where should I place the conversion linker tag in GTM? On an All Pages trigger, firing as early as possible. It needs to run on the landing page where the GCLID arrives in the URL, before the visitor clicks away. All Pages, Initialization or as high-priority as you can set it.

Does the conversion linker work with ad blockers? No. This is the part the guides skip. The conversion linker is a tag inside the GTM container. If an ad blocker or privacy browser blocks the GTM container script from loading, no tag inside it runs, including the linker. For 20 to 40% of users, the linker never executes at all.

What is a GCLID and why does the conversion linker need it? GCLID is the Google Click Identifier, a unique string Google appends to your landing-page URL when someone clicks your ad. It is the thread connecting the click to the conversion. The linker's whole job is to catch that thread off the URL and store it in a cookie before it disappears.

How does ITP affect the GTM conversion linker? Safari's Intelligent Tracking Prevention caps the lifetime of script-set first-party cookies, often to seven days, sometimes 24 hours. The linker's _gcl_* cookies are script-set, so on Safari they can expire well inside a normal consideration window. The tag fired correctly. The cookie just did not survive long enough to be read at conversion time.

What is the difference between conversion linker and enhanced conversions? The conversion linker preserves click-to-conversion attribution using cookies. Enhanced conversions sends hashed first-party data, like an email, to recover conversions where cookies failed. They solve overlapping problems. After Google's April 2026 change unified the enhanced conversions setting, more accounts have it on by default, but it is still not a substitute for the linker, and it has its own collection dependencies.

Why are my Google Ads conversions not being tracked in GTM? Run the checklist. Linker not on All Pages. Linker firing after the conversion tag instead of before. Conversion tag not set to use the linker data. And the one people miss: the GTM container itself blocked for that user, which makes every other check irrelevant.

How to set it up, the standard steps

You need this, so here it is, clean.

Create the tag. In GTM, go to Tags, New, choose tag type Conversion Linker. There is nothing to configure inside it for a standard setup. The defaults handle GCLID and the other _gcl_* parameters.

Set the trigger. Use the All Pages trigger so it runs everywhere. If your account has an Initialization trigger available, or you can set firing priority, push the linker to fire as early as possible. It must run before any conversion tag.

For cross-domain tracking, if your funnel spans multiple domains, configure auto-linking domains in your Google Ads tag settings and enable the relevant cross-domain options so the GCLID is passed in the URL between domains. The linker on the receiving domain then catches it.

Publish and verify. Use GTM Preview mode. Load a page with a test ?gclid=test123 parameter. Confirm the linker tag fires and that the _gcl_aw cookie gets written. Then submit the container version.

That is the setup. It is correct. It is also the point where every other guide stops, and that is the problem.

The gap: the linker is dead on arrival for a fifth of your paid traffic

Here is what Preview mode will never show you. Preview mode runs in your browser, with no ad blocker, with the container loading perfectly. It is a clean room. Your real paid traffic is not a clean room.

Between 20 and 40% of real users run an ad blocker or a privacy browser that blocks the GTM container outright. uBlock Origin, the built-in shields in Brave, and similar tools recognize the GTM domain and stop the container script from loading. When the container does not load, nothing inside it runs. The conversion linker is inside it. So for that 20 to 40%, the linker tag does not fire, the GCLID is never captured, the _gcl_* cookie is never set, and the conversion, if it happens, is reported back to Google as an unconverted click.

This is the layer the official docs and the vendor tutorials do not disclose. The conversion linker is itself a client-side script, and it inherits every weakness of client-side scripts. It cannot fix attribution for a user whose browser already blocked the machinery it lives in. You configured it perfectly. It is still blind to a large minority of the exact traffic you paid the most for.

There is a second, quieter failure on top of the blocking. For the users who do load the container, the linker writes cookies, but on Safari, ITP caps how long those cookies live. So even a perfectly-fired linker can lose attribution simply because the visitor took eight days to convert and the cookie expired on day seven. The tag did its job. The browser undid it.

And there is a race condition worth knowing about on single-page apps. On an SPA, route changes do not always reload the container or re-run tags in the order you expect. A conversion event can fire on a virtual page view before the linker has finished its work, and the attribution data is simply not there yet when it is needed.

Stack these up. Blocking removes 20 to 40% of executions. ITP shortens the attribution window for much of the rest. SPA timing drops more. The conversion linker, treated as a finished solution, is actually a partial filter, and the part it misses is invisible from inside GTM.

What that blind spot does downstream

This is not just a reporting inconvenience. The missing conversions become a corrupted signal.

Google Ads optimizes bidding on the conversions you report. Every blocked, expired, or mis-timed conversion is reported back as a click that did not convert. So Google learns that the campaigns, keywords, and audiences attracting privacy-conscious, ad-blocking users perform worse than they actually do. It bids them down. It shifts budget toward whatever segment happens to still report cleanly.

The result is the same compounding problem that haunts all client-side tracking. The data is not just incomplete, it is biased, and the bias trains the algorithm to mis-allocate your budget away from real customers who simply could not be measured.

It gets worse if you consider what does still get through. Of the traffic that is recorded, a meaningful share is non-human anyway, 24 to 31% of web traffic is bots. So your conversion data is simultaneously missing real humans the linker could not reach and padding the dataset with bot sessions that should never have counted. You are optimizing on a sample that is wrong in both directions.

The architectural fix, kept honest

The conversion linker is doing what it was designed to do. The problem is the layer it lives on. A tag inside a client-side container can only ever be as reliable as that container, and the container is blockable.

The structural fix is to move collection off the blockable client-side path. First-party architecture that runs on your own subdomain captures far more of your real traffic, because it is not a recognizable third-party script that ad blockers target on sight. It is far more resilient. On top of that, the incoming data gets filtered for non-human traffic at the point of ingestion, so the 24 to 31% bot share is caught before it pollutes your conversion counts. And the clean, more complete conversion signal is what gets sent onward through CAPI to Google and the other platforms, so the optimizer learns from real humans instead of from a measurement artifact.

That is what DataCops does. It does not replace the conversion linker as a concept. It removes the dependency on a tag that a fifth of browsers refuse to run.

Plainly: DataCops is a newer brand than the established tag-management and server-side names, and SOC 2 Type II is in progress, so a regulated buyer may want to factor that timeline. It improves collection resilience and filters bots, it does not promise that nothing is ever missed, because no honest tool can. What it changes is the structural ceiling. The conversion linker's ceiling is "whatever the browser allows." First-party architecture raises that ceiling.

Decision guide

You run Google Ads conversions through GTM. Set up the conversion linker. It is necessary. Just do not assume it is sufficient.

Your GTM conversions look about 20 to 40% lower than expected. That is almost certainly container blocking, not a config error. Stop re-checking the tag and look at the layer it runs on.

A lot of your audience is on Safari. Expect ITP to expire linker cookies inside your consideration window. Enhanced conversions helps, server-side collection helps more.

Your site is a single-page app. Audit linker-versus-conversion-tag timing on route changes. The race condition is real and silent.

You are about to scale Google Ads spend. Fix the collection layer first. Scaling spend on a 20-to-40% blind signal scales the mis-allocation.

Green checkmarks are not coverage

The mistake I see on nearly every account is this: the conversion linker tag is green in Preview, so it is filed under "done." Green means the tag is configured correctly. It does not mean the tag is running on your traffic. Those are two completely different claims, and the gap between them is 20 to 40% of the people you paid the most to reach.

Set up the linker. Then go find the part it cannot see, because Google is already pricing your bids on it.

So here is the question for your next account audit. Of the paid clicks you bought last month, how many actually ran the conversion linker, and how would you ever know from inside GTM?