Google Tag Manager now pushes gtag config into the dataLayer

If a tag in your Google Tag Manager container fires on a custom event trigger set to .*, it may have fired more often since Thursday, with no change in what your users did. Google changed what goes into the dataLayer.

What changed

Google’s Tag Manager release notes for 8 October 2026 contain two changes in one entry, “Standardizing gtag(‘config’) command behavior for Google Tag Manager”:

1. The container no longer waits for config. Every gtm.js container snippet now initializes when it loads, “regardless of any gtag(‘config’) commands”. Some sites relied on the container honouring a gtag('config', …) line without a gtag.js loader on the page. Google’s only instruction is that pages which use config code must run the Google tag (gtag.js) snippet.
2. Config calls are now dataLayer events. Each gtag('config') command now appears in the dataLayer as a visible gtag.config event. Google’s note says this “may cause those tags to fire” in containers that use wildcard custom event triggers.

The read: the second change inflates counts

The first change breaks a setup that Google never documented as supported. The second change affects setups that are documented and common.

A custom event trigger with regex matching and the pattern .* matches every event name. Google’s own trigger documentation already warned that this includes “events that Google Tag Manager and Google tag emit automatically”. On 8 October, Google added one more automatic event. On every page that calls gtag('config'), a tag on a .* trigger now gets one more chance to fire.

Whether that matters depends on the tag:

• A debugging or logging tag records one more row. That is harmless.
• A conversion or remarketing tag, or a pixel that sends an event to an ad platform, sends one more hit per config call. If that hit counts as a conversion and the platform does not deduplicate it, the conversion count goes up while sales stay the same. The ad platform’s bidding then learns from conversions that did not happen.

The extra hits started on a known date. If a report shows a step up in event or conversion volume from 8 October with no matching change in orders or leads, look at the container first.

What to do

• List your wildcard triggers. In each container, open Triggers and find every Custom Event trigger with “use regex matching” selected. Any pattern that can match gtag.config, .* above all, needs checking.
• Restrict the pattern. Replace .* with the event names the tag actually needs, for example ^(purchase|generate_lead)$. Google’s trigger documentation recommends a more restricted regex.
• Check the tags on those triggers. Conversion tags, remarketing tags and third-party pixels come first. Compare their hit counts before and after 8 October in each platform’s own event tool.
• Find config code without gtag.js. View the source of your page templates. If a page calls gtag('config', …) but loads only the GTM container, add the gtag.js snippet, as Google’s note instructs, or move that configuration into the container.
• Note the date on your reports. If you find inflated conversions, annotate 8 October so that nobody reads the jump as performance.