Solution to the Missing GA4 Events Issue with the GTM Google Tag (gtag) Update on 360, Using Zones, and SSGTM

If you experienced any data outages in GA4 after the GTM update you may not be alone. The reasons are a bit lengthy to describe but the fixes are pretty simple. I explain both as briefly as possible below.

This issue aside, I’m enjoying the new features created by the Google Tag update and am looking forward to what’s coming next.

Scenario

The automatic conversion of GA4 Conversion tags to Google tags within the major GTM update in September 2023 may have caused some unintended issues if you are are GA and GTM 360 license holder, use one or more Zones for sending GA4 hits, and also use SSGTM (server side GTM).

These hit interruptions were caused by some undocumented extra setup steps for a not so commonly occurring trifecta 1. 360 licensing, 2. zone use , and 3. SSGTM.

The GTM Google Tag Update:

Changes made by Google are explained here

• The much appreciated settings variables were added: Configuration, and Event
• Google Tag replaces theConfiguration tag
• One ID shared by Google products

The automated conversion was pretty impressive, especially with respect to how it effectively handled many non-standard scenarios.

Issues

After the GTM update the following happened with our client:

• SSGTM GA4 stopped receiving hits.
• Page_views in GA4 stopped triggering client side
• New Google Tag was not visible to client-side GTM. This was because the GA4 — Configuration tag newly converted to gtag by Google wasn’t firing

Causes

• Simplicity wins again. Like a lot of analytics issues, it was a bunch of simple but inobvious things that worked together to cause it.
• Zones were updated with changed toggle settings: I found that a few new default settings were causing the Google Tag to be invisible to the GA4 GTM container
• The updated GA4 Configuration tag, now a Google Tag, was not firing even with a successful trigger. There was a hint on the tags’ post-update that indicated GTM was unable to find the Google Tag. After a few cycles testing in Preview mode, it became clear that the Google Tag wasn’t firing through the converted Conversion Tag. It was confusing but visible thankfully. This was caused by the new Zone settings (above).
• The conversion of the Configuration tag to a Google Tag didn’t retain the server definition parameter for event tags on the client side, so SSGTM wasn’t receiving the server location in GA4 requests. This became evident after getting Zones to work and then debugging in SSGTM Preview mode.

Fixes

1. Zone settings
2. Trigger update on the Google Tag
3. Server definition parameter move for SSGTM

Zone settings

Type Restrictions:

• Open the Zone settings for your Zone(s), select the Zone that is connected to the container that sends GA4 events
• Navigate to Type Restrictions

• Select Variable Types: [All should be togged “on”]

• Variable types:

• Google Analytics Settings: this is also sometimes toggled “off” [default setting]. Toggle it “on”
• Google Tag: Configuration Settings: is sometimes toggled “off” and it’s a problem: toggle it “on”
• Google Tag: Event Settings: Important to make sure that Google Tag: Event Settings are toggled “on”: the default setting is “off”.

Trigger Change

• Updated trigger for GA4 — Configuration tag (although obsolete tag):
• Tag will not fire on Initialization (gtm.init). It has to fire on gtm.load (page view, e.g. container loaded), so the trigger was changed accordingly.

SSGTM Server Name Parameter

• Issue: Because the GA4 — Configuration tag (now a Google Tag) was no longer set to run first in sequencing, the server_container_url parameter wasn’t being set. This was our experience because this variable was previously set in Fields to Set in the Configuration tag which was triggered to run on page initialization ahead of any events that may be triggered subsequently, and would provide the “global” values for them. This became antiquated with the Google Tag change to GTM.
• Since the new Google Tag (converted from Configuration tag) cannot run at page initialization, the server_container_url parameter didn’t receive a value before client side tags executed. This caused this field to be empty when the SSGTM tag ran and is dependent upon this parameter being set prior to running (provided SSGTM server destination for the hit).
• Result: This resulted in no hits being processed in SSGTM for GA4.
• Solution: Added the server_container_url parameter to a newly created Event Settings variable which was then added to each client side event tag. This empowered each tag to receive the server_container_url definition for the SSGTM server at the time it triggered, and removed the dependency on the Google Tag.

Conclusion

This is a good reminder that the Zones + SSGTM combination in GA4 and GTM 360 is still not a common enough implementation to make it a “hands off” experience during some major GTM updates.

Best to keep major updates in focus, maintain a careful eye on hits, and look for the inobvious causes in case you find issues.