Automatically switch sites to the GA4 dashboard view on October 1

[nfmohit]

Feature Description

Note: This is a time-sensitive issue. This shall only be executed to be released as a part of the Site Kit update/release going right after UA has a zero-data state. The changes outlined here will be date-based, i.e. developed as we go, but will be visible to users on or after October 1 2023.

Around 90 days after the UA cut-off, Site Kit will no longer show any UA data anymore naturally. At this point, for the sites that have GA4 connected, we want to switch them automatically to the GA4 dashboard view. To accomplish this, we will need to make a few small changes like the following:

• The isGA4DashboardView selector (being implemented in Add isGA4DashboardView selector #6541) should be updated so that if GA4 is connected, it should unconditionally return true. Since Site Kit will automatically switch to the GA4 dashboard view at this point, this selector returning true will not require us to change the logic immediately and give us a generous amount of time to remove the selector and the UA module overall.
• Since we will automatically switch sites to GA4 dashboard view, we will no longer need to prompt users to switch over. Hence, the “Switch to GA4 Dashboard View” BannerNotification (being added in Add the “Switch to GA4 Dashboard View” notification banner #6544) should be removed, along with the shouldPromptGA4DashboardView selector in the analytics-4 datastore. This will be done as a part of Remove UA counterparts after SK no longer shows UA data beginning September 25 #6786.
• Since at this point there will be no way to switch back to the UA dashboard view, the dashboard view toggle in Analytics settings (being added in Add dashboardView toggle in Analytics settings #6547) should be removed. This will be done as a part of Remove UA counterparts after SK no longer shows UA data beginning September 25 #6786.
• Copy of the in-widget warnings about UA cut-off (added in [~June 30] Post UA cut-off warning #6557) should be updated according to the Figma design.

Here is the relevant part in the design doc.

---

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

Acceptance criteria

• If the current date is October 1 2023 or later, and the ga4Reporting feature flag is enabled:
  • The isGA4DashboardView selector in the analytics datastore should be modified to always return true if GA4 is connected.
  • The copy/text of the in-widget warnings about UA cut-off (added in [~June 30] Post UA cut-off warning #6557) should be updated according to the content in the "Post-July" section of the Figma design.
  • The "Switched to GA4" notification banner (developed in Add the "Switched to GA4" notification banner #6558) should be made visible to the users (i.e. added to <BannerNotifications />).
    • In terms of priority, the banner should be displayed just below the ModuleRecoveryAlert banner. It should appear above ZeroDataStateNotifications.
  • The Dashboard view setting in Analytics module settings (Site Kit -> Settings) (both view and edit) should not be displayed.
• The current date can be obtained using the getReferenceDate() selector in the core/user store. It is being enhanced as a part of Provide reference date to client on page load #6782 so that an optional custom reference date can be set on page load for testing purposes.

Implementation Brief

• In assets/js/modules/analytics/datastore/settings.js:
  • Update the isGA4DashboardView() selector so that it also returns true if the following conditions are met:
    • The ga4Reporting feature flag is enabled.
    • Current date (obtainable via getReferenceDate() selector in the core/user store) is October 1 2023 or later.
    • GA4 is connected (obtainable via isModuleConnected( 'analytics-4' ) selector in the core/modules store).
• In assets/js/modules/analytics/components/common/UACutoffWarning.js:
  • If the current date (obtainable via getReferenceDate() selector in the core/user store) is October 1 2023 or later:
    • Update the text/copy of the <SettingsNotice /> component's notice prop according to the Analytics widget area notices in this screen.
    • The text referred to in the design as of writing the IB is: No fresh data to display. Universal Analytics stopped collecting data on July 1. To resume collecting Analytics data, set up Google Analytics 4..
    • The Learn more link and Set up Google Analytics 4 CTA should persist as of today.
• In /assets/js/components/notifications/SwitchedToGA4Banner.js (being added in Add the "Switched to GA4" notification banner #6558):
  • Update the conditions to show the BannerNotification such that besides the existing conditions, it is also checked if the current date (obtainable via getReferenceDate() selector in the core/user store) is October 1 2023 or later.
• In assets/js/components/notifications/BannerNotifications.js:
  • Import the /assets/js/components/notifications/SwitchedToGA4Banner.js component (being added in Add the "Switched to GA4" notification banner #6558).
  • Place it after the <ModuleRecoveryAlert /> component, only if the ga4Reporting feature flag is enabled.
• In assets/js/modules/analytics/components/settings/SettingsForm.js:
  • Update the conditions under which the Dashboard view setting fields group is displayed so that besides the current conditions, it is also checked if the current date (obtainable via getReferenceDate() selector in the core/user store) is October 1 2023 or later - the group should not be displayed if so.
• In assets/js/modules/analytics/components/settings/SettingsView.js:
  • Update the conditions under which the Dashboard view setting meta view is displayed so that besides the current conditions, it is also checked if the current date (obtainable via getReferenceDate() selector in the core/user store) is October 1 2023 or later - the meta view should not be displayed if so.

Storybook

• Add Storybook story variant for UACutOffWarning to display its updated copy after UA-removal (October 1).
• Add Storybook story variants for Analytics SettingsEdit & SettingsView showing its difference of state after UA cut-off (July 1) and UA-removal (October 1).

Test Coverage

• In assets/js/modules/analytics/datastore/settings.test.js:
  • Update test cases for the isGA4DashboardView() selector to reflect the above changes.
• In assets/js/modules/analytics/components/common/UACutoffWarning.test.js:
  • Update test cases for the component to reflect the above changes.
• Fix any other failing tests.
• Add VRT scenarios for the updated stories.

QA Brief

• Setup Site Kit with the ga4Reporting feature flag enabled and connect Analytics (both GA4 & UA).
• Set the Dashboard View setting to Universal Analytics.
  • Note that you may want to use the following snippet in order to set the dashboard view without causing the GA4 feature tour to be dismissed, which is what happens when updating the view via the Settings page.
  • googlesitekit.api.set('modules', 'analytics', 'settings', { dashboardView: 'universal-analytics' })
• Using the Tester plugin, set the reference date to 2023-10-01 or later. Alternatively use the following snippet to set the date via the JS console while using the plugin.
  • googlesitekit.data.dispatch('core/user').setReferenceDate('2023-10-01')
• Verify that the Dashboard View setting is overridden to be GA4. This can be confirmed by running the following selector which should now return true, as well as by viewing the Dashboard and checking that the GA4 versions of the widgets are displayed.
  • googlesitekit.data.select('modules/analytics').isGA4DashboardView()
• Verify that the Dashboard View section is no longer present on the Analytics Settings edit and view pages.
• Verify that the Dashboard View indicator chip is no longer present on the Dashboard.
• Verify the text in the UA Cutoff Warning notices is updated as per the IB i.e. the text should be:
  • No fresh data to display. Universal Analytics stopped collecting data on July 1. To resume collecting Analytics data, set up Google Analytics 4.
    • This is consistent with the pre-Oct 1st text which is "Your data is stale because Universal Analytics stopped collecting data on July 1, 2023." The text in Figma contains the phrasing _"No fresh data to display. Universal Analytics property stopped collecting data on July 1." which is grammatically slightly off and inconsistent.
  • To display the notice, GA4 needs to be in a disconnected state while UA is connected. The easiest way to achieve this is to delete the googlesitekit_analytics-4_settings option from the DB.
• Verify that the "Switched to GA4" notification banner appears when the Dashboard View setting is overridden via setting the date.
  • Refer to the first four QAB steps in Add the "Switched to GA4" notification banner #6558.
  • However, rather than manually switching over to the GA4 Dashboard View in the second step, instead run the JS snippet mentioned above to set the Dashboard View to Universal Analytics (use the snippet to avoid dismissing the feature tour, as the notification won't display when the tour has been dismissed).
  • Then, when logged in as the second admin, ensure the date is set to 2023-10-01 or later, in order to override the Dashboard View to GA4.

Changelog entry

• Automatically switch users to GA4 dashboard on October 1, 2023 (when no more Universal Analytics data will be available).

[techanvil]

Have moved this back to AC to determine whether to develop this behind a feature flag instead of trying to target a specific release.

[nfmohit]

Thank you, @techanvil!

I have updated the ACs to mention the addition of the Banner Notification developed in #6558 to <BannerNotifications /> as a part of this issue.

Other than that, @aaemnnosttv @tofumatt do you folks have any thoughts regarding @techanvil's idea of using some sort of a flag (e.g. a new feature flag) to develop/test this ahead of time, and fine-control the activation date instead of relying on people updating their Site Kit version? (Slack discussion)

Thanks!

[techanvil]

Thanks @nfmohit. To be honest, I'd have thought the existing feature flag system would be the most pragmatic choice here, but I'm not sure what if any alternative we currently have in terms of infrastructure that lets us update some data remotely...

[aaemnnosttv]

@techanvil I agree that some kind of controllable flag would be best here rather than making this release-dependent. Certainly a feature flag could be used for this condition, but I don't think there are that many moving pieces here that would justify it, particularly on the server side, nor do we need the the gradual rollout. We could implement the flag "internally" and essentially calculate it rather than sourcing it as a persistent remote flag as we usually do, which isn't something we've done before but is something we could potentially consider.

How about using a dismissed item instead (e.g. uaDashboard)? These are persistent across resets and should be sufficiently configurable for testing. We would then automatically set the item so long as UA and GA4 were connected. This would only be needed as long as the UA infra was still around and we already have the infra in place to get and set it.

---

One more thing I wanted to highlight from the current AC is that it seems to be inconsistent with the description which says that we only want to do the automatic transition if GA4 is connected. This nuance isn't represented in the current first point:

• The isGA4DashboardView selector in the analytics-4 datastore should be modified to always return true.

Also, this selector is currently part of the analytics store, not GA4.

[nfmohit]

One more thing I wanted to highlight from the current AC is that it seems to be inconsistent with the description which says that we only want to do the automatic transition if GA4 is connected. This nuance isn't represented in the current first point:

• The isGA4DashboardView selector in the analytics-4 datastore should be modified to always return true.

Also, this selector is currently part of the analytics store, not GA4.

Thank you for spotting this, @aaemnnosttv! I have updated this.

[techanvil]

@techanvil I agree that some kind of controllable flag would be best here rather than making this release-dependent. Certainly a feature flag could be used for this condition, but I don't think there are that many moving pieces here that would justify it, particularly on the server side, nor do we need the the gradual rollout. We could implement the flag "internally" and essentially calculate it rather than sourcing it as a persistent remote flag as we usually do, which isn't something we've done before but is something we could potentially consider.

How about using a dismissed item instead (e.g. uaDashboard)? These are persistent across resets and should be sufficiently configurable for testing. We would then automatically set the item so long as UA and GA4 were connected. This would only be needed as long as the UA infra was still around and we already have the infra in place to get and set it.

Hmm. Well, if we're going to be determining the value ourselves, does it need to be a persisted value at all?

Also, seeing as the intention here is to toggle some behaviour after September 30, 2023, if we're not going to do this remotely or via a release, why don't we simply treat this as another date-dependent piece of functionality?

[aaemnnosttv]

Hmm. Well, if we're going to be determining the value ourselves, does it need to be a persisted value at all?

@techanvil not necessarily, but it could be useful to have it leverage existing infra.

if we're not going to do this remotely or via a release, why don't we simply treat this as another date-dependent piece of functionality?

Given that the changes only seem to be relevant for the front end it could be date-based using the current reference date. The only problem with that is that we don't currently have an easy way to control this for QA ahead of time.

On its face, there's many ways this could be done, but I think aiming for something which is straightforward to QA would be a good guiding principal.

Conceptually, I feel like this fits well with dismissed items since the UA dashboard is kind of being "dismissed" permanently. The mechanism for setting the dismissal could be triggered by conditions using the reference date, and for QA we could use a console command to trigger that dismissal. If we wanted to go for a bit cleaner of an approach, we could use a feature flag but have the enabled state of that featured flag controlled by a dismissed item. That way it could still be toggled via the tester plugin but would be controlled by the plugin itself.

That's my 2c. Thoughts @felixarntz ?

[techanvil]

Hi @aaemnnosttv, thanks for the detailed explanation. I've certainly no objection to the direction you've suggested here, and am interested to hear @felixarntz' thoughts too.

One alternative possibility I would like to suggest though, a suggestion that could keep the front-end code a bit simpler, while also allowing ease of QA, would be to implement this as a simple check against the reference date, and then to facilitate QAing, we could add a feature to the helper plugin that allows the reference date to be overridden so it's set at page load time. That would allow simple QAing of this as well as other reference-date related features...

[aaemnnosttv]

@techanvil that sounds reasonable to me and something I had considered at some point as well. The one issue that might be a problem there is the availability of that value which is currently only exposed through the data store.

We'd need to introduce a mechanism for providing this on page load as well as make that addition in the tester plugin but that would be fine. I think this much is worth doing anyways as we'll have some date-based logic in here regardless. Would you please open a new issue for this part? Then the AC would only need the added detail here about when the change should take effect, and this issue would depend on the new one.

[techanvil]

Note: Have moved this back to the EB, as the additional point added to the AC is no longer needed and has been removed (see the description edit history for the date of this comment). This is no longer needed due to the updated AC for #6914.

[mohitwp]

QA Update ⚠️

@techanvil When date is set to 1 Oct, 2023. Then under Analytics settings The Dashboard view settings is not displaying but UA settings are still visible. Will we continue to display UA settings when the dashboard view permanently switches to GA4?

[techanvil]

Hi @mohitwp, thanks for asking! We will indeed be removing this section, however this particular issue is simply about changing the dashboard view setting, which doesn't affect the rendering of UA settings.

The section you've highlighted will be removed via a separate issue, #6786.

[mohitwp]

QA Update ✅

• Tested on dev environment.
• Verified on setting date to 1 October 2023. Dashboard view change to Ga4.
• Verified Dashboard display all GA4 widgets.
• Verified that the Dashboard View section is no longer present on the Analytics Settings edit and view pages.
• Verified that the Dashboard View indicator chip is no longer present on the Dashboard.
• Verified thatthe text in the UA Cutoff Warning notices is updated as per the IB i.e. the text is:
• No fresh data to display. Universal Analytics stopped collecting data on July 1. To resume collecting Analytics data, set up Google Analytics 4.
• Verified that the "Switched to GA4" notification banner appears when the Dashboard View setting is overridden via setting the date.

Note : I've noticed that Dashboard sharing functionality for Analytics is not working correctly when site swicthes to GA4 dashboard view. I will create a separate ticket for that and will update here.

Before Oct 1 if Analytics a/c don't have GA4

After Oct 1 if Analytics a/c don't have GA4

Admin 2 dashboard view - Forced switch to GA4

[mohitwp]

Note : As mentioned above created new issue for Dashboard sharing - View only dashboard related issue > #7417