Show more informative messages on dashboard-details screen if there is no data

[felixarntz]

Feature Description

The blue CTAs for when there's no data for a page should provide more contextual information, partly based on new checks.

• If the page was recently created and there is no data, the wording should indicate that as the reason for the lack of data.
• For Search Console, if the Search Console property was just recently created, the wording should indicate that as the reason for the lack of data.
• For Analytics, if the Analytics property was just recently created, the wording should indicated that as the reason for the lack of data.

This will require both changes in wording and a few new logic bits.

Here is a current screenshot:

---

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

Acceptance criteria

• Widgets should be able to return a specific component which indicates to the renderer that the widget has currently no data (e.g. due to API response values all being 0).
• The copy for the component should be centrally controlled per each module, i.e. not every widget should have to manually implement the copy.
• For Search Console, if there is "no data" (i.e. all 0s like we detect today):
  • If in the single page view (dashboard-details) and the page was created in the last day, display: Heading: Search Console gathering data Text: This page was recently created - as soon as people start finding it in Search, you'll see information about clicks and impressions here.
  • Elsewhere, if the oldest post on the site was created in the last day, display: Heading: Search Console gathering data Text: This site was recently created - as soon as people start finding it in Search, you'll see information about clicks and impressions here.
  • Otherwise, keep the regular "Search Console data is not yet available, please check back later."
• For Analytics, if there is "no data" (i.e. all 0s like we detect today):
  • If in the single page view (dashboard-details) and the page was created in the last day, display: Heading: Analytics gathering data Text: This page was recently created - as soon as Analytics collects more data about it, you'll see it here.
  • Elsewhere, if the oldest post on the site was created in the last day, display: Heading: Analytics gathering data Text: This site was recently created - as soon as people start visiting it, Analytics will show you information about how they engage with your content.
  • Otherwise, if the Analytics property has been created within the last day, display: Heading: Analytics gathering data Text: Your Analytics property was very recently created, it might take some time to gather all the data for your site.
  • Otherwise, keep the regular "Analytics data is not yet available, please check back later."

Implementation Brief

• Introduce Entity::is_new() in PHP, and expose it in core/site selector isCurrentEntityNew:
  • The is_new data should be set to true only for posts that have a creation date which is not older than 1 day, otherwise it should be false.
  • This value should then be provided to JS with the other current entity data.
• Add another core/site selector called isSiteNew. Should be based on a PHP-to-JS provided value:
  • Add Context::is_site_new(), which queries posts (of any public post type) to get the oldest post and checks if its creation date is not older than 1 day.
• Implement WidgetNoDataError component in the components/common directory for Search Console and Analytics.
  • Should for now render the existing CTA component with title and description per the ACs.
  • For Analytics, to get the property creation date, it should make an API request to a new datapoint modules/analytics/data/property (which relies on https://developers.google.com/analytics/devguides/config/mgmt/v3/mgmtReference/management/webproperties/get), using an updated version of the getPropertyByID( accountID, propertyID ) selector:
    • The selector should require accountID and propertyID, as parsing the account ID is not fully correct (actually this is an oversight from #1707).
    • The selector should receive a resolver, which, if the property is not yet in state (e.g. via getProperties from before), should issue the request to modules/analytics/data/property.
• Implement generic WidgetNoDataError component in assets/js/googlesitekit/widgets/components directory:
  • Should receive props moduleSlug (required) and children (optional).
  • Should get the module's name via select( 'core/modules' ).getModule( moduleSlug ) (the name property).
  • Should render a div.googlesitekit-widget-no-data-error, and inside of it:
    • Either children if it is present.
    • Or the existing CTA component with today's standard "%s Gathering Data" title and "%s data is not yet available, please check back later." description (using the module name for the placeholder).
• The WidgetNoDataError component should be made publicly available via googlesitekit.widgets.components.WidgetNoDataError, and it should (also internally) be always imported from there (via Widgets).
• For the new widgets API, components will return these components when there's no data. For implementing this with the current withData HOC, modify assets/js/components/notifications/nodata.js:
  • Add moduleSlug as new first argument (existing arguments should follow).
    • Update all usages of getNoDataComponent to work properly.
  • If the slug is search-console or analytics use the specific WidgetNoDataError from the module as mentioned above, otherwise it should use the generic WidgetNoDataError component (hard-coded because only needed for BC).
  • Maintain the ctaWrapper call at the end.

Changelog entry

[marrrmarrr]

@felixarntz updated the text. For the "recently created" cases, could we increase the time frame to 2 (or even 3) days? Especially for SC, it's unlikely there will be enough data in 2 days to show something meaningful.

[aaemnnosttv]

Looks like a good start here @felixarntz - a few questions for you:

• isCurrentEntityNew and isSiteNew don't appear to be used other than adding the selectors
  • Rather than making these boolean on the server, it might be more useful to pass these as dates or timestamps and move the "is new" logic to the client/selector. That way we could use this for something else without requiring new data on the server if we wanted to check something else relative to these points in time. With that said, I think these would be more useful as something like currentEntityPublishedAt and oldestEntityPublishedAt values, then we could use that to implement the same selectors you described.

Add Context::is_site_new(), which queries posts (of any public post type) to get the oldest post and checks if its creation date is not older than 1 day.

Similar to the needs of hasConnectedAdmins I think we should implement an option to store this value in so we don't trigger unnecessary DB queries for the oldest post on every Site Kit page load.

The selector should require accountID and propertyID, as parsing the account ID is not fully correct

1. How was this missed!? 🤯
2. I still think that this selector shouldn't need the account ID as a parameter because it should only ever belong to a single account (even if it is moved). If properties were keyed by propertyID rather than accountID::propertyID we could grab it with state.properties[ propertyID ]. Nevertheless, I understand the accountID is necessary to make the request to the new datapoint though so I suppose this is okay 👍

Aside from that, this would still result in many widgets on the page rendering the same message in a blue CTA component, would it not? Maybe it would be better to conditionally render the entire widget area rather than specific widgets that are all likely to show the same CTA? Is there a case where some widgets should still be shown in an area which is inherently tied to some data? I don't recall if this was ever discussed in an issue before but I feel like there was a desire to render some alternate layout with less duplication of "no data" in known no data states.

[mxbclang]

Noting here that it would be great to revisit this as we do get many support topics asking for more details about these messages.

[marrrmarrr]

Thanks @bethanylang! Could you share some of the support topics to see what exactly people are confused about? @aaemnnosttv I'm working with Aaron on the zero-state dashboard, but this is still in early UXD stages. In the meantime, it would be great to surface clearer messages. @felixarntz does anything change in terms of widget rendering here given all the refactoring of JS APIs and components that's been completed in the meantime? How big of a lift is this?

[mxbclang]

@marrrmarrr Sure thing!

• https://wordpress.org/support/topic/analytics-gathering-data-analytics-data-is-not-yet-available-please-check-back-5/
• https://www.google.com/url?q=https://wordpress.org/support/topic/not-gathering-data/
• https://wordpress.org/support/topic/analytics-gathering-data-analytics-data-is-not-yet-available-please-check-back-4/
• https://wordpress.org/support/topic/search-console-gathering-data-search-console-data-is-not-yet-available/
• https://wordpress.org/support/topic/analytics-gathering-data-analytics-data-is-not-yet-available-please-check-back-3/

As you can see, there seems to be some concern that something is "wrong" based upon the "gathering data" messages, as opposed to this being a message indicating that things are connected, but data is not yet available. Felix mentioned on a meeting yesterday that it might be helpful to provide some more personalized detail here if possible, i.e. "Analytics was successfully connected on DD/MM/YYYY. It takes a few days to collect data for display here. Please check back later."

[eclarke1]

@felixarntz @marrrmarrr I spotted this ticket in the Backlog column as a P0. I presume this will actually relate to the work we want to complete in the new Zero Data States epic. Should we consider this together rather than progressing with this ticket, and then doing UX on Zero Data States afterwards?

[felixarntz]

@eclarke1 Good point. The main focus of this issue is to implement logic and provide more specific messaging for why there may not be data available (e.g. Analytics property was just created, site has no content yet etc.).

I'd say it's decoupled from the UX work in the epic, but it does make sense to consider it together. This one would actually be a good candidate for a small PRD and design doc, so I wonder whether we should still treat it as its own epic (e.g. "Tailored zero state messages"), since none of the two parts needs to block the other one at all. Thoughts @marrrmarrr?

We haven't prioritized this for Q3 though, maybe we should look into it for Q4. Technically, this issue has been stalled for a while, so I'll now finally mark it as such.

[eclarke1]

@felixarntz that's really great o understand thank you. I will create a new epic in Asana and add to the backlog for "Tailored zero state messages" and we can certainly consider it's priority for Q4. Good to know the "Zero data states" epic is separate also, and they do not block each other.

[marrrmarrr]

@felixarntz do you mean this would involve changes in the logic of displaying all zero states?

[felixarntz]

@marrrmarrr Yes, it would be about adding logic to get more helpful messages on why there might be a certain zero state. Instead of just saying "You have no data" it could based on additional logic include notes like:

• This may be because you just recently created this Analytics property.
• This may be because your site is still quite new.
• This may be because your site is not indexable by Google Search.