Avg Time on Site: how is the last page visit handled?

[marcochiodo]

Looking at the source, avg_time_on_site is calculated from time_to_next_event, filtered to exclude values greater than 30 minutes or NULL. This means the last event in a session (where time_to_next_event is NULL) is excluded from the average.

The tracker script also doesn't seem to send any outgoing events (sendBeacon, visibilitychange, pagehide, etc.), so we were wondering: is the time spent on the last visited page intentionally not considered in the avg time calculation?

We tested sending a custom event via the API:

POST /api/event
{ "name": "heartbeat", "entity_id": "...", "url": "..." }

This gets recorded and correctly populates time_to_next_event on the previous event. We could use setInterval with the exported event() function as a workaround.

Two questions:

1. Is there a recommended way to capture time on the last page of a session?
2. Do custom event names like "heartbeat" affect the hits count in the dashboard, or are only "pageview" events counted?

Thanks!

[explodingcamera]

Hi! Yes, there are no custom events yet (every event is treated as a pageview for now) and time spent on the last page of a session isn't counted right now. I'd like to eventually revisit this, maybe by just adding support for custom events and/or a specific unload event that updates that duration. sendBeacon looks interesting, didn't that existed!

[marcochiodo]

It does exist, unfortunately it's quite unknown :) It's been widely available since 2018 —
here's the MDN page: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon

The basic usage looks like this:

document.addEventListener("visibilitychange", () => {
  if (document.visibilityState === "hidden") {
    navigator.sendBeacon("/api/event", analyticsData);
  }
});

As an alternative, fetch with keepAlive: true does the same thing.

---

Following up on your interest in improving avg time — I'd like to propose an approach.

The idea is to send an event on visibilitychange (hidden) using sendBeacon, so the
server can timestamp the real last moment a user was on a page.

I'd call it pagelastview rather than pageunload for a specific reason: on mobile, users
frequently switch apps and return without ever truly leaving the page. This means
visibilitychange can fire multiple times for a single pageview, producing multiple
pagelastview events per visit. pageunload would be semantically wrong in that context —
the user didn't unload anything. Multiple pagelastview events are actually useful: the last
one before the next pageview is the most accurate exit timestamp, and intermediate ones
could serve as keep-alive signals for long sessions.

I'll leave the query side to you since you know the data model best, but the intuition is
that the last pagelastview before the next pageview gives the true time-on-page,
server-side, with no client trust required.

On a related note: with custom events on the horizon, I'd suggest introducing a whitelist
for what counts as a hit in the dashboard — rather than every event name incrementing the hit
counter. pagelastview should clearly not count as a hit, and future custom events probably
shouldn't either unless explicitly opted in.

Would love to hear your thoughts!

[marcochiodo]

Quick heads up while implementing the pagelastview approach on our end — we ran into
a CORS issue with sendBeacon that's worth knowing about for when you add this to the
tracker.

sendBeacon with a Blob of type application/json triggers a CORS preflight (OPTIONS).
When the server responds with Access-Control-Allow-Origin: *, some browsers block the
request because wildcards are not allowed alongside credentials, which sendBeacon
attaches implicitly in certain configurations:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource
at 'https://liwan-01.chdev.eu/api/event'. (Reason: Credential is not supported if the CORS
header 'Access-Control-Allow-Origin' is '*').

Sending text/plain (a CORS "simple" content type, no preflight) avoids the issue, but
then the server rejects the body because it expects Content-Type: application/json.

The fix that works: fetch with keepalive: true

fetch with keepalive: true behaves like sendBeacon — the browser keeps the request
alive even if the page is being unloaded — but without the credential issue. Works reliably
in visibilitychange:

function sendEvent(name: string) {
    fetch(ENDPOINT, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ name, entity_id: ENTITY, url: location.href, referrer: document.referrer }),
        keepalive: true,
    }).catch(() => {});
}

document.addEventListener('visibilitychange', () => {
    if (document.visibilityState === 'hidden') {
        sendEvent('pagelastview');
    }
});

So for the tracker implementation, sendBeacon can probably be skipped entirely in favor
of fetch + keepalive: true — simpler, no CORS issues, same reliability guarantee.

I'm currently testing this approach on one of my sites by manually sending pageview and
pagelastview events with fetch, and avg time is already showing up correctly!

You can see it in action at https://www.vanessafemia.it/ — open the network tab in devtools
and switch to another tab, you'll see the pagelastview request fire. Tab/browser close is
harder to test but visibilitychange should cover it the same way.