Google is merging the Google tag (gtag.js) and Google Tag Manager into a unified product, and most analytics teams have no idea what this means for their existing containers, conversion tracking, or migration path. PPC Land broke the story, the official Google docs have started shifting language around “Google tag” as the umbrella product, and Slack channels are filling up with confused developers asking whether their gtag snippets are about to break.
Short answer: nothing breaks tomorrow. Longer answer: the way you think about web tagging architecture is changing, and if you run multi-property setups or mixed gtag/GTM deployments, you need a plan before Google starts deprecating the old admin surfaces.
I’ve been migrating clients between gtag and GTM for years, and I’ve spent the last few weeks pulling apart what the merger actually means at the implementation layer. This is the practitioner guide I wish existed when the announcement dropped.
What’s actually merging
The merger isn’t a code-level fusion where gtag.js and GTM become one library. It’s an administrative and conceptual consolidation. Here’s the breakdown:
The “Google tag” becomes the umbrella product. What used to be “gtag.js” (the lightweight snippet you’d paste from GA4 or Google Ads) is being repositioned as a configuration entity that lives in a shared admin. You can manage it from either the Google Ads/GA4 interface or from GTM, and changes propagate.
GTM web containers become a deployment surface for the Google tag. If you load gtm.js on your site, you’re already loading the runtime that can serve Google tag configurations. The merger formalises this: GTM containers and Google tag IDs share settings like consent defaults, linked destinations, and event configuration.
The admin experience is unifying. Previously, if you set up Google Ads conversion tracking via gtag and later wanted to add a Floodlight tag through GTM, you’d manage two separate systems with overlapping concepts (the gtag “configuration” in Ads vs the GTM “tag” in the container). The merged admin lets you see and edit the Google tag from both sides.
What is not changing: the GTM container ID format (GTM-XXXXXXX), the Google tag ID format (G-XXXXXXX for GA4, AW-XXXXXXX for Ads, DC-XXXXXXX for Floodlight), or the way dataLayer works. Your existing event pushes still fire. Your triggers still trigger.
Do your existing implementations keep working?
Yes. This is the most important sentence in this post. If you have a gtag snippet on your site, it keeps working. If you have a GTM container, it keeps working. Google has been pretty clear that they’re not going to break production sites.
But “keeps working” hides three migration scenarios you should plan for:
Scenario 1: You have gtag.js only
Your site loads something like this in the <head>:
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXX');
gtag('config', 'AW-YYYYYYY');
</script>
Under the merged product, this snippet is now managed as a “Google tag” with a primary ID and secondary destinations. You’ll see both G-XXXXXXX and AW-YYYYYYY listed under the Google tag admin, with shared settings for things like cookie domain, allow_ad_personalization_signals, and consent defaults. You can edit those settings from the GA4 admin, the Google Ads admin, or by opening a GTM-style interface attached to the tag.
Nothing in the HTML needs to change. The gtag/js endpoint is the same. The runtime is the same.
Scenario 2: You have GTM only
Your site loads:
<script>(function(w,d,s,l,i){...})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
And inside the container you’ve got a GA4 Configuration tag, a few Google Ads Conversion tags, maybe a Conversion Linker. Under the merger, each of those Google-owned tags is also a “Google tag” managed entity. If your GA4 Configuration tag uses measurement ID G-ABC123, that ID now shows up as a manageable Google tag in the GA4 admin, with settings that mirror what’s in GTM.
Here’s where it gets interesting: settings can drift. If you change the “include user-provided data” setting from the GA4 admin, and someone else changes it inside the GTM tag config, you’ve got two sources of truth. Google’s documented behaviour is that the GTM tag config takes precedence at runtime, but the admin surface won’t always warn you about the conflict.
Scenario 3: You have both
This is the most common setup I see, and the one that benefits most from the merger. Common pattern: GTM loads on every page, but Google Ads conversion tracking was set up by the PPC team via a raw gtag snippet because “GTM was too complicated.” Now you’ve got two scripts loading the same Google tag runtime, two consent configurations, and frequently a duplicate Conversion Linker.
The merger gives you a clean migration path. Move the gtag snippet into GTM, link the Google Ads account, and let the unified admin manage both. I’ll cover this in the decision framework below.
Conversion tracking, consent mode, and cross-domain linking under the merged product
This is where the practical changes show up. Let me go through each.
Conversion tracking
Google Ads conversions fired via gtag look like this:
gtag('event', 'conversion', {
'send_to': 'AW-YYYYYYY/AbC-D_efG-h12_34-567',
'value': 49.99,
'currency': 'GBP',
'transaction_id': '12345'
});
Conversions fired via GTM use the Google Ads Conversion Tracking tag template with the same conversion ID and label. Under the merger, both routes write to the same Google tag’s destination list. The admin shows you which conversions are configured per destination, regardless of which surface created them.
Practical change: enhanced conversions configuration is now centralised. Previously you’d set up enhanced conversions in the Google Ads UI for gtag implementations, or via the GTM tag for GTM implementations. The merged admin treats this as a property of the Google tag itself, so the setting applies to all conversion events for that destination.
Consent mode
Consent mode v2 is where the merger genuinely simplifies things. Default consent states (the gtag('consent', 'default', {...}) call that must fire before any measurement tags) are now a property of the Google tag, not of the implementation surface. You can define defaults once and they apply whether the tag fires from gtag.js or from a GTM container.
Here’s a default consent block that works under both:
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied',
'functionality_storage': 'granted',
'security_storage': 'granted',
'wait_for_update': 500
});
Gotcha: if you define default consent in the Google tag admin and you push a consent default to the dataLayer before GTM loads, the dataLayer push wins because it executes earlier in the page lifecycle. The admin-defined defaults act as a fallback. Most CMPs (Cookiebot, OneTrust, Iubenda) push the default to the dataLayer, so admin-defined consent defaults are largely belt-and-braces unless you have a site with no CMP.
Cross-domain linking
The Conversion Linker is being absorbed into the Google tag’s default behaviour. Under the merged product, cross-domain measurement settings (linked domains, accept_incoming for cookie domain configuration, URL passthrough for cookieless ping) are managed once per Google tag and apply across both gtag and GTM deployments.
If you’ve been maintaining a separate Conversion Linker tag in GTM and also configuring cross-domain measurement in the GA4 admin, you can stop. The merged admin treats this as one setting.
Side-by-side: old gtag vs old GTM vs the unified flow
| Capability | gtag.js only (old) | GTM only (old) | Unified Google tag (new) |
|---|---|---|---|
| Snippet location | <head> of every page | <head> + <body> GTM snippets | Either, both routes accepted |
| Where settings live | Hardcoded in snippet + GA4/Ads admin | Inside GTM tag config | Google tag admin, shared across surfaces |
| Adding a destination | Edit HTML, add gtag('config', ...) | Add new tag in GTM | Link destination in Google tag admin, propagates |
| Consent defaults | Hardcoded gtag('consent', 'default', ...) | CMP template or custom HTML tag | Admin-defined with code fallback |
| Conversion Linker | Automatic with gtag | Separate tag needed | Built into Google tag |
| Cross-domain config | linker parameter in config | Fields to Set in GA4 Config tag | Single setting in admin |
| Deployment speed | Requires dev for any change | Publish in GTM | Publish in GTM or edit in admin |
| Version control | Git history of HTML | GTM version history | GTM version history, admin changes logged |
| Best for | Static sites, low change frequency | Most production sites | All sites going forward |
The unified flow doesn’t force you to abandon either approach. It standardises the configuration model so that whichever surface you prefer, you’re editing the same underlying entity.
Decision framework: migrate now, wait, or run hybrid
I get this question every week from clients. Here’s how I’d think about it.
Migrate now if:
- You’re running a hybrid setup with both gtag and GTM loading Google products on the same pages. This is the highest-value migration because you’re probably double-firing tags or running competing Conversion Linkers without knowing it.
- You’re about to do a re-platform (Shopify Plus, Next.js rebuild, headless migration). Consolidate the tagging at the same time, not in a separate project six months later.
- You have multiple teams editing tags with no coordination. The unified admin gives you a single audit trail.
Migration checklist:
- Inventory every Google-owned tag firing on your site. Use the GTM preview mode and a network sniffer (browser DevTools, filter on
google-analytics.com|googletagmanager.com|googleadservices.com|doubleclick.net). - Identify duplicates. Same conversion ID firing from both gtag and GTM? That’s revenue being double-counted in Google Ads.
- Pick a single source of truth, GTM is the right answer for 90% of sites.
- Move the gtag-only conversions into GTM tags. Test in preview mode.
- Remove the gtag snippet from the site. Verify in DevTools that the network requests still fire from the GTM-loaded scripts.
- Wait two weeks. Compare conversion volumes in Google Ads against your previous baseline.
If you need help running this audit cleanly, our GTM service handles exactly this kind of consolidation work.
Wait for forced migration if:
- You have a stable gtag-only setup that hasn’t been touched in years and isn’t broken.
- You’re not running Google Ads, only GA4, and your measurement is straightforward.
- You have no upcoming changes to the site and a long change-approval process.
Even then, you should still audit your consent mode implementation against consent mode v2 requirements, because that’s enforced regardless of the gtag/GTM merger.
Run hybrid if:
- You have a genuine reason to keep gtag in place (server-rendered conversion confirmation pages where GTM load timing causes issues, embedded widgets where you can’t inject GTM).
- You have legacy server-side processes that send measurement protocol hits referencing a specific client ID that’s set by gtag.
Hybrid checklist:
- Document which tags fire via gtag and which via GTM. Put it in a README in your repo.
- Pick one surface for each destination. Google Ads conversions either all fire from gtag or all fire from GTM, not both.
- Define consent defaults in one place. If your CMP pushes to the dataLayer, that’s your one place.
- Schedule a quarterly review to check whether the hybrid is still justified.
Common mistakes and troubleshooting
Double-counted conversions after a partial migration. You moved Google Ads conversions to GTM but forgot to remove the gtag('event', 'conversion', ...) call from the thank-you page. Check the network tab for two collect or conversion calls firing on the same page load.
Consent mode defaults firing too late. GTM’s consent initialisation must run before any tag that respects consent. If you load your CMP via GTM and define defaults inside the same container, you have a race condition. Define defaults in a Custom HTML tag that fires on “Consent Initialisation - All Pages” trigger, or push them to the dataLayer before the GTM snippet loads.
Cross-domain linking silently broken. After the merger, if you removed your Conversion Linker tag in GTM thinking it was redundant, but you hadn’t yet enabled the equivalent setting in the Google tag admin, you’ve broken cross-domain attribution. Test by clicking a link to your secondary domain and inspecting the URL for the _gl parameter.
GTM debug shows tag firing, but Google Ads doesn’t record the conversion. Nine times out of ten this is enhanced conversions misconfiguration after a migration. The user-provided data wasn’t mapped correctly in the new tag. Check the Google Ads diagnostics tab, not just GTM preview.
Measurement ID conflicts. If you migrate a property from gtag to GTM and the GTM tag uses a different measurement ID than the one in the original snippet (easy mistake when a team has multiple GA4 properties), you’ll silently start writing data to the wrong property. Always verify the measurement ID at the destination, not just in GTM.
Server-side GTM containers were not affected by this announcement. The merger is about web tagging. If you run server-side GTM, your sGTM container keeps working exactly as before. The web container is what changes administratively. If you’ve been thinking about moving to server-side tagging as part of this transition, that’s a separate architecture decision worth its own evaluation.
For e-commerce sites running this kind of migration, our Shopify analytics work and GA4 setup service often involve untangling exactly this kind of hybrid mess.
Key Takeaways
- The Google tag and GTM merger is an administrative consolidation, not a code-level rewrite. Existing gtag snippets and GTM containers keep working without changes.
- The biggest practical wins are unified consent mode defaults, automatic Conversion Linker behaviour, and a single source of truth for cross-domain measurement settings.
- Hybrid setups (gtag and GTM both deployed on the same site) are the highest-priority migration targets because they frequently double-count conversions and run competing consent configurations.
- For most production sites, GTM is the right single source of truth. Move gtag-managed destinations into GTM tags, verify in preview mode, and remove the gtag snippet only after confirming network requests still fire.
- Don’t migrate during a quiet period for the sake of it. Tie the consolidation to a re-platform, a CMP change, or a consent mode v2 audit.
- Server-side GTM is unaffected by this merger. If you’re already on sGTM, nothing changes. If you’ve been considering it, evaluate it as a separate architectural decision.
Share this article