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