Check GA4 measurement ID mapping from Google Tag periodically

[felixarntz]

When the Analytics_4 module is active, Site Kit should regularly check whether the mapping between the Google Tag and the GA4 measurement ID that Site Kit has stored is still accurate. If not, it needs to alert the user about it so that they can make a decision on how to proceed.

---

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

Acceptance criteria

With the gteSupport feature flag enabled and the Analytics / GA4 module active: The logic added in #6082 to periodically check for the Google tag ID should be expanded. That issue added logic that populates the googleTagID only when it was empty before. This issue here is focused on adding further logic for the other case (when googleTagID is already set), as the googleTagID needs to be regularly checked to continuously ensure its correctness (since external changes outside of Site Kit may affect it). See below for detailed requirements:

• The API request that was added in Populate Google Tag data for existing site using GA4 #6082 to identify the Google tag container (also see Implement Google Tag container lookup and destinations list JS selectors #6079) based on the GA4 measurement ID should now be made even when the googleTagID module setting is already populated. It then needs to be checked whether the current googleTagID setting (still) refers to one of the IDs in the container's tagIds property.
  • If yes, then nothing needs to happen.
  • But if not, it means that the Google tag mapping was changed and the Site Kit configuration needs to be updated, since otherwise the current googleTagID would send the data to the wrong place (i.e. no longer to the currently configured GA4 measurement ID). Therefore, in this scenario a banner notification needs to be shown (see below).
  • Similar to what was implemented in Populate Google Tag data for existing site using GA4 #6082, this check should happen at most once per hour.
• To determine what the banner notification needs to show, the getGoogleTagContainerDestinations selector (also see Implement Google Tag container lookup and destinations list JS selectors #6079) needs to be used, passing the current googleTagAccountID and googleTagContainerID.
• For now, an empty banner notification component for this purpose should be implemented, which simply contains the above selector usage and then parses the result into a simple array of strings, with only the values from each object's destinationId field.
• This will be continued in a separate issue. For now, the banner notification can simply output something to easily "debug" the results of the above logic, e.g. a comma-separated list of the destinationIds. It doesn't matter what it looks like, as the UI will be implemented in a follow up issue.

Implementation Brief

• In assets/js/modules/analytics-4/datastore/properties.js, add the following:

  • Add a new action, setHasMismatchedGoogleTagID which takes a boolean value and sets the hasMismatchedTag value in the state.
  • Add a new selector, hasMismatchedGoogleTagID which returns the hasMismatchedTag value from the state.
  • Add a new initial state, hasMismatchedTag with a default value false.

• Update the *syncGoogleTagSettings action (which is being implemented in Populate Google Tag data for existing site using GA4 #6082) with the following:

  • If the googleTagID is already set, check if it's one of the tagIds in the getGoogleTagContainer.tagIds[] array.
  • If it matches, dispatch the setHasMismatchedGoogleTagID action with true.
  • The logic to update the googleTagAccountID, googleTagContainerID and googleTagID should be skipped.
  • It should continue to update the googleTagLastSyncedAt timestamp hourly.

• In assets/js/components/notifications, create a new component, GoogleTagIDMismatchNotification with the following:

  • Check if there is a mismatch in the tag ID using the hasMismatchedGoogleTagID selector.
  • If it returns false, return null.
  • Otherwise, continue with the following:
  • Get the googleTagAccountID from getGoogleTagAccountID and googleTagContainerID from the getGoogleTagContainerID selectors.
  • Get the container destination array of objects from the getGoogleTagContainerDestinations selector.
  • Parse the destination array of objects into a simple array of strings, with only the values from each object's destinationId property.
  • It should render the BannerNotification component with the following props:
    • id - google-tag-id-mismatch
    • title - Google Tag ID mismatch
    • description - The following mismatched Google Tag IDs were found: {comma-separated list of destination IDs}.
    • dismiss - Cancel
  • All the strings should be translated.
  • Add storybook stories for the component.

Test Coverage

• Add test coverage for the new setHasMismatchedGoogleTagID action and hasMismatchedGoogleTagID selector.
• Update test coverage for the *syncGoogleTagSettings action.
• Add test coverage for the GoogleTagIDMismatchNotification component.

QA Brief

• This issue improves the work done at Populate Google Tag data for existing site using GA4 #6082 and takes an initiative to check the GA4 measurement ID mapping from Google Tag periodically.
• Follow the QAB of Populate Google Tag data for existing site using GA4 #6082 and ensure the functionality over there still works.
• Now, head over to tagmanager.google.com and go to the Google tags tab.
• Locate and navigate to the appropriate Google Tag (selected while testing Populate Google Tag data for existing site using GA4 #6082).
• Edit the configuration of the Google Tag, and remove the destination. This should let you create a new Google Tag for the measurement ID, and thus unassign itself from the current measurement ID.
• After an hour or more, go to the Site Kit dashboard. It should now cross-check to see if the saved Google Tag ID still points to the current measurement ID.
• Since we have removed our measurement ID from the Google Tag configuration, Site Kit should now show a Banner Notification with copy as mentioned in the ACs.

Changelog entry

• Add a periodic check to ensure that the Analytics 4 Google Tag is mapped correctly.

[eclarke1]

@felixarntz are we possibly in a position to add the ACs to this one now at all? And did you mention there were some additional GH issues to create now the one-pager has been approved? Just trying to work out timelines on this one holistically.

[felixarntz]

@eclarke1 Indeed, I have this on my list for Monday.

[eugene-manuilov]

Update the *syncGoogleTagSettings action (which is being implemented in Populate Google Tag data for existing site using GA4 #6082) with the following:

• If the googleTagID is already set, check if it's one of the tagIds in the getGoogleTagContainer.tagIds[] array.
• If it matches, dispatch the setHasGoogleTagIDMismatched action with true.
• The logic to update the googleTagAccountID, googleTagContainerID and googleTagID should be skipped.
• It should continue to update the googleTagLastSyncedAt timestamp hourly.

@hussain-t, I don't feel that we really need to change the way how the syncGoogleTagSettings action work. To me this looks like a completely different logic that has nothing common with that action. I suggest creating a resolver for the hasGoogleTagIDMismatched selector that will verify the requested logic. Could you please update your IB to create a new resolver instead of changing that action?

[hussain-t]

@eugenemanuilov that would contradict the aims of the AC, e.g.

The logic added in #6082 to periodically check for the Google tag ID should be expanded.

Also, we want to run it on the same schedule; otherwise, we’ll add another regular API call.

I have slightly updated the IB to rename the action and the selector. LMK WDYT? Thanks!

cc: @techanvil

[eugene-manuilov]

@hussain-t, ok, let it be it. IB ✔️

[hussain-t]

Note: I initially wrote the IB to make the changes in assets/js/modules/analytics-4/datastore/settings.js. However, that's incorrect. So, I have updated the IB to make the changes in assets/js/modules/analytics-4/datastore/properties.js.

[aaemnnosttv]

It then needs to be checked whether the current googleTagID setting (still) refers to one of the IDs in the container's tagIds property.

• If not, then nothing needs to happen.

@felixarntz is this part of the AC correct? Shouldn't this be "If so," (then nothing needs to happen) rather than if not? If the googleTagID refers to one of the IDs in the container's tagIds property then the mapping would still be correct, no?

[felixarntz]

@aaemnnosttv Good catch, after reviewing, this was just a mistake in my writing of the ACs - it should be the opposite. I've updated that bit of the ACs accordingly.

[wpdarren]

QA Update: ⚠️

@nfmohit I have two observations, which might be expected but I didn't want to assume.

- After an hour or more, go to the Site Kit dashboard. It should now attempt to update the Google Tag settings since the existing one has been unassigned from the measurement ID.
- In the browser console, run the following code:
- googlesitekit.data.select( 'modules/analytics-4' ).getSettings()

1. So, I left it just a little over an hour and went back to the Site Kit dashboard. I noticed a banner notification which has a title of Google Tag ID mismatch and a description of The following mismatched Google Tag IDs were found: There are no Google Tag IDs listed though and underneath is only a Cancel CTA.

Reading the AC's it says

For now, an empty banner notification component for this purpose should be implemented, which simply contains the above selector usage and then parses the result into a simple array of strings, with only the values from each object's destinationId field.

This is what I see:

Is this expected at this point?

2. In the QAB it mentions:

In the response returned, verify that the Google Tag setting properties returned reflect to the new Google Tag ID, account, and container.

I ran the code in the console and this is the output

What I noticed is:

• The old measurementID is G-BH42GYS1Y1 which appears to be the old one.
• The GoogleTagID is GT-P84MGBX which is the old one, it should be GT-MKPXCFZ which is the new one.

I've included some screenshots, but wondering if this is an issue, expected, or, something I have done wrong when removing the destination.

Screenshots

This is the new GoogleTagId

This is what I see in Tag Manager

This is the old GoogleTagId

[nfmohit]

Hi @wpdarren!
Thanks so much for sharing your findings and for the detailed context.

So, I left it just a little over an hour and went back to the Site Kit dashboard. I noticed a banner notification which has a title of Google Tag ID mismatch and a description of The following mismatched Google Tag IDs were found: There are no Google Tag IDs listed though and underneath is only a Cancel CTA.

This is correct. The list of Google Tag IDs will only have items when the Google Tag ID configuration (in tagmanager.google.com) has other destinations added. So, even though the current measurement ID/destination is removed from the Google Tag configuration, if it has other destination IDs, they'll show up in the Banner Notification.

Here is a screenshot of my Google Tag configuration with my test site's measurement ID/destination is removed, but it still has a different destination added:

And here is a screenshot of my Banner Notification:

For question 2, I have updated the QAB. It was a mistake on my end and the Google Tag settings aren't supposed to be updated automatically.

Let me know what you think. Thanks!

[wpdarren]

QA Update: ✅

• The functionality on Populate Google Tag data for existing site using GA4 #6082 still works as per the QAB.
  • In the response returned, the Google Tag setting properties (e.g. googleTagID) are populated.
• Followed the QAB instructions on this ticket and I can confirm that since we have removed the measurement ID from the Google Tag configuration, Site Kit shows a Banner Notification with copy as mentioned in the ACs.
  • An empty banner notification component simply contains the values from the destinationId field.

The UI will be implemented in a follow up issue.

Screenshots