GTM's New gtag.config Event Quietly Double-Fires Wildcard Triggers

On October 8, 2026, Google changed Tag Manager so every gtag('config') command on a page now shows up in the dataLayer as a visible gtag.config event, according to the Tag Manager release notes. Any GTM tag fired by a .* wildcard custom event trigger can now fire one extra time per config call. If that tag is a conversion or remarketing tag, Smart Bidding sees inflated numbers within days.

This is one of those release-note lines that reads like housekeeping. Google's own wording is that the change "may cause those tags to fire" if your containers use wildcard custom event triggers. That sentence is doing a lot of quiet work, and I suspect most people who own a GTM container did not read it on a Thursday.

What Google actually changed on October 8

There are two parts to the update, and they hit different people.

First, GTM container snippets (gtm.js) now initialize on container load no matter what gtag('config') commands sit on the page. Previously, some hybrid setups had the container waiting on config. That wait is gone. PPC Land's write-up frames this as Google pushing sites that mix a GTM snippet with loose gtag('config') lines (G-, AW- or DC- IDs) onto a proper gtag.js install. Google emailed affected container owners, though it hasn't said how many.

Second, and this is the part that worries me more, config commands used to run silently. Now they surface as gtag.config events. A dataLayer event is something triggers can match. So any trigger built to match everything will now match this too.

None of this came out of nowhere. Google announced in May that it was merging Tag Manager and the Google tag, and an August 20 update said new deployment snippets will drop the config command entirely in favor of a "gtm init" trigger, which legacy setups can set to wait for config. The October change is the plumbing catching up with that plan. There's also a separate Google tag and Tag Manager updates page worth bookmarking, because I doubt this is the last behavior change of the year.

Why a ".*" trigger is now a liability

Wildcard custom event triggers (Event name set to .* with "use regex matching" checked) are more common than people admit. They show up in debugging setups, in older containers an agency built in 2019, and in "fire on every dataLayer push" tags that send events to a third-party CDP or a Meta pixel bridge.

Some of those were built on purpose to fire several times per page. GA Optimizer put it bluntly: "Tags intentionally firing three times per page will suddenly start firing four or five times." The count goes up by however many config commands run on that page. A site with a GA4 config and a Google Ads config hardcoded in the head gets two new events per pageview, not one.

Simo Ahava, who has probably written more GTM documentation than Google has, flagged the same thing in PPC Land's coverage: "If you use .* event name triggers, this will be an additional firing for them." Nothing about your trigger was wrong. The world around it changed.

A trigger you built correctly in 2022 can be wrong today without anyone touching it.

Think of it like a motion-sensor light in a hallway that worked fine for years. Then the building installs a robot vacuum. The sensor still works perfectly. It's just turning on a lot more, and the electric bill is where you notice.

Where the extra fires actually cost money

An extra GA4 debug event is annoying. An extra conversion is expensive.

Here's a micro-example. Say a lead-gen site's thank-you page fires a Google Ads conversion tag on a wildcard trigger, and that page also runs one hardcoded gtag('config'). Every lead now has a decent chance of being counted twice. If the conversion action is set to count "every" conversion, Google Ads reports 200 leads where 100 happened, your CPA appears to halve, and tCPA bidding starts chasing traffic it thinks is twice as efficient as it is. Google's conversion counting docs explain the "one" versus "every" setting, and honestly, for lead forms, "one" was always the safer choice. This change just makes the cost of getting it wrong more visible.

Remarketing tags on wildcard triggers are a smaller problem (audience lists don't care much about a duplicate hit), but third-party pixels that charge per event or feed a CDP can get noisy fast. And GA Optimizer raises a second risk I hadn't considered: hardcoded config snippets that initialize before the dataLayer has user context can create a race condition, so the first pageview fires with "(not set)" dimensions.

To be fair to Google, pure GTM setups (Google tag configured inside the container, no hardcoded gtag on the page) seem to be largely unaffected. The trouble is concentrated in hybrid installs, which, I suspect, describes a lot of real-world websites. Shopify themes, WordPress plugins and "the developer pasted the Ads snippet in the header in 2021" all produce exactly this setup.

A 20-minute container audit before Smart Bidding learns the wrong lesson

This is the part you can do today. It took me longer to write than it should take you to run.

1. Find the wildcards. In GTM, open Triggers and look for any Custom Event trigger using regex with .* or a very broad pattern. Note every tag attached to each one.
2. Check the page source for hardcoded config. View source on your homepage, a product page and your conversion page. Search for gtag('config'. Each hit is one extra event per pageview.
3. Open Preview mode. Load a conversion page and look for gtag.config in the event timeline. If your conversion tag fires on it, you have the problem. Screenshot it for whoever owns the container.
4. Add an exception. Create a Custom Event trigger that matches gtag.config exactly and add it as an exception on every wildcard-fired tag. Simo's guide to trigger exceptions covers the mechanics, and the useful rule there is that "an Exception always wins against the corresponding Trigger."
5. Fix the install properly, eventually. Either move the Google tag inside GTM and remove the hardcoded snippet, or switch to the full gtag.js snippet Google documents in its configure guide. The exception is a patch; this is the cure.

The benchmark I'd use: compare Google Ads conversions to your CRM or backend order count for October 1 to 7 versus October 8 onward. If the ratio moved by more than about 10% with no change in traffic or offers, treat it as a tagging issue until proven otherwise.

Cleaning up the bidding data you already polluted

If you find double-counting that started October 8, don't just fix the tag and move on. Smart Bidding has already been learning from those inflated conversions. Google's data exclusions tool exists for exactly this: you tell Google Ads to ignore conversion data from a date range affected by a tagging problem. Google recommends applying them as quickly as possible and says performance should start to stabilize a few days after you create one for past dates.

Data exclusions work for Search, Display, Shopping and Performance Max. They don't cover Hotel and Travel campaigns. If your campaigns are on Meta and the Meta pixel bridge was on a wildcard trigger, there isn't an equivalent clean button, so the best you can do is fix the tag fast and annotate the date. (We wrote recently about how Meta's new agent will grade Meta's own ads, and this is a good example of why you want your own numbers before anyone's AI reads them.)

Anyway, this is also a reasonable moment to ask a broader question about your container. If it's full of tags nobody remembers adding and triggers that fire on everything, that's measurement debt, and Google is clearly going to keep changing the ground underneath it. I'm not sure most teams need to rebuild from scratch. Most probably need one afternoon of pruning.

My guess at how this plays out over the next quarter

My prediction: at least one in five GTM containers that run hybrid installs will show a measurable conversion bump starting October 8, and most of those teams won't notice until a monthly report looks suspiciously good. Somebody will present a 30% CPA improvement in a November QBR that is really a regex.

Google's direction is clear enough. The config command is on its way out, the gtm init trigger is on its way in, and every hybrid setup is going to get nudged (or shoved) toward one clean install. You can do that migration on your schedule now, or on Google's later, probably right before a busy season.

I'd check the thank-you page first. It's the page that pays for everything else, and it's the one where a quiet extra fire does the most damage.