Google Changed How GTM Handles gtag Config. Your Triggers May Misfire

By the Mayab Media Team

Most broken tracking doesn't break loudly. It just starts counting things twice, and nobody notices for three months.

That's the risk with a small Google Tag Manager change that went out on October 8, 2026. If your container has a "catch-all" trigger, or your developer pasted a GTM snippet next to a stray gtag config line years ago, you need to look at this now. Not next quarter.

What Google actually changed

Google's Tag Manager release notes list it as "Standardizing gtag('config') command behavior." Two things happened.

First, every gtm.js container snippet now initializes when the container loads, whether or not there's a gtag('config') command on the page. Before, some setups waited on that config call.

Second, any gtag('config') command on the page now gets pushed into the dataLayer as a gtag.config event. That sounds harmless. It isn't, for one specific group of people.

Google says it plainly: if your containers use wildcard custom event triggers, those tags may now fire on the new config events. A wildcard trigger is a Custom Event trigger set to .* with regex matching. It fires on every event that hits the dataLayer. Now there's one more event to fire on.

PPC Land's coverage adds the other half. Sites that load a gtm.js container snippet and then call gtag config with a G-, AW- or DC- ID on its own (without the full gtag.js snippet) are running a setup Google calls unsupported. Google emailed container owners in that situation and told them to switch to the full gtag.js snippet. It didn't say how many people got that email.

This change also fits a bigger plan. Google has been folding the Google tag into Tag Manager all year, and new deployment snippets won't include a config command at all. So this isn't a one-off. It's the direction things are going.

Why this costs you money

Here's the chain reaction.

A wildcard trigger fires one extra time per page where config runs. If that trigger is attached to, say, a Meta Pixel custom event, a LinkedIn tag, or a "page engagement" event you feed into Google Ads as a secondary conversion, you just inflated a number.

Inflated conversions do two bad things. Your reports look better than reality, so you keep funding campaigns that aren't pulling their weight. And if the event is used for bidding, automated bidding learns from fake signal and starts chasing the wrong users.

The unsupported snippet setup is worse in a quieter way. Google says those sites may see unexpected changes in tag behavior. Unexpected usually means "something stopped firing and your conversions dipped." If you don't know your setup was in that bucket, you'll blame the campaign, the season, or the creative. You'll be wrong.

Our honest opinion: wildcard triggers were always a shortcut. They're handy for debugging and logging. They're a bad idea in production for anything that touches ad platforms. This change just makes the cost visible.

Your action plan for this week

You can do this in under an hour for most containers.

1. Search your container for wildcard triggers. In GTM, open Triggers and look for any Custom Event trigger with the event name .* and "Use regex matching" checked. Write down every tag that uses one.

2. Decide if each one should exist. For each tag on a wildcard trigger, ask: does this need to fire on every single dataLayer event? Usually the answer is no. Replace it with a trigger for the specific events you care about.

3. Filter out the config event where you keep wildcards. Simo Ahava's advice, cited by PPC Land, is to exclude gtag.config at the trigger level. Practically, add a condition to the trigger so it fires only when Event does not equal gtag.config. Also note the change in your annotations so future-you understands any bump in the data.

4. Check how your site loads Google tags. View source on a few key pages (home, product, checkout, thank-you). Look for a GTM snippet (gtm.js) plus a separate gtag('config', 'G-...') or 'AW-...' line without the full gtag.js script tag. If you see that combination, swap in Google's full gtag.js snippet or move the config into GTM properly.

5. Run Preview mode and watch the event stream. Load a page in Tag Assistant. You should now see a gtag.config event where config commands exist. Click it and check which tags fired. If anything ad-related fired there, you found a leak.

6. Compare conversion counts before and after October 8. Pull daily conversions for each ad platform for the two weeks before and after. A sudden step up with no campaign change is a red flag. So is a sudden step down.

7. Check your inbox. Search the email tied to your GTM account for messages from Google about unsupported installations. If you got one, that's your highest-priority fix.

What to watch next

Google is pushing everyone toward one model: Tag Manager containers that handle Google destinations directly, no stray config calls. Each step of that move will shake loose setups that worked "by accident." The cheapest time to clean up is before the next change, not after a month of bad data.

If you haven't opened your GTM container since whoever built it left, that's your sign.

Takeaway: One new dataLayer event can quietly inflate every tag on a wildcard trigger, so audit those triggers this week.

Want us to check how this affects your tracking? Book a free audit.

Sources

• support.google.com
• ppc.land