search

divolte / divolte-collector

Divolte Collector
https://divolte.io/
Apache License 2.0
283 stars 77 forks source link

Persist event queue on client #150

Open fvlankvelt opened 7 years ago

fvlankvelt commented 7 years ago

The event queue on the client is not persistent, so pending events are lost when the visitor navigates away from a page. Persisting the queue in local storage (or even just session storage) should alleviate the problem.

friso commented 7 years ago

HTTP is stateless. There is no such thing as session storage, so any construct there has to be server side (which in turn would rely on delivering events before navigating).

Local storage is an option. You only get to see the contents of local storage next time the JS is loaded. When navigating to a different site, these events are still lost until rendezvous. Question is: are these events still worth your while if they arrive a week later? And would that mean from a session perspective (since sessions are a time based, artificial construct in HTTP)?

Another option is to block the browser from navigating away until the event queue is flushed. This has some UX impact, so you would want to limit the amount of time you block the browser from navigating away and do a best effort there.

On top of that, there is a baecon API, which is somewhat experimental, I believe, but usable in some browsers.

Perhaps you can elaborate a bit on how this limitation affects your use case concretely?

fvlankvelt commented 7 years ago

Beacon certainly looks promising, though mobile support seems to be lacking.

The use case is not so much pending events when the user leaves the site, as it is events that are fired right before a navigation on the site. E.g. a 'click' event which might be able to log some information that is not available in the next page. Such an event should not block the actual transition and it's fine to post it to Divolte upon the next page load.

I'm not sure how pending events can best handled when the visitor browses away from the site. Probably the only way to reliably send those requests is by synchronously flushing the queue.

asnare commented 7 years ago

There will be some movement on this front soon; specifically we're planning to improve the situation for click-through and click-out events. As you've noted, the problem here is that navigation (i.e. page unload) typically needs to be deferred until the event queue has drained.

Local storage (including emulation via cookies) is a bit of a pain. Last time I looked it wasn't available across the landscape of browsers that we support. In addition, as @friso noted it introduces problems because there can be a large difference between the time an event was raised and delivered. (For web there's normally an assumption that they're close together.)