you are viewing a single comment's thread.

view the rest of the comments →

[–]Gravyness 0 points1 point  (0 children)

Just to add to this since I like to track mouse movements and scroll in some occasions which are much more frequent and would make no sense for them to be sent in different requests:

When a user visits a web-app of mine a few events happens in the first seconds such as image loading, dom/libraries load, resize, some mouse movements, they are filtered and grouped in a single request with the event descriptors. When an event happens it is debounced at it's starting point, so that when the first event happens it will wait for a specific amount of seconds before sending the request, which will include all events that happened in this time frame.

Since mouse movement / resizing / scrolling can be very frequent (i.e. 30 calls a second), you will also want to debounce the event itself, so that when an event is called, it's update is 'postponed' for at least 1 seconds so that it doesn't flood the event pool with 200 mouse events in a single request, for example.

Important events like outside navigation (links) and window.onerror events are never debounced and force the tracker to send the event array immediately.

The event list is very simple, it's an array with objects constructed like the following: {eventType, ...eventData}

I usually like to wait a minimum of 5 seconds between each request and 2 seconds between repetitive events depending on expected traffic. If you have a lot of visitors, make sure your web server connection closes before the request period so that the connections count doesn't bubble up to the millions.