GTM vs G Container IDs on Shopify: Which Tags Are Allowed to Run

|Dan Giura
GTM vs G Container IDs on Shopify: Which Tags Are Allowed to Run

TL;DR

Google's tagging system draws one line through every Google container, and it runs through the container ID. Its documentation states it plainly: a container ID beginning with GTM- "allows all tag types," including third-party scripts and custom HTML, while "product-specific prefixes like G- or AW-" limit the container to Google tags, preventing other tag types from loading or executing [2]. A July 9, 2026 release note formalized the boundary for containers loaded on unsupported paths: previously those degraded to the restricted state no matter their ID, and "moving forward, the ID used to load the container will control this behavior, regardless of the path used" [1]. For a Shopify store the practical question is which class you are actually in, and that answer is scattered across four Google properties that never mention Shopify install routes together. So we assembled it: the five routes that put a Google tag on a Shopify store, the ID class each one produces, and the one common setup that sits outside the rule entirely. Along the way, three things Google does not say, said plainly.

The Rule, in Google's Own Words

Two documents carry the whole mechanism. The reference page, "Manage tagging behavior using the container ID," describes the boundary: with a GTM- ID, the container "can load and execute all features and a wide range of scripts," listing third-party scripts and custom HTML and JavaScript tags; with product-specific prefixes like G- or AW-, "the tag can send data exclusively to Google services" and "prevents loading or executing other tag types" [2].

The July 9, 2026 release note pins down when the ID became the deciding factor on unsupported loading paths such as /gtag/js. Containers loaded that way previously "degraded to a restricted state where only Google-provided tags and variables were permitted to run," and the fix makes the ID govern instead: GTM- containers are not restricted, product-ID containers permit Google-provided tags only, and "installations using Google-provided snippets are unaffected" [1].

Worth noticing what that history means: the documented change is a loosening for GTM- containers that had been over-restricted on those paths, not a new crackdown on anything. Google also notified "administrators of significantly impacted containers" by email [1]; Google gives no other way to check.

Which Class Is Your Shopify Store In?

The routes below come from Google's documentation, plus a code read for the app row. Each is a way Google tags commonly arrive on a Shopify store.

Install route ID class it produces Class under the ID rule
Google & YouTube app Configures Analytics, Ads and Floodlight destinations, whose IDs carry the G-, AW- and DC- prefixes [3][8][9] Google-only prefixes; the app cannot install non-Google tags in the first place
gtag snippet pasted in theme.liquid GT- for newly created tags; G-/AW- for legacy ones [4] G-/AW- are Google-only; GT- is unaddressed
GTM container snippet in theme.liquid GTM- Unrestricted; all tag types allowed [2]
GTM inside a Shopify custom pixel GTM- Not restricted by ID, but Google calls this setup "not a supported implementation" [5]
Server-side GTM Browser side carries whatever ID your web setup uses; the server container's Google Analytics client can be set to serve gtag.js on exactly the path class the July 9 note names [1][6] The browser-side ID now decides
WeltPixel Conversion Tracking's injected pixels Vendor SDKs, no container; GA4 loads under a G- ID Out of scope: no third-party tag routes through a container (last section)

Two Shopify-specific statements from Google anchor this table. On the channel app: "you can't set up Google Tag Manager through the Google & YouTube app," and Google's advice is to move Google tags out of Tag Manager containers on Shopify sites and configure those products directly in the app [3]. And on custom pixels: running Tag Manager inside Shopify's custom pixel sandbox is not a supported implementation [5]. The sandbox's data-quality problems are a separate axis from container permissions, and we covered them in the Meta-through-GTM match quality guide; a GTM- container in a sandbox is unrestricted by ID, which is exactly why that article's failure mode is thin data rather than no data.

The one route where this rule bites a real decision is the second row. If your theme carries a hand-pasted gtag snippet with a G- or AW- ID and third-party functionality has been routed through that container, it is in the Google-only class. Whether you have this is answerable in one look: view your storefront's page source and read the ID inside the googletagmanager.com script URL. That check belongs on the list in our pixel audit guide.

What Does Google Not Say About This?

What a merchant sees when a tag is prevented. The strongest verbs in either document are "prevents loading or executing" and "only permit" [1][2]. Google's documentation says the container prevents other tag types from loading or executing; it does not say what, if anything, the merchant sees.

Where the GT- prefix stands. Google's developer documentation, updated July 30, 2026, says each newly created Google tag gets a GT- prefix [4]. The restriction page names only G- and AW-, with the open-ended wording "prefixes like" [2]. The same silence covers DC-, which the developer docs list as the Floodlight prefix and the restriction page never names. We will not guess which way either resolves.

Who was actually affected on July 9. The note describes the previous behavior, the new rule, and an email to administrators of significantly impacted containers [1]. No source establishes which setups newly gained or lost capability.

Google's Stated Direction Is Toward the Unrestricted Class

The same documentation set carries the forward half of the story. Google's update page says Google tags "will be upgraded to fully capable Google Tag Manager containers," giving sites that only use the Google tag access to Tag Manager's interface-driven features, with no change to in-page behavior [7]. That is Google moving G- and AW- users toward the unrestricted class at the same time the ID rule formalizes what each class means. Read together, the two make sense as bookkeeping before a merge rather than a clampdown: define the boundary precisely, then move people across it deliberately.

For a merchant deciding anything today, that direction mostly counsels calm. The class system is real and worth knowing your position in, and standard setups keep working as they did.

Where Do App-Injected Pixels Sit?

A container permission model governs tags inside a container. An app-injected pixel is not inside one: it is a script the app's own code places on the page, loading each vendor's SDK from that vendor's servers. In WeltPixel Conversion Tracking's case, the Meta, TikTok, Reddit, OpenAI Ads, Pinterest and Klaviyo pixels each load their own vendor's script directly, the only Google-hosted script in the integration is the GA4 tag itself, and the app itself ships no GTM container at all. Google Ads has no browser tag in this integration, which is why it does not appear in that list. A container permission model has nothing to attach to here.

The server side is further removed still: purchase delivery runs from Shopify's order webhook and never touches a browser tag container. The sGTM route has its own legitimate cases, which we weighed separately. The ID rule governs Google containers, and these delivery paths do not use one.

Key Takeaways

  • Your Google tag's container ID prefix is a permission boundary: GTM- containers allow all tag types, product-ID containers like G- and AW- permit Google-provided tags only [2].
  • The July 9, 2026 change made the ID decide on unsupported loading paths where the path decided before; the documented delta is a loosening for over-restricted GTM- containers, and Google-provided snippets are unaffected [1].
  • On Shopify, the Google & YouTube app produces Google-only destination IDs and cannot install GTM at all; a theme-pasted GTM snippet is unrestricted; a theme-pasted G-/AW- gtag is in the Google-only class [3][4].
  • Google does not say what a merchant sees when a tag is prevented, and its restriction page leaves the GT- and DC- prefixes unresolved [1][2][4].
  • Google's stated direction is upgrading Google tags into fully capable GTM containers [7].
  • App-injected pixels and webhook-driven server-side delivery run outside Google containers, so container permissions do not reach them either way.

FAQ

Can a Meta or TikTok tag be blocked by the container ID rule?

Only if it runs as a tag inside a container loaded with a product ID like G- or AW-. That is how the ID rule works, not something the July 9 note introduced; the note changed which factor decides, not what a product-ID container permits. Tags inside a GTM- container are in the unrestricted class, and pixels injected directly by apps are not in a container at all.

Which container ID does the Google & YouTube app give my store?

The app configures Google destinations directly, whose IDs carry the G-, AW- and DC- prefixes, and Google states you cannot set up Tag Manager through it at all [3][8][9]. Those destinations are Google-only prefixes, consistent with what the app is for: it cannot install non-Google tags in the first place.

My Google tag starts with GT. Is it restricted?

Unresolved, honestly. Google's developer docs say every newly created Google tag gets the GT- prefix, while the restriction documentation names only G- and AW- with open-ended wording [2][4]. Until Google closes that gap, no confident answer exists in either direction.

Does this change affect server-side GTM setups?

It touches a path they can use: a server container's Google Analytics client can be set to serve gtag.js on the exact path class the July 9 note names, and under the new rule the browser-side container ID decides the behavior rather than the path [1][6]. Whether sGTM is worth running at all is a different question we treat separately.

Which check should I run on my own store?

Open your storefront's page source and read the ID inside the googletagmanager.com script URL. If it starts with GTM-, every tag type is permitted. If it starts with G- or AW- and third-party tags are attached to that container, that is the one configuration worth revisiting deliberately.

WeltPixel Conversion Tracking takes the app-injected route described above: vendor pixels loaded directly, plus server-side purchase delivery from Shopify's order data. Install it here.

Sources

  1. Google Tag Manager Help, Release notes, July 9, 2026 entry, support.google.com/tagmanager/answer/4620708, accessed July 31, 2026
  2. Google Tag Manager Help, Manage tagging behavior using the container ID, support.google.com/tagmanager/answer/17070049, accessed July 31, 2026
  3. Google Tag Manager Help, Migrate your Google tags with the Google & YouTube app on Shopify, support.google.com/tagmanager/answer/15642481, accessed July 31, 2026
  4. Google Tag Platform documentation, Choose from existing tag IDs, developers.google.com/tag-platform/devguides/existing, page updated July 30, 2026, accessed July 31, 2026
  5. Google Tag Manager Help, Limitations of using a custom pixel for conversion measurement on Shopify, support.google.com/tagmanager/answer/16000892, accessed July 31, 2026
  6. Google Tag Platform documentation, Server-side Tag Manager, send data, developers.google.com/tag-platform/tag-manager/server-side/send-data, accessed July 31, 2026
  7. Google Tag Manager Help, Updates to Google tag and Google Tag Manager, support.google.com/tagmanager/answer/17079602, accessed July 31, 2026
  8. Google Tag Manager Help, Destination ID: Definition, support.google.com/tagmanager/answer/12324787, accessed July 31, 2026
  9. Google Tag Manager Help, Migrate your tagging to the Google & YouTube app, support.google.com/tagmanager/answer/16030792, accessed July 31, 2026

Ready to upgrade your tracking?

Server-side tracking for Magento and Shopify — accurate data, better attribution, full privacy compliance.