#GTMTips: Automatic Page View Hits in SGTM After Consent Granted

If you’re using server-side Google Tag Manager, Google (Advanced) Consent Mode and you’re collecting hits to Google Analytics 4, you might have noticed something odd happening when switching consent to granted state.

It looks as if your page_view hits as well as any other hits marked as “Conversions” (or key events now, I guess) are automatically redispatched to the server-side Google Tag Manager endpoint when consent is granted!

This sounds incredibly useful. You no longer need to reconfigure the dispatch of important events after consent is granted.

However, there’s a catch. A pretty significant one. These events can’t actually be used for GA4 data collection at all. They can’t be used to activate Google Analytics 4 tags in the server-side Google Tag Manager container.

So why are they dispatched again in the first place if they can’t be used for GA4? Can you prevent this behavior? And how does this fit in with how GA4 automatically reprocesses hits after consent is granted?

Read on for the answers!

Tip 138: Automatic dispatch of events after consent is granted is solely for Google’s advertising tags’ benefit

If you are running Advanced Consent Mode and collecting the page_view and key events when consent is denied, then Google Tag will automatically send these events again to the server-side Google Tag Manager endpoint when consent is granted for ad_storage.

This only applies when collecting data with the Google Tag to a server-side Google Tag Manager endpoint, and only when consent is granted specifically for ad_storage.

You’ll see these events appear in server-side Google Tag Manager Preview Mode, but any GA4 tags that should have fired with the incoming request are inexplicably blocked from firing, without any indication why this is so.

Google does this to mimic how Google Ads (and related) tags work client-side.

One of the key use cases for server-side Google Tag Manager is to remove redundant tagging from the client-side environment and move it to a server-side context. A popular manifestation of this is moving Google Ads conversion tracking and remarketing to server-side Google Tag Manager and using Google Analytics 4 as the data stream that triggers the ads flows.

However, Google Ads’ client-side tags have a built-in mechanism to automatically redispatch any hits (that were originally collected when consent was denied) as soon as consent is granted for ad_storage. This is likely because Ads doesn’t (yet) have a similar mechanism for reprocessing hits as GA4 does.

These hits are blocked programmatically in server-side Google Tag Manager from activating GA4 tags and any other non-Google-Ads tags in the container. All Ads-related tags (see screenshot below) fire nicely.

Above, you can see how the incoming GA4 request refuses to fire the GA4 tags as well as a couple of custom templates I’m running in the container. However, all five different Ads-related built-in tags do fire without issue.

What we know thus far: when consent is granted for ad_storage, any client-side Google Analytics 4 key events that were collected through server-side Google Tag Manager are sent again, but they can only be used to fire Google’s advertising tags.

What we also know from testing is that this behavior cannot be modified. You can’t use a transformation, for example, to strip out the key parameters (gcu and gcut) that control this behavior.

Well, let’s say you’re not running any advertising tags in the Server container. Is it possible to prevent this behavior? What if you don’t want to expend the network egress that comes from these non-hits? As far as I know, the only way to prevent this behavior is to not set ad_storage granted. So if you’re not collecting any advertising on the site, just keep ad_storage denied at all times.

But if you are collecting advertising hits client-side, then you’re out of luck. You’ll need to set ad_storage to granted state for those, but this will trigger the server-side GTM redispatch.

If you’ve found a way to prevent this behavior when setting ad_storage granted, please let me know. I’ll update the article accordingly.

Finally, the reason GA4 tags are blocked is most likely to avoid collecting duplicate hits to GA4. Remember that GA4 hits first collected when consent was denied are automatically reprocessed as consent “granted” when analytics_storage is flipped to granted state. If you were to collect the automatically dispatched hits through server-side GTM to Google Analytics 4 as well, you’d end up collecting duplicates of all key events.

What bugs me a bit is the lack of control – I might want to use this redispatch mechanism for other tags than GA4. It sounds like a valuable way of streamlining client-side tagging and making use of the network load generated by the redispatched event.

That’s the long and short of it. Hopefully this resolves the mystery for some of you. We’ll see if this behavior is rolled back if Google Ads ever introduces similar reprocessing that GA4 hits already do.

Let me know in the comments if you have more questions about this behavior!