Goodbye GA4 Configuration Tag, Hello Settings Variables!

An important update to Google Tag Manager (GTM) began rolling out earlier this week. The most noticeable change is that “GA4 Configuration” tags are being converted into “Google Tags,” but the exciting part is that settings variables have made a much-anticipated return!

Google Tag Transition

The purpose of the GA4 Configuration tag was to set up Google Analytics on the page, but as the name implied, it only worked for Google Analytics 4 (GA4). The Google Tag is a more flexible solution that can be used to set up Google Analytics, Google Ads, and potentially other future products. This transition moves GA4 into alignment with the Google Tag approach.

Before you panic about the implications of your GA4 Configuration tag going away, rest assured that Google’s GTM team has made the transition pretty seamless, so odds are you won’t actually have to DO anything, at least not right away… The Google Tag replacing the GA4 Configuration tag will function the same as the config tag did, and your existing GA4 event tags will continue to function exactly the way they did before the transition. But there are definitely opportunities for better configuration approaches going forward, which we’ll address in detail below.

Here’s how an example GA4 Configuration tag will appear after the migration is complete:

Before:After:

 

 

One of the key differences in this new “Google Tag” world is that GA4 event tags no longer have a direct linkage to the Google Tag, the way they typically did to the config tag. The “Configuration Tag” drop-down menu on the GA4 event tag template has gone away. Instead, each GA4 event tag now requires the Measurement ID of the GA4 web data stream receiving the events. This frees up the Google Tag to focus solely on setting up GA4 (or other products) on the page.

Briefly, here’s a summary of what is changing:

Tag ID vs. Measurement ID

Prior to this transition, the GA4 “Measurement ID” (of the GA4 web data stream receiving the events) could either be configured directly on the event tag, or GTM would pull it from the associated GA4 Configuration tag. Going forward, since there is no direct linkage between event tags and Google Tags, the Measurement ID needs to be configured directly on each event tag.

“So if Measurement ID now goes on the event tag, what is this Tag ID field on the new Google Tag?” Conceptually, the Tag ID is the unique identifier of the Google Tag, but because Google Tags can be combined to address the needs of multiple Google products and destinations, the “Tag ID” could, in theory, be the ID of a combined Google Tag. In practice, though, at least for Google Analytics, the Tag ID is currently the Measurement ID for the GA4 web data stream, so whatever value is in the “Measurement ID” field of the GA4 Configuration tag will be migrated to the “Tag ID” of the converted Google Tag.

If you previously relied on the GA4 Configuration tag to hold the Measurement ID of your web data stream, the transition process will also copy that value to all associated event tags.

No More “Fields to Set”

The GA4 Configuration tag had a section called “Fields to Set,” which could be very confusing. The values configured there were a hodgepodge of “fields” that controlled behavior (e.g., allow_google_signals, cookie_flags) or supplied values for built-in dimensions (e.g., page_location, language), but you could also include event parameters. The values of these parameters remained constant until the GA4 Configuration tag fired again (typically when the next page loaded), but the benefit of adding event parameters in “Fields to Set” was that those parameters would automatically be added to each subsequent event on the page, which saved having to configure them on every tag. But since the values were static, this approach was not viable for many parameters unless you also enabled tag sequencing and fired the config tag before each event tag. (But since that approach was not without its own challenges, let’s just say that before this GTM update, the configuration of shared event parameters was “complicated.”) Immediately after the transition, everything in the config tag’s “Fields to Set” will appear in the “Configuration Settings” section of the Google Tag.

Configuration Settings and Shared Event Settings

With the Google Tag transition, the “fields” previously set in Fields to Set are being rebranded as “configuration parameters” and they are now set in the “Configuration Settings” section of the Google Tag. (The supported configuration options remain the same.) In addition, there is a new “Shared Event Settings” section on the Google Tag where you can set event parameters. As with the GA4 Configuration tag, the values of any event parameters set by the Google Tag remain constant until the Google Tag fires again, but the benefit of setting parameters on the Google Tag is that they will be applied to all events on the page, including most “automatic” events, like user_engagement and events tracked by Enhanced Measurement. (Unfortunately, they are not yet applied to first_visit or session_start, but we hope to see that remedied at some point.) You can enter configuration parameters and event parameters directly on the Google Tag, or you can supply them via the new settings variables. (See below for more on these settings variables.)

One important caveat about the new Configuration Settings and Shared Event Settings sections: The distinction between these areas is only conceptual at this point… If you include a “configuration parameter” in your Shared Event Settings or an event parameter in your Configuration Settings, everything will still work. There is currently no enforcement of what should go where, but rather than perpetuate the confusing free-for-all previously known as “Fields to Set,” it’s a good idea to take advantage of the new structure and put “configuration parameters” in the Configuration Settings section, and true event parameters in the Shared Event Settings section. (We’ll address configuration best practices below.)

Regarding page_view events: The GA4 Configuration tag template had a checkbox to control whether this event was sent automatically when the tag loaded; however, the Google Tag template has no such checkbox. Instead, page view behavior for the Google Tag is governed by the send_page_view configuration parameter. The default behavior is to send an automatic page_view event when the Google Tag loads, but if the checkbox is left unchecked on the config tag, the migration process will automatically add a send_page_view configuration parameter to the Google Tag with the value “false”. Going forward, though, if you want to suppress the automatic page_view event when a Google Tag loads and instead send your own custom event, be sure to include the send_page_view parameter in your Configuration Settings and enter the value “false”, otherwise you may end up with duplicate page_view events.

Finally, for those using Server-Side GTM, the GA4 Configuration tag template had a “Send to server container” checkbox that exposed a field for the Server Container URL when checked, but that checkbox has also gone away. On the Google Tag, you now specify the URL using the server_container_url configuration parameter. (This will automatically be converted if your config tag specified a sGTM URL.)

User Properties

User properties are an extremely valuable Google Analytics 4 feature, and while you could set them on the GA4 Configuration tag, the new Google Tag template does not include a place for them because it’s designed to be product agnostic. Later in this post we’ll address where to set them going forward, but to keep things simple for existing tags, GTM will continue to include any user properties in the post-transition Google Tag. You can keep them there if you like, but any new Google Tags you create must adopt the new approach below. Note: Be careful that you don’t set user properties on both the Google Tag and GA4 event tags; if you do, the ones on the Google Tag will be ignored in favor of the ones on the event tag.

Advanced Settings and Triggers

Any triggers or advanced settings previously configured on the GA4 Configuration tag are being migrated to the new Google Tag as a part of the transition, so the Google Tag will fire exactly how it did before. If you previously used tag sequencing to make your GA4 Configuration tag a “setup tag” for your event tags, that sequencing will still be in place, but as we’ll discuss below, tag sequencing is no longer needed.

Welcome Back Settings Variables!

While the migration from the GA4 Configuration tag to the Google Tag is all fine and good, it’s not really going to rock anyone’s world, but the (re)introduction of “settings variables” is a game changer!

As part of the Google Tag update, Google Tag Manager is adding two new types of variables: “Google Tag: Configuration Settings” and “Google Tag: Event Settings”. For those who remember the “Google Analytics Settings” variable from Universal Analytics, this is a prayer being answered! These new settings variables allow you to define a list of “configuration parameters” or event parameters (and user properties) in a variable and apply the whole list to a tag simply by adding that variable to the tag. For example, you can now create a Configuration Settings variable that contains all the “configuration parameters” you want to apply to your Google Tag and add them by choosing that variable from the new drop-down menu on the Google Tag—ditto for event parameters in the Shared Event Settings section. But what is even more exciting is that you can now create an Event Settings variable and apply it to your GA4 event tags to automatically include a standard group of event parameters (and user properties) on every event. And unlike the values set by the Google Tag, the values provided by the Event Settings variable are dynamically recalculated when the event is sent, so you’re not limited to static values. (Timestamp, anyone?)

A Sample Configuration Settings Variable

 

A Sample “Static” Event Settings Variable

 

Best Practices Going Forward

To make the immediate transition as simple as possible in existing containers, GTM is migrating the GA4 Configuration tag to a new Google Tag such that everything will work the same, but in doing so it is not using the new settings variables. To take advantage of the flexibility now provided by these settings variables, our recommendations going forward are:

Google Tag

When your config tag is converted into a Google Tag, everything in “Fields to Set” is moved to the Configuration Settings section of the Google Tag. This ensures that the tag will function the same as it did before, but it just perpetuates the old “Fields to Set” confusion forward. We recommend that you use this opportunity to do a little housekeeping so that things are better organized for the future:

A Sample Google Tag, Including Settings Variables

 

• Move the actual “configuration parameters” from the new Google Tag(s) to a Configuration Settings variable and apply that variable to your Google Tag(s). Anything in this list is a “configuration parameter.” (See the nuance about user_id below.)

• Move all event parameters with static values from the new Google Tag(s) to an Event Settings variable and apply that variable to your Google Tag(s). Since the values set by the Google Tag will be static, best to name this variable accordingly (e.g., “Event Settings - Static”). Be sure you only include event parameters whose values will be constant for the lifetime of the page; if you identify any event parameters that may change values, move those to a separate Event Settings variable which you apply to your event tags. (More on that below.)

If you only have a single Google Tag (which is the case for many implementations), using settings variables may be overkill, but it will help maintain a clearer line between “configuration parameters” and event parameters and set you up for easy reuse if you create additional Google Tags. However, if you’d prefer to skip using the new variables, you can configure the parameters manually in their respective sections on the Google Tag. In any case, it’s a good idea to separate the two types of “parameters” into the appropriate sections of the tag.

Event Tags

Review your GA4 event tags and Google Tag(s) for event parameters that need to be applied to every event and move any parameters with values that may change to an Event Settings variable, then apply that variable to your event tags. Since the parameter values in this variable will be dynamically recalculated each time an event tag fires, name this variable accordingly (e.g., “Event Settings - Dynamic”).

After you make this change, the only event parameters you will typically need to enter directly on an event tag are those that are specific to that event. (Any shared event parameters with static values should be moved to the Event Settings variable applied to the Google Tag as addressed above.)

Review your GA4 event tags and the Google Tag(s) that replaced your GA4 Configuration tag(s) for user properties and move all user properties to the “Google Analytics User Properties” section of the Event Settings variable that you applied to your event tags. By having all user properties in this one variable and applying it to all event tags, you can be sure that whenever a user property value changes, the new value will be included with the next event that gets sent.

A Sample GA4 Event Tag, with Event Settings Variable

 

A Sample “Dynamic” Event Settings Variable for Use on GA4 Event Tags

 

Tag Sequencing

If you have been using tag sequencing to fire your GA4 Configuration tag before each event tag (i.e., to force parameter values to update before the event), that workaround is no longer needed now that you can apply an Event Settings variable to your event tags.

After you’ve implemented the new Event Settings variable as described above and applied it to your event tags, you can go to Advanced Settings > Tag Sequencing and remove the Google Tag as the Setup Tag for each event tag.

When you remove tag sequencing, be sure to add a trigger to your Google Tag. Typically, the Google Tag should fire on page initialization or as soon as the data layer is ready. (If the same trigger fires both the Google Tag and an event tag, the Google Tag will automatically execute first to ensure that GA4 is set up properly before events are processed.)

Nuances

Here are a few things to keep in mind when it comes to the new settings variables:

• A parameter value set directly on a tag takes precedence over the value provided by a settings variable. For example, if your settings variable provides the value “A” for the my_param parameter, but on the tag you’ve set the value “B,” then “B” is what will be included in the event sent to GA4. This is true for both the Google Tag and event tags and both types of settings variables. Normally you wouldn’t have a parameter configured in both a settings variable and on a tag, but if you do, the tag value overrides the settings variable value.

• While it might be tempting to simplify things further and have a single Event Settings variable that you apply to your Google Tag(s) and your GA4 event tags, this is not a good idea. The Event Settings variable you apply to your Google Tag should only contain event parameters with values that are guaranteed to remain constant for the page's lifetime. If you include a parameter or user property that can change values while the page is active, automatic events like user_engagement will contain the original value set by the Google Tag, not the then-current value. This can lead to confusing results as values appear to regress on automatic events. Better to use one completely static version of Event Settings for the Google Tag and a separate dynamic version for event tags. This will ensure that all events, including (most) automatic events, will have all the static event parameters, and all custom events will have both the static and dynamic event parameters, which is the most coverage possible given the current capabilities of GTM.

• Regarding the GA4 User ID: Technically, user_id is a “configuration parameter,” which implies that it should be set on the Google Tag. But since all values set by the Google Tag are static, and it’s not uncommon for the User ID to become available after the Google Tag has fired on a given page, it’s typically better to set it via the Event Settings variable that you apply to all of your event tags—that way the User ID will be sent as soon as it’s available. You can put user_id in either the Event Parameters section or the Google Analytics User Properties section of your Event Settings variable. It’s not really an event parameter or a user property, but conceptually it’s more like a user property, so our preference is to set it as a user property, especially since User ID behaves like a user property in apps and BigQuery. Just understand that however you set it, the value gets sent via the uid query string parameter on the GA4 hit, so it’s not going to be available in GA4 as either an event parameter or a user property. (Ergo, it won’t be available to feed a custom dimension.) If you want to feed a custom dimension, which may result in more “(other)” rows given GA4’s current cardinality challenges, you’ll need to pass a copy of the User ID value using another name, like “user_id_2”.

Closing Thoughts

The introduction of settings variables to Google Tag Manager in support of GA4 is a huge step forward. Back when GA4 was first introduced, hardcore GTM/GA users lamented the lack of a settings variable, and its absence forced some complicated (and sometimes problematic) workarounds—cough, cough, sequencing, cough, cough. But as with most things GA4, patience pays dividends, and now that settings variables are back in the toolbox, configuring GTM for Google Analytics purposes will be a lot simpler.

If Adswerve can assist during or after this transition, please reach out and learn more about how we can help.