デジタルマーケティングエンジニア 西村 彰悟のコラム「[GTM] Googleタグ版GA4のSPA向けタグ設定」をデジタルマーケティングエンジニア JAIN Vibhor が英訳したものになります。
The official document for GA4 tag settings on single-page applications (SPA) has been updated, and a description of a new parameter called “update” has been added. The use of the update parameter is not mandatory, but it is a useful option when setting up SPA measurements in the future.
In this article, we introduce recommended GA4 tag settings for measurement on SPA, using the update parameter and the role of the update parameter.
- The automatic SPA measurement settings in GA4 are not perfect
- Recommended SPA Measurement Settings Using the “update” Parameter
- Turn off GA4 enhanced measurement feature “Page changes based on browser history events”
- Set the necessary parameters in the Google Tag (update, send_page_view, page_referrer)
- Create a GA4 event tag to measure the page_view event
- Configure triggers for the Google Tag and the page_view event measurement tag
- The function of the update parameter
- Benefits of Using the Update Parameter
The automatic SPA measurement settings in GA4 are not perfect.
As introduced in the previous article “Traps and Countermeasures for SPA Measurement with GA4,” GA4 now allows for automatic measurement of SPA page transitions in response to browser history events by default, thanks to its enhanced measurement features.
However, the compatibility between virtual page view settings and the custom dimension measurements is poor, and it cannot be used in all situations.
Problems with automatic SPA Measurement via Enhanced Measurement Features are as follows:
- It cannot handle page transitions other than those caused by browser history change events.
- Old custom dimension values continue to persist, without being re-evaluated.
- It cannot coexist with settings that overwrite the values of page_location or page_title.
When these issues cannot be ignored, it is necessary to manually configure SPA measurement settings using Google Tag Manager (GTM).
Recommended SPA Measurement Settings Using the “update” Parameter
If you are already successfully measuring SPA, there is no need to use the update parameter. However, based on the latest Google tag specifications at the time of writing, the recommended SPA measurement settings are as follows:
- Turn off GA4 enhanced measurement feature “Page changes based on browser history events”
- Set the necessary parameters in the Google Tag (update, send_page_view, page_referrer)
- Create a GA4 event tag to measure the page_view event
- Configure triggers for the Google Tag and the page_view event measurement tag
Let’s discuss these steps in detail.
2-1. Turn off GA4 enhanced measurement feature “Page changes based on browser history events”
If both the enhanced event measurement feature for SPA page transitions and the same settings in Google Tag Manager (GTM) are enabled, duplicate firings can occur due to each configuration. Therefore, disable the enhanced event measurement side.
- Open the GA4 admin panel.
- Click on the “Data Streams” menu under the “Property settings” > “Data collection and modification”, and then click on the Web stream tab. Choose the Web Stream you wish to modify
- Scroll down and click on the gear icon for the “Events” section under “Enhanced Measurement”.
- Click on “Show advanced settings” under the “Page views” item, to display the settings for “Page changes based on browser history events”. Uncheck, to disable it, and click “Save” in the upper right corner.
2-2. Set the necessary parameters in the Google Tag (update, send_page_view, page_referrer)
We will add the configuration parameters update and send_page_view to the Google tag for SPA measurement. With these settings, the Google tag will be configured to update the value of custom dimensions and various parameters before the GA4 event tag fires.
Parameter name | Parameter value |
send_page_view | false |
update | true |
If necessary, the following parameters will also be set within the Google tag:
The page_title and page_location parameters do not need to be set if correct values can be obtained without them. However, if the page_referrer parameter is not set, the correct information will not be recorded in the “Page Referrer URL” dimension.
Parameter name | Parameter value | When parameters are not se (when the parameter value is undefined) |
page_title | the page title | document.title |
page_location | the page URL (without the fragment part | location.origin+ location.pathname+ location.search |
page_referrer | URL of the page that was displayed immediately before the current page: | document.referrer |
Setting to obtain page_referrer information when using a history change trigger.
When using a history change trigger to detect page transitions in an SPA, you can easily obtain the URL of the previous page using a data layer variable.
Variable name | dataLayer – gtm.oldUrl |
Variable type | Data Layer variable |
dataLayer variable name | gtm.oldUrl |
Settings to obtain page_referrer information when using a custom event trigger:
When the site handles each page display in an SPA by executing the following code, and the page display is communicated to GTM via a custom event, you can use a custom JavaScript variable to retrieve the previous URL from the dataLayer.
Example code implemented on the site side to trigger a custom event during page transitions in an SPA:
<script> window.dataLayer = window.dataLayer || []; dataLayer.push({ // Event name indicating page display used in GTM’s custom event trigger settings ‘event’: ‘virtual_page_view’, ‘event’: ‘virtual_page_view’, // Page URL and parameters to send to GA4 ‘page_location’: ‘https://example.com/column/123/?xx=yy’, // Page title to send to GA4 ‘page_title’:’Measure SPA with GA4′, // additional information you want to send to GA, etc., ‘content_group’: ‘article’, ‘user_id’: ‘xxxxxxx’, ‘member_status’: ‘gold’, }); </script> |
Example of setting a variable to retrieve the previous page URL from the dataLayer.
Variable name | cjs – previous page_location |
Variable type | Custom JavaScript |
dataLayer variable name | refer the code below:(Align TARGET_EVENT and TARGET_PARAM values as per the actual custom events that is rendered on the page) |
function() { // use actual custom events that is rendered on the page var TARGET_EVENT = ‘virtual_page_view’; /// use actual custom events that is rendered on the page var TARGET_PARAM = ‘page_location’; var defaultValue = document.referrer || undefined; var dl = window.dataLayer.slice(); var foundTargetEvent = false; for(var i = dl.length-1; i>=0; i–) { if(dl[i].hasOwnProperty(‘event’) && dl[i].event === TARGET_EVENT) { if(foundTargetEvent) { return dl[i][TARGET_PARAM]; } foundTargetEvent = true; } } return defaultValue; } |
If there are other necessary parameters such as user_id or content_group, set them in Google tag settings or in the ‘Event Configuration Variables’ referenced by the Google tag.
2-3. Create a GA4 event tag to measure the page_view event
With the earlier settings, the GA4 configuration tag has stopped automatically sending the page_view event, so we will create a separate GA4 event tag to measure the page_view event. The reason will be explained later, but this action is essential when using the update parameter in the Google tag.
Tag Type | Google Analytics: GA4 Event |
Measurement ID | Set the same Measurement ID as set in Google Tag. |
Event name | page_view |
2-4. Configure triggers for the Google Tag and the page_view event measurement tag
We will set triggers for both the Google tag and the page_view event tag created in the previous step. At this time, there is no need to set the order of the tags or the priority of their deployment.
The appropriate settings may vary slightly for each website, but they largely fall into the following two patterns, depending on how SPA page transitions are detected in GTM:
When detecting SPA page transitions using history changes:
We will link the following two types of triggers to both the Google tag and the GA4 page_view measurement tag:
- Page View Triggers (initialization trigger recommended)
- History Change Trigger
For the specific setup methods, refer to the previous article: https://ayudante.jp/column/2023-07-03/12-30/#a4-1
When detecting SPA page displays using a custom event:
Implement on the website to send a custom event with dataLayer.push() at the time of page display (including page transitions via SPA), and link the custom event trigger to both the Google tag and the page_view event measurement tag.
Trigger Type | Custom Event |
Event name | Same as the one that triggers upon page transition (virtual page) |
Above set up is now complete.
The function of the update parameter
SPA (Single Page Application) is a technology that facilitates screen transitions without actual full page reloads. However, when the same Google tag with the same measurement ID fires multiple times within the same page view, any subsequent firings are ignored as “duplicate instances” by default. This means that simply re-triggering the Google tag during a screen transition in an SPA will not function.
To address this issue, it is necessary not only to adjust settings within GTM but also to turn off the “Ignore duplicate instances on page settings” switch in the settings for each web stream on the GA4 side. (In web streams that were created a long time ago, this may be turned off by default.)
GA4 Admin Panel > Data Streams > Web Stream Details > Configure tag settings > Admin Tab > Manage Google Tags
A Google tag with the update: true parameter is allowed to fire more than once on the same page regardless of the “Ignore duplicate instances on page settings”.
Additionally, when the Google tag fires a second time or more, it does not send the page_view event, regardless of the send_page_view parameter state. Therefore, when using the update parameter, it is necessary to send the page_view event separately using another GA4 event measurement tag.
The behavior of the Google tag according to each settings is summarized in the table below.
The traditional SPA measurement settings are represented by patterns A and B in the table, the settings introduced in Google’s official documentation are pattern C, and the settings introduced in this article are pattern D.
“update” parameter status | “send_page_view” parameter status | SPA page transition re-triggers Google Tag” and page_view event be re-sent? | SPA page transition re-triggers Google tags, and evaluates custom dimension | GA4 page_view event tag trigger timing | |
A | false / not set | true / not set | ‘Ignore duplicate instances’ is off? YES | ‘Ignore duplicate instances’ is off? YES | Not set |
B | false / not set | false | NO | ‘Ignore duplicate instances’ is off? YES | each page load / transition (including page navigation on a SPA” |
C | true | true / not set | NO | YES | Only during SPA page transition |
D | true | false | NO | YES | each page load / transition (including page navigation on a SPA)” |
Benefits of Using the Update Parameter
The “Ignore duplicate instances on page settings” is a user-friendly feature that can prevent unintended multiple firings of Google tags. However, it can be an obstructive feature when measuring SPAs (Single Page Applications). It’s located in a spot that often requires multiple clicks to reach, and depending on when the GA4 property’s web stream was created, this setting could be either on or off by default, which has led to confusion and issues.
GA4 Admin Panel > Data Streams > Web Stream Details > Configure tag settings > Admin Tab > Manage Google Tags
For instance, if you are setting up tags to switch between multiple GA4 measurement IDs according to the domain of the website, you must ensure that the ‘Ignore duplicate instances on page settings’ is turned off in all web streams. If not, despite having a common GTM setup, it could lead to incidents where only some GA4 properties are not measured correctly.
Utilizing the update parameter allows you to completely bypass the ‘Ignore duplicate instances on page settings’ and configure tags within GTM, offering a significant advantage in preventing such mishaps.
As mentioned at the beginning of the article, if SPA tracking is already functioning correctly, there is no need to switch to a configuration that uses the update parameter.