Proposal: Metrics for web page abandonment

Currently, when users navigate away from a page before loading metrics like first contentful paint fire, the page’s analytics may not be loaded yet, and so the abandoned page load is not counted in the site’s analytics. This means client-side analytics, which many sites rely on, are blind to abandoned navigations that do not get to a point where the analytics script is able to execute and beacon a successful page hit.

This is a proposal for new APIs to close that gap.

My first thoughts for the possible overlap with the NEL API and the brief discussion on the proposal document.

Definition

Reading the NEL spec, as an engineer myself working on the whole stack of an application, I felt that it goes more into the technical/monitoring side of things, which certainly with some work, it can provide more high level insights, similar in nature to those we aim for. But still it resonates more with my development side and not the experience side, as it also never mentions the “user” abandoning the page. I see it as a more low-level capability for multiple use cases e.g. the subresource case (widget) which is mentioned in the NEL spec. To be honest I see NEL as massively useful and I foresee that the implementation will be mostly done on the framework world, e.g. libraries that add this to Express.js etc.

The web page abandonment definition though is carefully structured to aim at the experience of a user. Addressing the common case where for example a navigation might be initiated for the initial page load of an applicaiton, and with no network failure (which cannot be addressed by NEL), the user gets frustrated before reaching a FCP and he/she decides to abandon. The user-initiated-navigation-abandonment baseline as mentioned . That is the case that I see that we can address with our new metric. The main focus of it is experience and not just a compilation of NEL reported occurances.

Target Audience

As all would possibly understand, both of these initiatives have a share of the target audience I would call “user experience group”. This audience consists of people that care to evaluate, measure and improve the experience that a user has on their website. In my opinion, the web page abandonment proposal would win the vast majority of resonance with this group.

For the option that we provide initially (CRUX), we make it really easy for :

1. not so technical people

2. people with not much time to implement infrastructure needed for the Reporting/NEL APIs

to have this important information, available to them easily (along with all the other benefits that CRUX provides). This is one of the differentiating factors in my mind that can achieve the goal of making this metric an easily accessible and really strong factor to drive change, from multiple parts of an organization .

In my mind, I see the scenario of a marketeer/UX designer, checking out the CRUX report for this metric and understanding the importance of it, really probable. This would not be so “common” if as a requirement we need to have a custom collection and reporting infrastructure set from the development team (NEL case), which might never be shared with the rest of the organization.

That can really be made clear even by reading the goals of the proposal. Each goal has certain keywords that made the broader audience clear to me. Abandonment , Core User Experience , Analytics .

Looks like a very useful API. I wonder what happens if a page was served from within an iframe? Would an abandoned parent page also abandon the page in the iframe, or will it have a life cycle of its own?

A bigger concern is the relative inaccessibility of this new metric. From what I can tell, the Reporting API HTTP header is behind a flag and Chrome only, so no data at all from real users. ReportingObserver is Chrome-only, which also would mean missing a lot of data.

Even in a future state where both are broadly supported, the nature of Reporting API automatically excludes many website owners as they don’t have the resources for this kind of reporting infrastructure. I’m thinking the only alternative for those without reporting infrastructure would be to load their analytics script in a blocking way, which has its own downsides, and could even affect this metric in itself.

Or, and I would normally never advocate for a proprietary solution, use CRUX. By choice, via configuration, not as a default.

As a final unrelated thought, I’m seeing some assumptions/examples in the proposal regarding abandonment reasons: performance/frustration. Surely that would be a key use case but it’s colored and subjective. There can be plenty of other reasons. A user could have clicked in error, which is extremely common (especially on touch devices). An extension can trigger a new URL, which the user did not want. And so on.

I would opt to describe it a bit more neutral: the API is about tracking abandonment, regardless of reason, as the reason is not known, not from this API.

Services like https://report-uri.com/ exist, and can provide an option for small site owners to collect such information without setting up the infrastructure. One can also imagine open source reporting end-points, CDNs offering that as a service, etc.