New metrics to consider from GA4: Percentage scrolled

[taceybadgerbrook]

GA4 provides slightly different data compared to Universal Analytics (aka Google Analytics.) While this means some metrics like bounce rate won't be available, in many cases, the new data is worth considering adding to the current KPIs.

[taceybadgerbrook]

Scrolls

Definition: the first time a user reaches the bottom of each page (i.e., when a 90% vertical depth becomes visible). The event populates the Percent scrolled dimension.

Why is Explore/Engagement report/page path + query string X percent scrolled empty? Is it because data was not collected before importing this dimension on 28 September?

We might want to change the scroll depth on the basis that lots of people don't scroll down to 90%. We could change this to 50% by setting up a custom tag in GTM. Here's an article showing how.

[jennpb]

Slack discussion https://wellcome.slack.com/archives/C04KB3PFGCV/p1676643761036419

we're not restricted to GA4's default scroll event, i.e. tacking a single percentage. We could track as many arbitrary scroll depths we want. We could also use the element visibility trigger, which may be a better way of understanding behaviour. This event fires whenever a particular element we specify appears in the browser window.

[jennpb]

Just thinking about where/why we might use these options:

Single percentage scroll depth (90% default)

• Useful to keep as is if we don't think we'll do anything with the data!
• Useful as a starting point until we have a need to monitor scroll depth

My hunch is that a single percentage scroll depth sitewide is most useful for sites that have more consistent content types, with roughly similar page lengths - single-page websites, apps, document-heavy sites etc. The variety of our content, and the various placements of calls to action, mean it's less likely to deliver any useful sitewide insights, even if we modify it to a shallower depth, e.g. 75%.

Arbitrary scroll depths

• Could set arbitrary scroll depths for specific content types: for example, we know we want people to get to the bottom of articles, so setting a 75% depth for /articles versus a 50% depth for functional content pages where we want to ensure that the most important info is prioritised toward the top half of the page.

This feels a bit unnecessary if we can use the third option, element visibility triggers.

Element visibility trigger

• Useful to define the end of the page content, before user reaches page furniture. For example, we know that the newsletter signup component is on all Prismic-created and landing pages. We could set a visibility trigger at the newsletter signup which would be a proxy indicator for the user having reached the bottom of the content.
• Useful where we have pages with multiple calls to action, for example a /works page that has long information, plus digitised item and requestable item. We may wish to identify those elements so we can understand what prevents users from seeing the content they need.