Adapt GTM integration with GA to support GA4

[nfmohit]

Feature Description

UPDATE 29 Jan 2024: Refer to this comment for decisions taken regarding this issue.

The existing integration between GTM and GA modules in Site Kit only supports UA and since UA has been removed, this integration is no longer functional. #7989 already started an effort to adapt this integration to support GA4.

This issue should be focused on using the datastore infrastructure introduced in #7989 in Tag Manager module components/datastore replacing any usage of the legacy analytics module/datastore.

To summarise, across the Tag Manager module components/datastore, this should work to:

1. Replace the usage of legacy UA tagmanager (get|has)AnalyticsPropertyID*() selectors with GA4 counterparts.
2. Check for the active status of the analytics-4 module instead of analytics.
3. Compare with analytics-4 measurementID instead of analytics propertyID.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• When setting up Tag Manager and editing Tag Manager settings, the legacy message shown when a UA property ID was found within a GTM container tag's property ID should be adapted to work with GA4 and the new Google Tag as follows:
  • When GA4 is not connected, but the selected Tag Manager container has a Google Tag (googtag) which is a valid Google Tag ID, then display the following screen:
    • Screenshot:
      
    • The message should be adapted as follows:
      • Looks like you may be using Google Analytics within your Google Tag Manager configuration. Activate the Google Analytics module in Site Kit to see relevant insights in your dashboard.
    • The CTAs should match the above screenshot.
  • Clicking on "Continue to Analytics setup" should take the user to the Connect Service Analytics screen. (/wp-admin/admin.php?page=googlesitekit-dashboard&slug=analytics&reAuth=true).
    • On the subsequent Analytics settings page, no additional message should be added above the "Please select the account information below.", even if the selected measurement ID matches or does not match the Google Tag ID found above.
• Since there is no support for adding GA4 tags to an AMP container, we should remove existing infrastructure (datastore selectors and React components) that solely "check" for Amp containers and give the user a message as before. Note this comment: We still intend to allow users to setup GTM with an AMP container and that should not be removed.
• Remove any other unused/unreachable infrastructure used to fetch the current GTM live container's UA tags and their associated property ID. (Note to AC Reviewer: This point was originally part of 7992 - but since we are already removing AMP container functionality, it makes sense to remove the other unreachable code here as well. The UA code is already unreachable and not being used, so there is no risk of removing and updating the selectors in a single PR. Also, the scope of our GTM - GA4 integration has been reduced so this issue is not as big as it was originally planned to be.)

Implementation Brief

• Within assets/js/modules/tagmanager/datastore/versions.js, create the following new selectors and implement them as below:

  • getLiveContainerGoogleTag: Similar to getLiveContainerAnalyticsTag, use the getLiveContainerVersion selector and check for the liveContainerVersion?.tag property. If it exists, return the first tag with a type of googtag.
  • getLiveContainerGoogleTagID: Similar to getLiveContainerAnalyticsPropertyID, check for the parameter property having a key of tagId within analyticsTag. If it does, this should be the Google tag ID. If this value is wrapped within {{ }} brackets, then find a variable (using getLiveContainerVariable()) within the container with this value as the name. Iff this variable is of type c (constant), then the value of the first parameter should be the Google tag ID. This comment shows the shape of the container data returned. Ignore logic that tried to find the property ID within a gaSettings variable. Validate any of the IDs found using isValidMeasurementID().
  • getCurrentGTMGoogleTagID: This selector should first fetch the accountID and internalContainerID saved in Tag Manager settings as done in getAnalyticsPropertyIDs(). Pass these values to the getLiveContainerGoogleTagID selector created above to fetch the current container's associated Google Tag ID (if any).
  • Remove all other selectors in this file that were not created above or used within the above selectors.
    • Note that some (or all) of these selectors might also be used for functionality that prevents Analytics from adding the snippet when GTM is connected (e.g. in useGAPropertyIDEffect). This functionality will be removed as part of Remove functionality preventing GA4 from outputting tags when GTM takes over  #8196 and removing this here is out of scope for this issue.

• Within assets/js/modules/tagmanager/components/common/FormInstructions.js:

  • Remove calling the following selectors and all if blocks that use their values:
    • isSecondaryAMP
    • singleAnalyticsPropertyID
    • hasMultipleAnalyticsPropertyIDs
    • analyticsPropertyID
  • Modify the analyticsModuleAvailable and analyticsModuleActive constants to check for the analytics-4 module instead of the analytics module.
  • Call the new getCurrentGTMGoogleTagID selector saving its result in a constant, say currentGTMGoogleTagID. Modify the legacy if block where analyticsModuleAvailable is true AND analyticsModuleActive is false. Check if the currentGTMGoogleTagID has a value (instead of checking for singleAnalyticsPropertyID). Modify the message as per the AC.
  • So effectively, this component should only call three selectors and have one if block for the above condition and the isSetup block which needs no modification.

• Within assets/js/modules/tagmanager/components/setup/SetupForm.js:

  • Instead of selecting the singleAnalyticsPropertyID, select the currentGTMGoogleTagID using getCurrentGTMGoogleTagID. Replace its usage when defining the isSetupWithAnalytics constant.

Test Coverage

• Add new tests for all the selectors created above to mirror the existing tests in versions.test.js.

QA Brief

• Within GTM setup, perform a regression test to verify:
  • creating a new account
  • creating a new container
  • selecting/saving existing account and container
• Perform the same regression tests for editing GTM settings once it is set up.
• Verify existing Google Tag within a GTM Container:
  • Ensure Google Analytics is disconnected.
  • Once you have set up Tag Manager, go to settings and view the Tag Manager settings. Click on "Edit in Tag Manager" to open the appropriate dashboard for the account / container that you have configured.
    • In the default Overview tab that will open, click on "New Tag" -> click "Tag Configuration" -> click "Google Analytics" -> click "Google Tag" from the list. Give the tag a name in the upper left side. Add any valid Google Tag value, say G-ABC12DE34F in the "Google Tag ID" field. Click "Triggering" and choose any trigger (say All Pages). After adding this new tag, click on "Submit" in the upper right corner, give the version a name and description and click "Publish".
    • Go back to the plugin settings, and try selecting the same Account and Container, both, when setting up Tag Manager from scratch again and when editing its settings. Verify the new message as per the AC. However, note that the button CTA's to setup Google Analytics will only appear when setting up Tag Manager and not when editing settings.
    • Edit the tag created above to an invalid Google Tag ID (publish changes again) and verify that the message does not appear.
• Verify existing Google Tag via a Constant variable within a GTM Container:
  • Follow the same steps as above to create a new tag or edit the same one that is created. If creating a new one, ensure the old tag is deleted. However, instead of adding a valid Google Tag ID, add a string with brackets in the Tag ID field like {{My Google Tag ID}}. After saving this tag, go to the "Variables" tab, click on "New" within the "User defined variables" list. Then click "Variable Configuration" -> Constant (under Utlities). The value here should be a valid Google Tag ID like G-ABC12DE34F. Now click on "Submit" and publish a new live version. Verify that the message
  • Edit the tag created above to an invalid Google Tag ID (publish changes again) and verify that the message does not appear.

Changelog entry

• Update setup flow for Tag Manager to be GA4 aware.

[techanvil]

Hey @nfmohit, the AC is most of the way there, however, as noted in a related comment, the tagId is actually a Google tag ID, so we need to check if any of the corresponding Google tag's containers are a match for the current measurement ID rather than assuming the measurement ID will be tracked directly in the tag ID field.

If not, we'll determine the most relevant measurement ID for the Google tag following similar logic to that used in GoogleTagIDMismatchNotification, although falling back to the first valid measurement ID if none of them exist in the available Analytics accounts (TBC as per the linked comment).

[nfmohit]

Hi @techanvil!

I'm handing this over to @jimmymadon as Jimmy actually added the ACs for this one. @jimmymadon Let's sync if needed to discuss the ACR feedback.

Thank you folks!

[techanvil]

Oh, sorry @nfmohit, I should have realised that. Thanks for pointing this in the right direction.

[jimmymadon]

@aaemnnosttv I've modified the AC here based on our discussions for your approval.

On a side note, I just wanted to confirm if your reply to my comment regarding supporting AMP is still valid? If yes, then these selectors will assume that an AMP container could contain a googtag which, as mentioned above, is impossible for now. The usage within our existing Tag Manager settings messages can still be preserved, but these will never be reached. I'm not sure this is the best way to proceed as we will be keeping a lot of code that will never be reached. If we need to reintroduce support for AMP, we can potentially refer to this code and re-add it then?

c.c. @techanvil @nfmohit

[jimmymadon]

@bethanylang @ivonac4 As an update, we are waiting to hear back from Mariya and possibly the GTM team on this one.

[aaemnnosttv]

we are waiting to hear back from Mariya and possibly the GTM team on this one.

This is still in progress, although if it stalls out, I agree with @jimmymadon that we can essentially prune the unused/unreachable AMP code and re-add it later if/when it becomes necessary, but let's hold on this a bit longer.

[jimmymadon]

@bethanylang I’ve checked the comment you were referring to in Asana and we just want to wait a little bit more before we can finalise the AC for 7990. I believe we are want to wait for the GTM team to liaise with the GA team on whether they've planned to allow adding GA4 tags to a GTM Amp container.

c.c. @aaemnnosttv @marrrmarrr

[mxbclang]

@jimmymadon Should this be assigned back to you to update the AC, since we've determined we're not going to support AMP?

[jimmymadon]

I've set this as a 19 as the IB doesn't cover all removal of code that is unreachable and allowing for additional testing of anything missed in the IB. This will have to be done carefully.

[aaemnnosttv]

• Since there is no support for adding GA4 tags to an AMP container, we should remove existing infrastructure (datastore selectors and React components) that cater to AMP mode and tags within an AMP container.

Remove the AMPContainerSelect component and all of its usage.

@jimmymadon while GTM doesn't support configuring GA4, removing GTM support for AMP entirely is out of scope for this issue but also isn't something on our foreseeable roadmap. Folks should still be able to set up GTM using AMP as today, they just can't implement GA4 with it, which is fine since Analytics supports it and makes things a bit easier for us actually. This means we'd always check the web container for a Google tag and suggest setting up Analytics regardless of whether or not the site was using AMP or not.

I'm not sure if this significantly impacts the rest of the IB (which LGTM), but anything which was based on this point about removing AMP support for GTM would need to be reverted/revised.

[wpdarren]

QA Update: ✅

Verified:

• Within the GTM setup, I performed a regression test to verify:
  • creating a new account
  • creating a new container
  • selecting/saving existing accounts and container
• Performed the same regression tests for editing GTM settings once set up.
• Verified existing Google Tag within a GTM Container:
• Verified the new message as per the AC.
• I edited the tag created above to an invalid Google Tag ID and verified the message does not appear.
• Verified existing Google Tag via a Constant variable within a GTM Container:
• Tested all steps in the QAB and AC.
• I also did some additional testing around AMP on the scenarios highlighted above.
• I also checked the snippets in the source code for GTM with AMP activated and not.

Screenshots