Within the discovery team we are now looking into tracking dwell time and bounce rate for the pages linked from the SERP's. To accurately track dwell time we need to fire an event in the unload handler of article pages. Poking around in the EventLogging code i see we are now using sendBeacon if it is available, and thats great. The problem is all of the browsers that do not have sendBeacon (many) will not send this event. They will inject an img tag that will not be processed as the page is being unloaded.
Searching around I saw some discussion about this almost a year ago, in may 2014, before sendBeacon support was added (in nov 2014), titled "[Analytics] Using EventLogging for funnel analysis". There it was proposed to push the events into localStorage to be sent during a future page view. I don't see any other viable options, so wondering if there is any reason i shouldn't look into implementing this now (with the jStorage wrapper of localStorage available in core)?
Erik B.
I, for one, am ok with the localStorage stash for later approach. Seems like a sensible fallback for when sendBeacon is not available. Before you go and do a lot of work though, it might be good to test how likely we are to get that localStorage data back and sent as an event later. We could run an experiment sending an event every time we add something to localStorage and another every time we find what we added in a subsequent browser session.
The reason for that experiment is that the time lag between adding the event and sending it, or the percentage of the time that it even happens at all, might make this solution less useful than you'd think at first.
On Mon, Jun 8, 2015 at 6:57 PM, Erik Bernhardson <ebernhardson@wikimedia.org
wrote:
Within the discovery team we are now looking into tracking dwell time and bounce rate for the pages linked from the SERP's. To accurately track dwell time we need to fire an event in the unload handler of article pages. Poking around in the EventLogging code i see we are now using sendBeacon if it is available, and thats great. The problem is all of the browsers that do not have sendBeacon (many) will not send this event. They will inject an img tag that will not be processed as the page is being unloaded.
Searching around I saw some discussion about this almost a year ago, in may 2014, before sendBeacon support was added (in nov 2014), titled "[Analytics] Using EventLogging for funnel analysis". There it was proposed to push the events into localStorage to be sent during a future page view. I don't see any other viable options, so wondering if there is any reason i shouldn't look into implementing this now (with the jStorage wrapper of localStorage available in core)?
Erik B.
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
On Mon, Jun 8, 2015 at 3:57 PM, Erik Bernhardson <ebernhardson@wikimedia.org
wrote:
Searching around I saw some discussion about this almost a year ago, in may 2014, before sendBeacon support was added (in nov 2014), titled "[Analytics] Using EventLogging for funnel analysis". There it was proposed to push the events into localStorage to be sent during a future page view. I don't see any other viable options, so wondering if there is any reason i shouldn't look into implementing this now (with the jStorage wrapper of localStorage available in core)?
There are basically three possibilities: - just accepts that some visits won't be logged. This is inaccurate, but given that some of the time you will fail anyway (no unload support, leaving the page in a way that does not call the unload handler, the user leaving the site and not coming back, localStorage disabled/not supported/aggressively purged), this might not be as bad as it sounds, and works out of the box. Can be improved somewhat by sending the EL request even when there is no sendBeacon support (might or might not be successful depending on how long unload takes - IIRC from our pre-sendBeacon experiments this still worked about half the time). - block unloading until the EL call finishes. Not really an option unless your sample size is tiny. OTOH the only way to get truly unbiased results (apart from the browsers which don't support unload but there is not much to be done about that). - use localStorage, as you described. Still inaccurate but less so than the first option.
If you go with localStorage, that wheel has been invented at least two times already (by the mobile web team and the old growth team, I believe) so it's worth checking out their code before writing this from scratch.