Add Google Tag settings to the `Analytics_4` module

While overall the Google Tag is intended as a generic solution for tag management, in terms of Site Kit’s modules it only applies to GA4. Since the future of the tag implementation is unclear, the infrastructure should therefore be built specifically into the GA4 module.

---

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

Acceptance criteria

• The Analytics_4\Settings class should receive 3 new settings:
  • googleTagID: A string in a similar shape to a GA4 measurement ID, however it can start in either “G-”, “GT-”, or “AW-”. Default should be an empty string.
  • googleTagAccountID: A string which technically is a Google Tag Manager account ID. Default should be an empty string.
  • googleTagContainerID: A string which technically is a Google Tag Manager container ID. Default should be an empty string.
• The JS store modules/analytics-4 should support those 3 settings as well, including validation functions.

Implementation Brief

Note that “settings mentioned in the ACs” refers to: googleTagID, googleTagAccountID, and googleTagContainerID

• In includes/Modules/Analytics_4/Settings.php:
  • In the array returned from the get_owned_keys() method, include the settings mentioned in the ACs.
  • In the array returned from the get_default() method, include the settings mentioned in the ACs as keys and empty string as the value for all.
  • In the get_sanitize_callback() method, check if the $option array includes googleTagID, and if so, check if the string value for $option['googleTagID'] starts with either G-, GT-, or AW-. If it doesn’t, return false from the function.
• In assets/js/modules/analytics-4/datastore/base.js:
  • In the ownedSettingsSlugs and settingSlugs arrays in the createModuleStore function, include the settings mentioned in the ACs.
• In assets/js/modules/analytics-4/utils/validation.js:
  • Add a new function named isValidGoogleTagID() which should copy the functionality from isValidMeasurementID() function located in the same file, with the exception considering it can start with either G-, GT-, or AW-.
  • Add a new function named isValidGoogleTagAccountID() which should re-export the isValidAccountID() function located in assets/js/modules/tagmanager/util/validation.js.
  • Add a new function named isValidGoogleTagContainerID() which should re-export the isValidContainerID() function located in assets/js/modules/tagmanager/util/validation.js.
• In assets/js/modules/analytics-4/datastore/__fixtures__/default-settings.json:
  • In the JSON object, include the settings mentioned in the ACs as keys and empty string as the value for all.

Test Coverage

• Add test cases for all the newly added validation functions, including those that are exported, so that if the original functions change the Google Tag ones fail (to alert the developer that only the Tag Manager functions should change).

QA Brief

• No visual changed should be introduced.

QA:Eng Brief

• Verify the modules/analytics-4 datastore owns the settings mentioned in the issue.
• Verify the Modules/Analytics_4/Settings.php correctly validates the googleTagID
  • Go to Settings -> Connected Services -> Analytics Edit
  • In console, set the googleTagId programatically. window.googlesitekit.data.dispatch('modules/analytics-4').setGoogleTagID('GT-XXX');
  • Click Save
  • Verify the Tag is saved in the database or reload page and verify the setting is available. window.googlesitekit.data.select('modules/analytics-4').getGoogleTagID()
  • Do the same with an invalid googleTagID and the other newly added settings.

Changelog entry

• Add googleTagID, googleTagAccountID and googleTagContainerID to modules/analytics-4 datastore.

[aaemnnosttv]

But I think there is still something missing. I added the validation functions but did not apply them anywhere, so nothing gets ever validated. I also did not create reducers/selectors.

@derweili Correct – the validation functions are mostly used in other selectors and actions, that don’t exist yet but this issue is laying the foundation for. It’s good to avoid introducing things we don’t use and that’s usually what we do, although there are some issues like this where things are added ahead of time. The tests should be sufficient for ensuring they function properly for now, but you can look at some of the validation functions in other stores to see the kinds of things they will be used for.

I also did not create reducers/selectors.

Is creating reducers/selectors and applying the validation (maybe inside the reducer) handled in a different Issue, or is it missing in the IB?

The basic getters/setters and related parts for settings are generated automatically as part of the internals in createModuleStore. We have a number of these kinds of meta-programming utilities to simplify things that are otherwise highly repetitive and offer little value in hand-coding every time (we used to do this though!).

Generally speaking though, we primarily validate arguments passed to actions and some selectors although these sometimes have to be a bit flexible due to selectors sometimes returning undefined while data is resolving as selector functions themselves are synchronous pure functions.

Hope that helps – let me know if you have any other questions 👍

[derweili]

@wpdarren, as this only adds some settings to the analytics datastore without making use of them and without changing the existing settings, I think testing following areas should be enough:

• Analytics Setup
• Analytics Settings
• Anayltics Dashboard