David Vallejo
ANALYTICS

Solving the GA4 Server-Side Configuration Issue: Why Your First Hit Might Bypass Your Server-Side Endpoint

David Vallejo •
Share

Disclaimer: This might stem from a misunderstanding on my side about how GA4 tags function within Google Tag Manager (GTM), especially compared to how configuration tags used to work in Universal Analytics. The differences between these systems can be subtle and confusing. This issue has been quite frustrating, so I’m sharing my experience in case others encounter the same problem.

I was working on my Google Analytics 4 implementation via Google Tag Manager Server Side and I noticed some of the hits were coming through the regular endpoint ( *.google-analytics.com ), for some reason.

After some testing I figured out the issue. Despite Google Tag Manager shows the associated Google Tag on your GA4 tags, it's not taking any action to be sure that the config settings are applied to the related tag. Meaning that any tag firing before Google Tag won't have the needed configuration. GTM won't be applying the settings to the linked GA4 Tag.

Having this message in the interface makes it somehow confusing:

So for example if the current dataLayer event that triggers your event is on the dataLayer before the event that triggers the GA4 Configuration Tag, the server_container_url will be ignored making your first hit not going through your server-side endpoint.

This means that if are firing a GA4 event tag based on a trigger that happens before the trigger that fires the GA4 config tag, these hits wont go through the SGTM endpoint.

Here is it is an example of the issue:

You see the issue by your own on the following urls:
https://www.thyngster.com/demos/gtag_ss_race_issue/pv_push_before_gtm.html
https://www.thyngster.com/demos/gtag_ss_race_issue/pv_push_after_gtm.html

I prepared a test environment with the most simple replication setup, just a page_view event tag that fires on the page_view event, and the GA4 Config Tag that fires on the All pages (gtm.js) event.

This is how it looks like the tags and triggers on this container:

In my case the issue was not a big deal since i'm just firing the data through the server-side endpoint and I'm not doing anything else, so the biggest problem I'd have is having some hits being blocked by some adblocker because of the domain.

I expect some people firing pixels or doing data widening, firing some pixels based on the SGTM GA4 Client to have some more inconveniences, despite the data flow to Google Analytics 4 to keep working.

Google Tag Manager knows when there's a Google Tag that references our current Measurement IDs ( check screenshot above ), meaning that should be possible to grab the configuration parameters ( server_url, cookie preferences, etc ) and apply them to the to the linked Event Tags ( as Universal Analytics Config tags used to work ... ) without even needing to wait for the Google Tag execution at all or maybe have them them queued them until the related GTAG has fired.

But anyway if you are having this issue, the workarounds are pretty straighforward:

  • Ask your developers to move your push after GTM Snippet
  • Set the GA4 Config tag trigger to be the same as your first event trigger
  • Manually set the server_container_url for the tags that may fire before the Google Tag
  • Be sure that GTAG fired always before any GA4 Event Tag.

    • Based on a comment on Linkedin from Roman Appeltauer there's an extra way of getting over this.

    • Use the Initialization Trigger for your Google Tag

      • This post talks about the server-side integration issues (because it was my problem) but this can be applied to having user properties or event parameters set via the Google Tag. and not being applied to all the tags, depending on your triggers or dataLayer configuration )