Making Sense of the GA4 Configuration Tag

[ Last updated: 2022/11/22 ]

Do you know that joke of the GA4 implementation guy who got bitten in the ass so many times by a tag? Well.. you’re reading his blog now. My blog.

No tag so crucial as the GA4 Configuration Tag. It can make or break or silently kill your implementation without warning. Sounds scary? It is! But I’ll try to explain some quirks and offer a solution to prevent things from breaking too much.

Buckle up and read on… Time to Stop Worrying and Love the GA4 Configuration Tag!

The basics: what is the GA4 configuration Tag

Forget everything you know about Universal Analytics. We’re in GA4 implementation land now. No more fancy and comfortable Settings Variables anymore.

What is it

The GA4 configuration tag is a tag that makes it easy for you to configure how your implementation functions. You can set things like

• the measurement ID to use “everywhere”
• event parameters to set “everywhere” (like currency, client timezone, ..)
• configuration parameters (like cookie options, clientid, …)

Quite a powerful thing. It’s basically a Tag that is a mix of the gtag “config” and “set” api functions.

But that is where it can get confusing. It helps to remember these two things:

Remember this:

The GA4 Configuration Tag is a Tag. Not a variable.

You will need to fire this tag at least once.

The basics: how to use it in its simplest form

When you do nothing fancy, everything will work out just fine.

1. create a Configuration Tag for the data stream, and add your Measurement ID
2. Tell the tag to fire a Page View
3. add a Trigger to the tag (All Pages)
4. for all other tags with other triggers: add this Tag to the event tag.

If you use your tag like this, in all cases, you should be fine.

What can go wrong here?

Nothing. If you use it like this, everything will work fine. The only thing that can go “wrong” is that you may get overconfident :-)

Adding Configuration options and Event Parameters

The beauty of the Tag is that you can add two types of things

• configuration options (like: “cookie_name”, “transport_url”, etc)
• event parameters (like: “gtm_version”, “client_timestamp”, etc)

If you set a configuration option, or set an event parameter, and the configuration tag gets executed the options and the parameters remain “sticky”.

Example: sending a content_group parameter to Home Page on page_view will also send this parameter on subsequent tags.

What can go wrong here?

it does not always work for all tags.

There is a short time window where the tracker is created with (oddly enough) the Measurement ID from the config tag, but no other parameters or configuration.

In this time window, automatic events like “scroll”, and subsequently “session_start” and “first_visit” are sent.

These events can then be sent WITHOUT the proper configuration!

So if you use something like transport_url or “Send to server container” – these hits will NOT be sent via server side, possibly messing up cookies, privacy policies and the like. So beware!

Event tags that use the GA4 Configuration Tag

Event tags that use the GA4 Configuration Tag will “inherit” the event parameters and configuration options that are set in the config tag.

Simple, right?

What can go wrong here?

Did you remember: “the GA4 Configuration Tag is a Tag. Not a variable”.

Well.. You will need to fire this tag at least once.

If you choose not to send a page_view in your config tag: fine If you then fire a page_view event tag: also fine.

But: make sure to FIRE the config tag too! If you only say: use the tag, it will not FIRE the config tag, and will ONLY pick up the measurement ID. Not the settings.

Best practices, and a solution to most quirks

When you need the configuration to be present on all tags, make sure to fire a configuration tag as early as possible.

Like this:

1. fire a configuration tag – without page view – on gtm.init with essential stuff. This will make sure all tags (even the automatic ones) pick this up.
   • transport_url
   • cookie_name, cookie_flags, etc
   • all other stuff that is present on “init” (variables from the URL, GTM containter version, etc)
2. fire a 2nd configuration tag on gtm.js – or an event of your choice – to act like the regular pageview. Here you can duplicate the settings from the first one (to be sure), and add the stricky parameters that you need for subsequent tags
   • content_group, page_type, login_status.. all that goodness that is in your dataLayer at the right moment

What can go wrong here?

Just when you thought you were safe.. as Jørn Reidel pointed out to, there is a fairly hidden setting in the GA4 interface that influences the behaviour of the config tag.

You should disable the “ignore duplicate instances of on-page configuration” setting.

Find it here:

Admin -> Data Streams -> (select stream) -> configure tag settings -> (click your tag)

Then disable the slider. The slider is OFF for older properties, and ON by default for newer ones.

More information on that setting can be found in the Google documentation of this setting.

Summarizing..

The GA4 Configuration Tag is a Tag. Not a variable. Fire it.

Don’t be afraid to fire it more than once (and make sure your UI setting allows the second firing to work)

The configuration tag can be your friend, if you accept it like it is.

Happy Tagging!