Your GTM Bot-Blocking Trigger Has Never Fired — the One-Checkbox Fix

Bot traffic is in your GA4 right now. Most teams know that, so most GTM containers have blocking triggers — exceptions attached to tags that are supposed to stop known bots from firing analytics events.

Here’s the uncomfortable part: many of those blocking triggers have never fired. Not once. They look correct, they were reviewed when they were set up, and they’ve been silently doing nothing ever since.

I found exactly that in a production container, and the root cause was one dropdown.

What the broken state looks like

While the blocking trigger silently does nothing, every bot session flows straight into GA4. The damage compounds quietly:

• Inflated session counts — traffic looks healthier than it is
• Lower conversion rates — bots don’t fill forms, so every bot session dilutes CVR
• Misleading bounce and engagement rates — bot behavior skews both directions depending on the bot
• Decisions made on dirty data — budget moves, page “winners,” and channel comparisons all inherit the noise

None of this announces itself. There’s no error, no failed tag in preview, no red flag in a report. The data is just wrong, uniformly, every day.

The bug: equals vs matches RegEx

The blocking trigger in question was a Custom Event trigger meant to match every event. The standard pattern uses a regex wildcard on the event name:

Field:     {{_event}}
Operator:  matches RegEx
Value:     .*

What was actually configured:

Field:     {{_event}}
Operator:  equals
Value:     .*

One dropdown difference. And it’s fatal:

With equals, GTM checks whether the event name is literally the string .* — two characters, a period and an asterisk. No GTM event is ever named .*. So the condition never matches, the trigger never fires, and every tag that lists it as an exception fires for bots as if the block didn’t exist.

This is what makes the failure so durable. The trigger reads correctly at a glance — the .* is right there, doing nothing. It passes every visual review because the reviewer sees the wildcard and assumes wildcard semantics. The semantics live in the dropdown, not the value.

In the trigger configuration UI, the equivalent mistake is the “Use regex matching” checkbox on event name conditions. Unticked, your regex is a string literal. Ticked, it’s a pattern. One checkbox.

The 3-step audit

This takes about ten minutes for a typical container, and it’s worth doing this week:

1. Open every blocking trigger in your GTM container — anything used as an exception on analytics tags
2. Find the Event Name condition and look for .* (or any regex pattern) in the value field
3. Check the operator: is it matches RegEx (or is “Use regex matching” ticked)? If not — it’s broken, and it has been since the day it was created

Do this for every blocking trigger, not just the one you suspect. Configurations get copied, and a broken pattern gets cloned into new triggers along with everything else.

What happens when you fix it

The first correctly-firing week is jarring if you don’t know what to expect:

• GA4 event counts drop 10–30% depending on how much bot traffic you were absorbing
• Bot crawl spikes disappear from the timeline
• Conversion rates go up — same conversions, honest denominator

The instinct is to treat the drop as a problem. It isn’t. The data you had before wasn’t accurate; this is. Annotate the change date so nobody six months from now investigates the “traffic loss.”

The bigger lesson: setup is not verification

The trigger existed for months because setting up a GTM trigger and verifying it fires are two different pieces of work, and only the first one had been done. A few rules I now treat as non-negotiable:

• Use GTM Preview mode after any trigger change — actually watch the trigger fire (or block) against a real event, don’t just read the config
• Check the event stream in GA4 DebugView — confirm the downstream effect, not just the GTM-side behavior
• Watch for unexpected drops (or their absence) after publish — a blocking trigger that changes nothing in the data probably isn’t doing anything
• If you can’t prove it fires, assume it doesn’t

That last one sounds paranoid until the first time a two-character string costs you months of clean data.

One checkbox. Months of cleaner data. Check your blocking triggers this week.