Using GA4 Config tags as Event setup tags?
Use our GA IDs List report and correct this setting to make it work.
If you've worked on an implementation of GA4 that fires config tags more than once per page, or if you're using GA4 to send data to a server-side GTM implementation and using config tags more than once per page, read on.
Since there's no "Settings Variable" for GA4, one of the standard ways we can centralize some parameters is to put them in a GA4 Config tag and fire that Config tag as a "Setup tag" for every GA4 Event tag. This method is solid and is used by default in Intarsia's GA4 Migration projects and tools.
But DID YOU KNOW that there's a setting in each GA4 datastream that can cause it to IGNORE multiple config tags on a page? When this setting is enabled, the first config tag works as expected, and the rest do nothing - completely breaking this approach.
Prior to early August 2022, this setting didn't exist, and firing multiple config tags over the life of a page behaved exactly as one might expect - gtag's config settings were updated with each fire.
But in Early August 2022, the Google Tag launched. Google released a blog post at that time, but the post didn't mention this setting. But, since that point, creating a new GA4 data stream also silently creates a new Google Tag.
Google even provided an article about configuring your Google Tag settings, but this setting isn't in that article; I've also checked GA4 release notes, API documentation, etc etc - but information is lacking.
What no one pointed out is this (which I've only found mentioned as an aside here):
"If the same Google tag is configured two or more times on the same page, it may cause duplicate data or mixed settings. This scenario can occur if you accidentally implement the same tag twice or if you combine two Google tags that were previously both installed on the same page. To ignore duplicate instances of on-page config commands, you can enable the corresponding option in the “Manage Google tag” section of the Admin tab: “Ignore duplicate instances of on-page configuration”. To prevent issues, this option will be enabled automatically when you combine two Google tags."
In effect: since creating a data stream creates both a measurement ID and a Google Tag, this option is enabled by default on all GA4 data streams created in August or later. 🤯
How does this affect my data?
The thing that's really frustrating is that if your setup & testing were done pre-Aug, then new GA4 prop was added later, it may be very difficult to notice this in standard testing or standard reports.
While you might notice something is amiss if you're checking hit parameters as they're sent from the browser, the problem is only observable in the data when a hit-scoped config parameter doesn't get updated. This appears when a parameter either never gets populated (because it wasn't available at the time when the first tag fired), or when and you combine it with another parameter in a report and notice a mismatch.
For example, if I combine event_name and a custom gtm_event parameter, and see event_name == cta_click together with gtm_event == 'gtm.js', this obviously seems wrong - a page load probably shouldn't trigger a click event, right? (This is, in fact, exactly what started me down this road.)
How (and where) to fix this
Sadly, the setting is deep in the Admin, not exposed to the API, and doesn't have a URL of its own - so you're going to have to do some manual work to get this fixed.
I'd recommend using Intarsia's GA IDs List report to first create a list of data streams you'll need to review - export this as a Google Sheets file, then use the links in the data to go directly to your GA4 properties' Admin sections.
From there, choose the data stream:
Under Google tag, click Configure tag settings:
Under Your Google tag, click the name of your tag on the left:
And finally, switch the "Ignore duplicate instances of on-page configuration (recommended)" toggle to OFF, and Save your changes.
If I'm only using GA4 to send data to server-side GTM, am I ok?
No, you are not ok! This issue affects the way the client-side gtag library functions, not the way data is accumulated in GA4; so if you're using that to send data to GTM server-side, you'll see exactly the same issues there, but possibly worse: the data that arrives in your server-side container will be incorrect, so any tags built upon that will carry those same imperfections.
