umami
umami copied to clipboard
Average Visit Time Calculation
I'm testing on a site where users load a web page with inline video and often stay for long periods of time. Running Umami and Google Analytics in parallel has Visitor and Page counts in the same general ballpark but Visit Duration in Umami is 1-2 minutes where Google Analytics shows as 40min to over 1 Hours averages. The longer duration is more correct for this site.
Is there a default timeout or delta between page views that can be tweaked in code or possible exposed in configuration?
To experiment, I added client side code to register an event every minute to see if that had any effect on average visit duration and it did not appear to even though Umami did track thousands of events.
The visit time calculation is based on the delta between page visits. So if a user comes to a page, watches a video, and doesn't visit any other pages, we can't tell where there visit ended. We would probably have to come up with a solution to "ping" umami with the updated time while the user sits on the page.
Totally makes sense. Thoughts/questions:
Can an event be taken into account or act as that "ping" vs just the page view?
Or could there be a configuration setting that exposes that max delta time? I'm taking a wild guess that it's around 5 minutes just looking at some of my reports.
I'm not completely familiar with the analytics script. But couldn't we add a visibilitychange
handler in the analytics script and use Navigator.sendBeacon()
there to send information to umami once the user leaves a page?
MDN provides following example:
document.addEventListener('visibilitychange', function logData() {
if (document.visibilityState === 'hidden') {
navigator.sendBeacon('/log', analyticsData);
}
});
To add to @gnarlex's suggestion, initial page load and visibilityState
's 'visible' and 'hidden' values can be used to track when the page enters and leaves focus. I think it could be feasible to send this delta to the server-side. This should handle the elapsed time of each view when only visiting one page, navigating between site pages, or navigating between browser tabs.
One possible concern is that the tracker's current XMLHttpRequest
appears to cache the server's response whereas Navigator.sendBeacon()
would only be able to respond true or false to show if the request was queued.
Are there any plans to update the method for calculating the visit time in the near future? We're in a similar situation as we have a web app that people can use for long periods without navigating between different pages. We use events for various actions on the page so taking these into account for the visit time would be useful. Thanks
I have been playing around with this a bit. I think the solution is,
- Create a new column in the database, in the session table, called
ended_at
. - Then a new collection type, called
sessionend
. - In the tracker, add an event listener for visibility change and send a
sessionend
request if the visibility state is hidden. (mentioned previously by @gnarlex, but using fetch keepalive). - When
sessionend
request is received, change the session table to update theended_at
for the particular session.
Then the visit time can be calculated using the delta between created_at
and ended_at
for the particular session.
@mikecao, could this be a possible solution?
Doesn't the visibility change event also fire when a tab gets inactive? I wonder if it would duplicate views or something in cases where the user leaves the tab then comes back.
Doesn't the visibility change event also fire when a tab gets inactive? I wonder if it would duplicate views or something in cases where the user leaves the tab then comes back.
@jakobbouchard, I don't think that will be a problem, since every time the visibility change occurs (hidden), a request will be fired. And each time the timestamp will be updated in the database. The last timestamp value will only be in the record, the other values will be discarded.
@rohandebsarkar Oh yeah that makes sense!