Consider re-positioning settings in GA SettingsView

[nfmohit]

Feature Description

If we take a look at the final state of the Analytics module settings in this Figma mockup, it can be seen that the Account setting is on its own row. Do we think it'd be a good idea to implement this positioning consistently in Analytics SettingsEdit and SettingsView?

So, as for positioning:

1. GA account setting at the first row.
2. GA4 settings at the second & third rows.
3. UA settings at the fourth & fifth rows (until it is removed).
4. Other settings as they are today.

---

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

Acceptance criteria

• In Analytics Settings View (eg. SettingsView), the Google Analytics Account should appear on its own line, separate from the property, measurement ID, etc, similar to the Figma mocks:

• The new account row should have an added link to Edit in Analytics as well, as shown in the design which opens https://analytics.google.com/analytics/web/#/a{accountID}p{propertyID}/admin/account/settings in a new tab/window

Implementation Brief

• For the settings view, move the "Account" setting (DisplayView) into its own section (eg. its own <div className="googlesitekit-settings-module__meta-items">) like so:

<div className="googlesitekit-settings-module__meta-items">
	{ ga4ReportingEnabled && (
		<div className="googlesitekit-settings-module__meta-item">
			<h5 className="googlesitekit-settings-module__meta-item-type">
				{ __( 'Account', 'google-site-kit' ) }
			</h5>
			<p className="googlesitekit-settings-module__meta-item-data">
				<DisplaySetting value={ accountID } />
			</p>
		</div>
	) }
</div>

• Add an "Edit in Analytics" link next to the Account in settings view that goes to this URL, for the respective account ID: https://analytics.google.com/analytics/web/?pli=1#/a${GA4_ACCOUNT_ID}p${GA4_PROPERTY_ID}/admin/account/settings
  • See

    site-kit-wp/assets/js/modules/analytics/components/settings/UASettingsView.js

    Lines 51 to 55 in 6585d8e

    	const editViewSettingsURL = useSelect( ( select ) =>
    	select( MODULES_ANALYTICS ).getServiceURL( {
    	path: escapeURI`/a${ accountID }w${ internalWebPropertyID }p${ profileID }/admin/view/settings`,
    	} )
    	);

    for the other "Edit in Analytics" link as inspiration here.

Test Coverage

• No new tests needed, but VRTs will need updating.

QA Brief

• Set up Site Kit with the Analytics module.
• Go to Site Kit settings and open the settings view screen for Analytics.
• Verify that the account ID appears in its own row.
• Verify that the associated edit link works as described in the ACs.

Changelog entry

• Adjust the layout of the Analytics settings view.

[tofumatt]

Had another think on this and I don't think we should move this in the "edit" mode, especially as it isn't that way in Figma. But moving the view setting and adding a link to edit that account in Analytics is 👍🏻

[aaemnnosttv]

Thanks @tofumatt – the IB includes a code snippet which seems to have a feature flag condition within it which isn't part of the AC here. I think the first point of the IB should be sufficient for this simple change, let's remove the code which shouldn't be necessary but also seems to be incorrect.

• Add an "Edit in Analytics" link next to the Account in settings view that goes to this URL, for the respective account ID: https://analytics.google.com/analytics/web/?pli=1#/a${GA4_ACCOUNT_ID}p${GA4_PROPERTY_ID}/admin/account/settings (this should use the getServiceURL selector for Analytics)

Let's simplify this to avoid confusion to call for using getServiceURL (as you mentioned) on the analytics store (since this selector doesn't exist on the GA4 store) with the respective relative path, i.e. omitting all the other details which are provided automatically by the selector.

Also – this change seems simple enough as a 7, or even less but I'm guessing this would be with the Exp: SP label?

[tofumatt]

Indeed, this is a 7 with the Exp: SP label.

I've updated the URL creation not to use the old analytics module, I missed that because both data stores have a getServiceEntityAccessURL URL which the other "Edit in Analytics" link uses.

The GA4SettingsView already uses it here:

site-kit-wp/assets/js/modules/analytics/components/settings/GA4SettingsView.js

Lines 54 to 56 in e3fa574

	const editDataStreamSettingsURL = useSelect( ( select ) =>
	select( MODULES_ANALYTICS_4 ).getServiceEntityAccessURL()
	);

, so that can serve as a reference to create another selector for the URL mentioned in the IB. I think we should add that part in as well, so I've left it in the IB even though it's missing from the ACs. We should amend the ACs if needed, but the edit link is part of the design and we should add it in during this issue, I think, rather than create a new issue for it.

[aaemnnosttv]

Thanks @tofumatt!

We shouldn't really be using getServiceEntityAccessURL in this way, it's only intended to be used to request access to an entity that you don't have access/permissions for yet, and defining it in the first place enables this kind of behavior in the dashboard. Even if the end result is the same, we shouldn't use it for this.

It might be worth defining a new getServiceAdminURL (if only for GA4) to build URLs relative to //analytics.google.com/analytics/web/#/a{accountID}p{propertyID}/admin if we have multiple uses for it, (similar to getServiceReportURL) but for now constructing with getServiceURL is probably fine.

I'll amend the AC to include a reference to the edit link 👍

[tofumatt]

I think the IB here is good now, I don't see a reference to getServiceURL in it so should be good-to-go 🤔

[aaemnnosttv]

IB ✅

[wpdarren]

QA Update: ✅

Verified:

• In Analytics Settings View the Account appears on its own line, separate from the property, measurement ID, etc
• The new account row has an added link to Edit in Analytics, which opens https://analytics.google.com/analytics/web/#/a{accountID}p{propertyID}/admin/account/settings in a new tab.
• Tested this on mobile and other smaller viewports to make sure there are no UX/UI issues.