Hi @rahul,
Thanks for the detailed response.
I recommend upgrading to the latest version of our Javascript tracker. I don’t expect the upgrade will prevent all this from happening again, but I’d like to make sure nonetheless. Upgrading the Javascript tracker will also make the domain user ID a UUID (reduces the likelihood of collisions) and add the device sent timestamp (to improve timetracking).
Regarding case 4: is this measured using the collector_tstamp or the dvce_created_tstamp? We expect a small number of events to arrive late. For instance, if the device went offline or if the visitor left the website before the tracker had time to send the last event. These events are cached and sent whenever the visitor re-opens the website. In those cases, the collector timestamp will reflect when the event was sent, not created.
As mentioned before, the latest version of the JS tracker attaches a dvce_sent_tstamp, which is used to calculate the derived_tstamp (our best guess as to when the event was created). I recommend using the derived timestamp going forward – but the event must have been sent with JS tracker 2.6.0 or later and enriched on Snowplow 71 or later. If not, the dvce_created_tstamp can be used to compare events that were sent from the same device.
That said, if some sessions do indeed appear to last for a long time for no apparent reason, that will skew the session time if it’s calculated at the time difference between the first and last event. However, I would recommend against using this as a metric. You can use page ping events to get a precise measurement of how long a visitor was active on a page – see this post:
http://discourse.snowplow.io/t/logic-behind-time-engaged-with-minutes/344
I’ll follow-up with a second post that addresses the other cases.
Christophe