Google’s Tag Manager release notes, dated October 8, say that “all Google Tag Manager (gtm.js) container snippets will initialize on container load, regardless of any gtag(‘config’) commands,” and that config commands “will now surface in the dataLayer as visible gtag.config events.” Google calls it “standardizing the behavior of tagging snippets,” and the Help page it links to labels one install pattern “an unsupported implementation.” The note’s second paragraph reaches further: “If your Google Tag Manager containers use wildcard custom event triggers, this change may cause those tags to fire.” In my read, the audit worth adding is what hangs on a catch-all trigger, not only whether a stray config line exists.
What is the gtag.config event in Google Tag Manager?
gtag.config is the event name under which gtag(‘config’) commands will appear in the dataLayer. Google’s Tag Manager release notes say config commands “will now surface in the dataLayer as visible gtag.config events,” and that containers with wildcard custom event triggers may see those tags fire. The note gives no rollout date and no count of affected containers.
Google’s own pages, quoted
The note points to a Help page that describes the pattern Google wants gone. Google’s page on correct gtag.js setup says some sites “deploy a non-Google Tag Manager prefixed Google tag ID, such as those starting with G-, AW-, or DC, using a Google Tag Manager snippet path (gtm.js).” Google calls this “an unsupported implementation” and adds: “Users on containers with the unsupported implementation received an email notification.”
The same page says gtm.js snippets “will soon be updated to no longer recognize or wait for any gtag(‘config’) commands.” The Help page says “will soon,” the release note says “will,” and neither names a date. Google’s remedy is either the standard gtag.js snippet or, for teams that manage other tags in Tag Manager, keeping the GTM snippet, replacing the G-, AW- or DC- IDs with a GTM-XXXXXX ID, and deploying the Google tag inside Tag Manager.
The trigger documentation is where the note’s second paragraph gets its weight. Google’s custom event trigger page warns that the .* regex “means that your trigger will execute on all detected events, including events that Google Tag Manager and Google tag emit automatically.” The release note links to that page from the words “wildcard custom event triggers,” which is why a catch-all trigger is the place to look.
Two groups, two different audits
| Setup | What Google’s pages say | Source |
|---|---|---|
| gtm.js with a G-, AW- or DC- ID | “an unsupported implementation” | Help page |
| GTM snippet plus loose config line | Labelled incorrect and unsupported | Help page |
| Wildcard custom event trigger | Tags “may” fire | Release note |
| Supported gtag.js beside GTM | Not addressed by name | None |
Google’s email sentence covers “containers with the unsupported implementation,” the label its Help page puts on the first two rows. It says nothing about the third.
The trade outlets’ reading
PPC Land describes the behavior being retired as a gtm.js container recognizing and waiting for a gtag(‘config’) call placed elsewhere on the page. It quotes Simo Ahava, whom it identifies as co-founder at Simmer: “The thing you need to watch for is that there’s a new Data Layer event in the timeline: gtag.config.” PPC Land says he advised filtering it at the trigger level or accounting for it in annotations and logs.
Both outlets name a second group. Relevant Audience argues that the exposure can reach correct installs, because Google’s supported gtag.js snippet itself contains a config call. On their reading, a .* trigger on a page running gtag.js next to a GTM container gains one more event. That is their inference, not Google’s wording. Relevant Audience’s assessment of impact is its own too: a logging tag gains an extra row, while conversion, remarketing or forwarding tags on a catch-all trigger could send an extra hit.
Open questions
No source in this story gives a rollout date, and both outlets report that Google has not said how many containers use the unsupported pattern. Neither the release note nor the gtag.js setup page says whether Tag Manager’s diagnostics will flag the unsupported install or a wildcard trigger that catches the new event. Google says “may cause those tags to fire” and “may experience unexpected changes to their tag behavior,” and nothing firmer.
Where this sits after August and June
Our report on the August 20 unification covered Google tags becoming full containers, and new deployment snippets that will not carry the gtag config command, with a gtm init trigger recommended instead. An earlier post, on the June 29 interface refresh, described the Destinations model, in which a single container script serves the connected Google products. Google’s August page says the init trigger “can also configure the tag to wait for the config command if you want to preserve legacy setup.” It also says the upgrade “will not change the in-page behavior of the Google tags,” which concerns Google tags becoming containers. The October note concerns gtm.js container snippets, and it does not mention the gtm init trigger.
What to check in your containers
- If you move to the gtag.js snippet, Google’s Help page says to confirm your tag ID shows a green or blue status in the “Google tags found” header in Tag Assistant, and in the Chrome DevTools Network tab that requests go to
googletagmanager.instead ofcom/ gtag/ js /gtm.js. - Relevant Audience suggests listing custom event triggers that use regex matching with
.*or a broad pattern, and the tags each one fires. - In Tag Manager preview, load a page with a config command, find gtag.config in the event list, and check which tags fired (Relevant Audience’s suggestion). Google gives no rollout date, so not finding the event yet settles nothing.
- For tags that send conversions, remarketing audiences or events to third parties, Relevant Audience suggests narrowing the trigger or adding an event-name exclusion.