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.