Thanks for flagging this. I have a couple of follow-up questions:
What is the magnitude of the issue? This is the first question we ask when investing potential issues like this. We cannot expect the data from the Javascript tracker to be 100% perfect because it runs in an environment other actors (human or not) can mess with. If this affects 1% or 10% of users, it’s something that requires further investigation on our end. If it affects 1 in a million users, it’s one of those rare edge cases that won’t affect the conclusions that are drawn from the data (the reason we track events in the first place).
What versions of the Javascript tracker are affected? Do the events have something in common? It could be limited to certain platforms, devices, browsers or browser versions, or pages on the website.
Does it happen over and over again for these users? In other words, is it the case that users always these issues? Or do some users run into the issue once, but then behave normally on a later visit to the site?
case 1: same domain_sessionid the user_id changes during the session :
This issue is not much in magnitude but is still present across many days. Roughly this issue counts to less than 1% of data.
case 3: domain_sessionid changes in between page_views and then change back to old value again:
This issue counts roughly 5-6% of the data on daily basis. we are getting around 1.5-2.5 millions page_views per day, out which 5-6% of distinct sessions are erroneous.
case 4: domain_sessionid spans over 2-3 days (sometimes more than 3 days):
Again if we look at magnitude than this issue is with around 0.5%-2% of data. Though the numbers may be less but I feel this will effect the analysis drawn out of data as session time in such cases is in days (in some cases same session lasts for 10-20 days).
We are using tracker version js-2.5.3
We did not find any pattern, but we are on it if we can find some similarity in the sessions/users getting effected by these issues. But by looking at the data we can say, though not surely, that these issues are not limited to a limited set of users/sessions. Will update you once we get to know something.
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:
Regarding case 1: isn’t it plausible that a small number of visitors logs into more than one account in a single session? Perhaps I misunderstand the issue.
Regarding case 3: what is used as the user identifier in this case, the user ID or the domain user ID? If it’s the user ID, I’d investigate whether or not these are users that are logged in one more than one browser or device at once.
If it’s the domain user ID, I’d like to confirm that the events are sorted on the dvce_created_tstamp. Would you mind sharing the SQL you’re running to investigate this case?
for case 3 we are using following queries, we tried query for both (domain_userid & user_id) because in some cases only domain_sessionid changes and domain_userid & user_id remain same and in some cases domain_sessionid & domain_userid both changes. Yes the results we checked after sorting by dvce_created_tsamp.
queries are :
WITH multiple_sessions_domain_userid
AS (SELECT user_id,Count(DISTINCT domain_sessionid) AS distinct_sessions,
To_char(
collector_tstamp, 'YYYY-MM-DD HH24') AS ct_hour
FROM atomic.events
WHERE collector_tstamp BETWEEN '2016-07-01' AND '2016-07-11'
AND platform = 'web'
GROUP BY 1,3)
SELECT LEFT(ct_hour, 10),Count(1),user_id
FROM multiple_sessions_domain_userid
WHERE distinct_sessions >= 2
GROUP BY 1,3;
WITH multiple_sessions_domain_userid
AS (SELECT domain_userid,Count(DISTINCT domain_sessionid) AS
distinct_sessions,
To_char(
collector_tstamp, 'YYYY-MM-DD HH24') AS ct_hour
FROM atomic.events
WHERE collector_tstamp BETWEEN '2016-07-01' AND '2016-07-11'
AND platform = 'web'
GROUP BY 1,3)
SELECT LEFT(ct_hour, 10),Count(1),domain_userid
FROM multiple_sessions_domain_userid
WHERE distinct_sessions >= 2
GROUP BY 1,3;
for case 1: we are using the following query
WITH multiple_user_per_domain_sessioid
AS (SELECT domain_sessionid,Count(DISTINCT user_id) AS distinct_users,
Date(collector_tstamp)
FROM atomic.events
WHERE collector_tstamp BETWEEN '2016-07-01' AND '2016-07-11'
AND platform = 'web'
AND name_tracker = 'production'
GROUP BY 1,3)
SELECT domain_sessionid,distinct_users
FROM multiple_user_per_domain_sessioid
WHERE distinct_users >= 2;
Also in our case it can not be the case where a user logs into multiple accounts in same session.
For case 3 (query using user_id as identifier) please go through the screenshot.
Thanks for providing this - I’ll have a closer look at the queries later.
I have a follow-up question on this:
How is that enforced?
Also, looking at the screenshot, it does look like there is a 1-1 correspondence between domain_userid and domain_sessionid. This suggests that there are multiple sessions open in parallel, in different sandboxes, all with the same user_id. I’d like to make 100% sure that this is not what’s happening before continuing, because it would be the most plausible explanation.
We observed one pattern for the case where the domain_sessionid changes in between. When on clicking a link the link opens in a new pop-up window, we observed that domain_sessionid & domain_userid both changes, while on other pages both continues to have the old values.
so it explains the behavior in screenshot shared previously. But question still remains why is this happening? Also in which cases domain_sessionid changes during tracking?
one update on the issue, where on window popups session_id is changing.
suppose our domain is www.xyz.com, now when I checked when the issue was arising I found that the snowplow set 2 cookies named ‘_sp_id’ & ‘_sp_ses’. I found there are 2 cookies for '_sp_id ’ & ‘_sp_ses’ e.g.
a) ‘_sp_id.6fbe’ & '_sp_id.fc2b’
b) ‘_sp_ses.6fbe’ & ‘_sp_ses.fc2b’
Question is :
Why 2 cookies are being set for sp_id & sp_ses?
Second,
Both the above cookies are showing the domain set to www.xyz.com (our domain), when I set the domain during the tracker initialization, using ‘cookieDomain’ parameter, I set it to ‘.xyz.com’ then for popups no new session is started i.e. session_id remains same as other pages.
Why setting domain to ‘.xyz.com’ works? Because on our site when a link opens in a popup, domain name is same as the parent window then why setting domain name during tracker initialization works here?
