Implement/refactor GA tracking events for plugin setup

Feature Description

---

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

Acceptance criteria

• The following new GA tracking events should be triggered on the Site Kit plugin activation notice:
  • view_notification: Should be triggered on page load/notice visibility when the notice is shown.
  • confirm_notification: Should be triggered when the user clicks on the primary button in the notice, no matter what the button is set to do.
  • The plugin_activated, proxy_start_setup_banner and goto_sitekit events currently used should be removed.
  • start_site_setup: Should be triggered together with the above confirm_notification if both of the following is true:
    • The button will start the plugin setup flow (i.e. not just take the user to the dashboard).
    • The site isn’t connected yet (i.e. there are no site credentials stored yet).
    • The event should also receive a label: either “proxy” or “custom-oauth” depending on whether the proxy is used (99% of cases) or not.
  • start_user_setup: Should be triggered together with the above confirm_notification (and possibly start_site_setup) if the following is true:
    • The button will start the plugin setup flow (i.e. not just take the user to the dashboard).
    • The event should also receive a label: either “proxy” or “custom-oauth” depending on whether the proxy is used (99% of cases) or not.
  • In other words, start_site_setup is only for when the site is first connecting, start_user_setup is anytime a user connects (which includes the first time, where basically both of this happens as part of the plugin setup). This means that for example, the very first time that the CTA button is clicked, all three events confirm_notification, start_site_setup, and start_user_setup should be triggered.
  • All of the above events should use “activation” (VIEW_CONTEXT_ACTIVATION) as the event category.
• The following new GA tracking events should be triggered on the Site Kit splash screen:
  • start_site_setup: Should be triggered when the CTA button is clicked, under the same conditions as the event of the same name on the activation notice above. It should also have the same label (“proxy” or “custom-oauth”).
  • start_user_setup: Should be triggered when the CTA button is clicked, under the same conditions as the event of the same name on the activation notice above. It should also have the same label (“proxy” or “custom-oauth”).
  • The proxy_start_setup_landing_page and signin_with_google events currently used should be removed.
  • In other words, like on the activation notice, start_user_setup should be triggered in every case for the setup. start_site_setup should only be triggered when there are no site credentials yet (typically only the first time, unless the plugin is reset).
  • All of the above events should use “splash” (VIEW_CONTEXT_SPLASH) as the event category.
• The following new GA tracking events should be triggered on the dashboard success notification (e.g. after setting up the plugin or a module):
  • view_notification: Should be triggered when the notification is rendered.
  • confirm_notification: Should be triggered when the user clicks “Ok, got it”.
  • complete_site_setup: Should be triggered together with the above view_notification if both of the following is true:
    • The notification is shown because of a successful plugin setup (i.e. not because of a successful module setup).
    • Part of this plugin setup flow was to connect the site. A reasonable check to determine that could be to check that only one administrator is connected (since the site itself gets connected as part of connecting the first user).
    • The event should also receive a label: either “proxy” or “custom-oauth” depending on whether the proxy is used (99% of cases) or not.
  • complete_user_setup: Should be triggered together with the above view_notification (and possibly complete_site_setup) if the following is true:
    • The notification is shown because of a successful plugin setup (i.e. not because of a successful module setup).
    • The event should also receive a label: either “proxy” or “custom-oauth” depending on whether the proxy is used (99% of cases) or not.
    • In other words, if complete_site_setup fires, complete_user_setup must also fire (that would be the initial setup). On subsequent connections (which only connect the current user, not the site) only complete_user_setup should fire.
  • All of the above events should use “dashboard_authentication-success_notification” (relying on VIEW_CONTEXT_DASHBOARD for the “dashboard” part) as the event category.
  • Note that this notification is also touched for one event change as part of #4004, so this may require some coordination if happening at the same time.

Implementation Brief

• trackEvent mentioned in the bullet points below should be imported from assets/js/util/tracking/index.js
• Using assets/js/components/activation/activation-app.js,
  • Use the useMount hook to call the trackEvent with view_notification as action.
  • Use the isConnected selector of the site data store to know whether the site is connected.
  • Use the isUsingProxy selector of the site data store to know whether the proxy is being used.
  • Within the onButtonClick function,
    • Update the call to trackEvent with confirm_notification as action (removing the existing plugin_setup action and associated label).
    • If proxySetupURL is true, call the trackEvent function again, with start_user_setup as action, passing proxy as label if the result of isUsingProxy is true, else pass custom-oauth as label.
    • If proxySetupURL is true and isConnected it not true, call the trackEvent function again, with start_site_setup as action, passing proxy as label if the result of isUsingProxy is true, else pass custom-oauth as label.
  • All of the above events should use “activation” (VIEW_CONTEXT_ACTIVATION imported from assets/js/googlesitekit/constants.js) as the event category.
• Using assets/js/googlesitekit-activation.js, remove the trackEvent call.
• Using assets/js/components/setup/SetupUsingProxy.js,
  • Within the onButtonClick function,
    • Implement the start_site_setup and start_user_setup tracking calls as mentioned above for assets/js/components/activation/activation-app.js. The label can be hard coded to proxy since the component is rendered only if the proxy is used.
  • All of the above events should use “splash” (VIEW_CONTEXT_SPLASH imported from assets/js/googlesitekit/constants.js) as the event category.
• Using assets/js/components/legacy-setup/SetupUsingGCP.js,
  • Within the onClick callback for the Sign in with Google, implement the start_site_setup and start_user_setup tracking calls as mentioned above for assets/js/components/activation/activation-app.js. The label can be hard coded to custom-oauth instead of checking whether the proxy is used since the component is rendered only if proxy authentication is not used.
  • All of the above events should use “splash” (VIEW_CONTEXT_SPLASH imported from assets/js/googlesitekit/constants.js) as the event category.
• Remove the trackEvent call having signin_with_google as action from assets/js/components/legacy-setup/wizard-step-authentication.js and assets/js/components/legacy-setup/SetupUsingGCP.js.
• Using assets/js/components/legacy-notifications/dashboard-setup-alerts.js,
  • Use the hasMultipleAdmins selector of the site data store to check if there is only 1 admin. It should return true if the site has multiple admins, false if it has just one admin.
  • Use the isConnected selector of the site data store to know whether the site is connected.
  • Use the isUsingProxy selector of the site data store to know whether the proxy is being used.
  • Use the useMount hook:
    • to call trackEvent with view_notification as action.
    • if slug is null, call trackEvent with complete_user_setup as action and passing proxy as label if the result of isUsingProxy is true, else pass custom-oauth as label.
    • if slug is null and there is only one connected admins, call trackEvent with complete_site_setup as action and passing proxy as label if the result of isUsingProxy is true, else pass custom-oauth as label.
  • Add the onDismiss prop to Notification within the authentication_success test and the callback function should call trackEvent with confirm_notification as action.
  • All of the above events should use “dashboard” (VIEW_CONTEXT_DASHBOARD imported from assets/js/googlesitekit/constants.js) as the event category.

Test Coverage

• No new tests to be added.

QA Brief

• Verify that the events listed in the AC are all present and correct.

Changelog entry

• Update plugin setup tracking events for users who have opted-in to tracking.

[felixarntz]

@kuasha420 @aaemnnosttv I think it’s okay we don’t have special treatment for this event. User event tracking in that sense is always somewhat inconsistent (as they can opt-in and opt-out at any time), so I think this is acceptable. We still shouldn’t ditch the event entirely, as it could still fire if someone opts in, deactivates the plugin and reactivates it again. We mostly need to be aware of this caveat when assessing the metrics.

[tofumatt]

My guess is we need to wait for the user to press the checkbox before firing the view_notification event.

That is correct; the rest of the event tracking you experienced seems correct, and originally I thought we should special-case this one and put it in a useEffect + track when we send it, rather than putting it in a useMount, because tracking will likely be disabled on first load.

But that requires us doing this everywhere and isn’t very nice. I think this issue actually passes QA but we need to improve event storage when tracking is disabled: https://github.com/google/site-kit-wp/blob/6101771d0653fec3db89876eecc9013ee3e5f1f7/assets/js/util/tracking/createTrackEvent.js#L44

Maybe it can be part of the #3051 epic, for now I’ve made a note of it and will file a follow-up issue when needed. 👍🏻

After initial setup and being redirected to dashboard, 'view_notification' event fires twice in two different categories

This is correct, they’re different categories of notifications and it’s fine for both to fire, from the ACs of each issue.

So I think this is QA ✅ , thanks for checking on it @kuasha420 👍🏻