anniesullie / web-page-abandonment-api Goto Github PK

One scenario that has come up with a customer site, where I'd like to use the Abandonment API, is what should or shouldn't happen when an "abandon" occurs that is desirable from the site owner's POV.

I think this would only apply if the Abandonment API supported a user signal from analytics providers to note when a page is no longer abandoned, i.e. analytics is "ready" to measure the rest of the experience. If the Abandonment API only supports waiting until FCP, I don't think this scenario applies.

Imagine this scenario:

• Site's homepage registers Abandonment API via HTTP response header
• Site also registers that it needs to wait until analytics are loaded (e.g. via JavaScript callback or global)
• User navigates to site, and FCP happens with a mostly-blank screen but a Login button in the header bar
• User clicks on the Login button (that navigates to /login), before the rest of the page has been loaded and analytics has arrived

In this case, the Login button could be considered a good thing, i.e. a conversion, even though the user didn't wait for the page to fully load or analytics to arrive.

What would the Abandonment API do in this case? Since the analytics switch didn't happen, I assume it would report it as an Abandon. And I think it should report something, since analytics isn't there yet to report anything.

But it might be useful if the report helped indicate this may be an "OK" abandon for the site owner. Some thoughts:

• The report payload could note the "phase" that it happened, i.e. after FCP but before analytics-ready
• The report payload could note that the navigation was to another same-origin URL, e.g. with the destination-url or even just a same-origin-abandon: true flag

Alternatively, in this scenario, the site owner could hook into known exit actions (e.g. Login button click) and call the "analytics-ready" API so an Abandon isn't registered, but that would take additional work to get right.

FCP's appealing because it's a clearly defined point in the page load lifecycle but I suspect it's too early to measure abandonment.

I've had a few clients lately where the menu bar has rendered by the content has taken a while to arrive and we've seen visitors abandon while waiting for the main content.

To me it feels like we should treat someone leaving before the page is useful, or usable as abandonment but aware that's probably not possible for browsers to measure without the page being instrumented.

If we use a reporting API to report abandonment, there will be an overlap with the abandoned error in the Network Error Logging API. That API is similar to this one, but subtly different:

• It reports abandonment for all network requests, not just page loads.
• It only reports abandonment for the request, not the page load. For example, if the initial HTML of the page loads fully, but the user abandons the page before content displays, it's not abandonment from the NEL perspective but it is from this API's perspective.

I thought about this idea too, but it's not clear from the explainer why this is considered a worse alternative to FCP? If the intention is to let analytics providers report their metrics, wouldn't letting them specify when the load is no longer an abort be a reasonable solution? There are some potential problems with this:

• Requires intentional annotation in order to get any valuable data, whereas the FCP approach does not. In particular, I'm not sure if reporting everything as an abort as the no-op is reasonable from a performance standpoint...

• There can be multiple analytics providers or multiple performance aggregators for the same webpage, so it could be problematic if the first one says that the load is no longer an abort, and incentivizes moving the aggregation earlier. Not sure how common this is.

It's not clear to me what the goal is here. Is this meant to be a web API, as specified by the link? If it is, and not meant to be a Chrome-specific tool, then I'm not sure 'Chrome User Experience Report' would be a feasible option.

As a scenario mentioned on #6 , I believe we should clarify if and when will we be enabling the measurement of abandonment for navigations.

When to enable measurement:

• Navigation on different TLD
• Navigation on different FQDN
• Navigation on different path
  Other cases...?

Will this be configurable ?
Will we be able to switch between those with a configuration parameter ?

Saw "WebPerfWG call - June 18th 2020" video and these are some thoughts about the Abandonment API.

FCP seems a good metric to use in this case but it might be too early to measure Abandonment, not all websites will have the analytics systems ready at that point. We'll have users that abandon in the time window between FCP and analytics system load.

Personally I think that TTI could be a better replacement, even if TTI is not the best metric to track in the wild as many users exit the page before that, for the API this won't be a problem though. Even if users exit before TTI, calling the "analytics-ready" API to say "my tracking system is working" will stop calculating that as abandonment.

After all, the intent of the new API is to measure untracked abandonments so the main goal is to understand if and when an analytics system is ready to track a visit.

Eventually, it would be useful to have "reasons" for abandonment such as "click on the back button", "click on --", "new destination URL", "tab close", "User aborted the resource fetch" (think it's possible to copy this from NEL), or something similar, this to help webmaster debugging and filtering those specific website behaviours that shouldn't be counted as abandonment.

If this were to be exposed via the Reporting API, what kind of data might the payload contain?

Some thoughts:

1. Obviously the standard fields such as url etc would be desired
2. The elapsed time into the navigation before they abandoned would be nice
3. The "phase"? i.e. did they reach "waiting on server response", did they get "first bytes" etc
4. Would it be possible to know what action they took to abandon? i.e. "back" navigation vs "tab close"?