Enhance how the internal GA tracking loads for relevant non-pages like the Site Kit admin bar menu

Related to #1648: The internal GA tracking is only allowed on Site Kit-owned pages at this point. This generally makes sense, but during definition of #1648 there must have been an oversight related to the Site Kit admin bar menu.

Right now, tracking is not allowed for the admin bar, resulting any tracking events for the admin bar to not work (regardless of whether the Analytics opt-out snippet is being placed or not, which is related to another fix #3294). However, we shouldn’t just simply allow tracking for the admin bar menu, since that would be against the goal of #1648.

A good fix could be to generally allow the GA snippet to be used for the Site Kit admin bar menu, but to only include it if/once it is being interacted with. This would allow the Site Kit integration to work correctly, without unnecessarily including the GA tracking snippet for random non-Site Kit-related content. Essentially, the Site Kit admin bar React app is the only surface point of Site Kit in these cases anyway.

This also opens room for potentially similar changes to support other Site Kit areas, e.g. the plugin activation banner (which also has events) and the WP dashboard widget (which is technically less important since it doesn’t fire events, but would make sense to cover as well).

---

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

Acceptance criteria

• The Analytics snippet for Site Kit anonymous usage tracking should only be injected on page load for Site Kit owned/registered screens
• For non-Site Kit owned screens, the tracking snippet should be injected on-the-fly on the first use of the trackEvent function, but only if tracking is enabled (i.e. user has opted-in and the snippet does not exist on the page yet)
• The tracking snippet should be configured to only track pageviews for Site Kit owned screens

Implementation Brief

• Rename trackingAllowed to isSiteKitScreen in the base data global variable
• Update createEnableTracking to return an additional function like initializeSnippet which takes the respective script injection code from the current enableTracking function and injects it if it hasn’t been inserted yet (also, ideally only check the DOM once and store that in a local variable to avoid unnecessary duplicate calls for this now that it will be called more often)
  • enableTracking would then be refactored to use initializeSnippet
  • The config call should then be updated to include an additional argument to only track pageviews for Site Kit screens (i.e. { send_page_view: config.isSiteKitScreen })
• In assets/js/util/tracking/index.js, replace the current logic for bootstrapping tracking to only
  • If tracking is enabled and isSiteKitScreen, call initializeSnippet otherwise do nothing
• Update createTrackEvent to accept initializeSnippet as an argument
  • Update trackEvent to call initializeSnippet after the existing guards for client-side user-opt-out and user opt-in (trackingEnabled)

Test Coverage

• Tests for new and changed tracking methods should be updated as needed to cover the new behavior
• No visible user-facing changes

QA Brief

1. Open /wp-admin/admin.php?page=googlesitekit-settings#/admin-settings
2. Ensure tracking is disabled and reload the page.
3. Paste this snippet in console: document.querySelectorAll('script[data-googlesitekit-gtag').length
4. It should show 0
5. Enable tracking.
6. Paste the snippet again.
7. It should show 1
8. Open the site home page when you are logged in.
9. Paste the snippet again, it should show 0.
10. Hover over the sitekit dropdown, paste the snippet again, and it should show 1.

Changelog entry

• Enhance on-demand loading of anonymous usage tracking snippet.

[eugene-manuilov]

LGTM. Leaving it for @aaemnnosttv to merge.

[eugene-manuilov]

@aaemnnosttv could you please take a look at https://github.com/google/site-kit-wp/pull/4142#discussion_r717611185?