Hello guys,
For JS/Web, I’ve noted commonly on Tablets (but not all) that for every EVENT a new DOMAIN_SESSIONID is created while the DOMAIN_USERID is constant, this increments DOMAIN_SESSIONIDX which looks like:
I’ve found this to be common on Tablets, so much so an Average DOMAIN_SESSIONIDX over a short period looks like this:
If the 1st party cookie was blocked then I’d expect DOMAIN_USERID to be Null but this isn’t the case.
What would cause the DOMAIN_USERID to stay constant but not the DOMAIN_SESSIONID?
And I guess why would the tracker increment the session/IDX with a constant DOMAIN_USERID in place?
Thanks
Kyle
Can you share your JS tracker initialisation code too? Specifically the newTracker call?
Hi @PaulBoocock
<!-- Snowplow starts plowing -->
<script type="text/javascript">
(function(p, l, o, w, i, n, g) {
if (!p[i]) {
p.GlobalSnowplowNamespace = p.GlobalSnowplowNamespace || [];
p.GlobalSnowplowNamespace.push(i);
p[i] = function() {
(p[i].q = p[i].q || []).push(arguments)
};
p[i].q = p[i].q || [];
n = l.createElement(o);
g = l.getElementsByTagName(o)[0];
n.async = 1;
n.src = w;
g.parentNode.insertBefore(n, g)
}
}(window, document, "script", "//company.company.com/js-engine/company-sp.js", "snowplow")); //JS 2.17.0
window.snowplow('newTracker', 'co', 'snowplow.company.com', { //load balancer
appId: '477107',
discoverRootDomain: true,
stateStorageStrategy: 'cookieAndLocalStorage',
contexts: {
webPage: true,
gaCookies: true,
visibilitychange: true,
performanceTiming: true,
timing: true,
}
});
Thanks
Kyle
I broke it down much further and found that its predominantly from Apple iPad - Mobile Safari - 12.1.x, and contained within version 12, there is some Samsung Internet on Samsung Android also but its rarity of use after breaking down the versions means its an out-liar.
Kyle
Interesting! Do you know if the website this is running on is a Single Page Application or not? The ID’s are stored in memory, as well as cookies, so behave a little differently when it’s a Single Page App vs not. Trying to figure out what might be going on here 
It is single page application for the most part. ‘newTracker’ would be called for each ‘screen event’ or new page as the user would see it, so if a visit was to go from search (step1) to search results (step2) for example, ‘newTracker’ would be called. However Step 3 opens on a new tab and TI_ happens as well as a new page, same domain etc but it’s a UX decision.
‘newTracker’ aside even between calling page_views we have structs (SE_) like and unstruct (PP_ X/Y offset min/max) for example, but they are incrementing the Sess ID too, as well as TR_ and TI_.
What I find most strange is this is only in iPad and only in AGENT_NAME_VERSION_MAJOR ‘Safari 12’. It’s not in 13, 14, 11, 10 for example.
Here is the exclusion of all mobile Safari 12, for the same example shown previously:
This certainly sounds like some unexpected behaviour in Safari 12 (and maybe one or two other browsers). I’ll dig into this today and see what I find.
2 Likes
Thanks @PaulBoocock I’ll dig into Samsung Internet 14 a bit more as maybe theres something here also.
Hey @PaulBoocock
Ok ‘Samsung 14’ from Tablet is fine, while IDX was high its just exceptionally low traffic for device/browser combination for the domains I was looking at.
So for Mobile Safari 12.1, I found something else interesting. Previously I was looking at the domains that had stateStorageStrategy: ‘cookieAndLockalStorage’ so the entire thread above is based on this and only the domains we host ourselves.
I also have other domains in that I’d be a 3rd party to the host. So if I had this switched on (cookieAndLockalStorage) then I’d be a 1st to myself but a 3rd to the host, therefore its off as per host request.
This of course as you know means no DOMAIN_USERID will be set and IDX never incremented however I will get a session ID for the visit.
So for this domain lets look for iPads for LIKE ‘Mobile safari 12.1%’
As you can see the DOMAIN_SESSIONID remain constant in absence of DOMAIN_USERID for the session.
I did also check to ensure each logically looks like 1 session per Id and it does, same location, UserAgent, ISP, Geo, plus url flow and actions all tie together as 1 session per 1 unique ID.
Not sure if this helps but figured it couldn’t hurt showing it.
K
Thanks for the extra info. I’m struggling to replicate this! I’ve tested on iPad Safari 12.1.4 so far and tried to reproduce it but I haven’t been able to get the same behaviour yet.
The last example is what I’d expect to happen, however it’s certainly interesting that the domain_sessionid is stable for a page view when you disable storage but isn’t when you have storage enabled. This suggests that something strange is going on with Safari 12 and cookies (like it’s saying we can read cookies but then we don’t get the value when we actually ask for). The latter example doesn’t attempt to use cookies at all, so its simply reading values stored in memory. I suspect this is a bug with an API in Safari 12 that we should try and handle. It’s not a huge surprise Safari 12 is by far the buggiest browser in our automated tests too.
I’ll continue trying to reproduce it to see if there’s a workaround we can implement.
I’ll prefix this answer with that I’m not 100% convinced this will fix it but I think it’s worth exploring, I also haven’t managed to reproduce on real iOS devices running iOS 12 and Safari 12.1 which is rather frustrating.
Some versions of Safari on iOS 12 have a known incompatibility with SameSite=None cookies and marks them as Strict. This shouldn’t actually be an issue but I’m wondering if there’s something else going on beyond the reported Safari bug.
SameSite=None is the current default for the tracker cookies since 2.14.0 however, given the now known incompatible clients it perhaps isn’t the best default and instead Lax would be a better option, but this would’ve been a breaking change with the existing behaviour before SameSite was introduced.
In the mean time, you can adjust this yourself and see if it helps (I’d love to know if it does help) it certainly won’t have any adverse effects as there is no need for the JavaScript set cookies to have a SameSite value of None unless you expect the Snowplow trackers cookies to be sent with requests beyond your Snowplow tracking (which is why we originally defaulted it to None, to maintain existing behaviour).
Taking your example above, you just need to do this:
window.snowplow('newTracker', 'co', 'snowplow.company.com', { //load balancer
appId: '477107',
discoverRootDomain: true,
stateStorageStrategy: 'cookieAndLocalStorage',
cookieSameSite: 'Lax',
contexts: {
webPage: true,
gaCookies: true,
visibilitychange: true,
performanceTiming: true,
timing: true,
}
});
1 Like
It certainly won’t hurt to try this. I put the JIRA ticket in, if I’m lucky it’ll merge and go live in the early afternoon Wednesday the 7th of July, if not I’ll need to wait a week.
I’ll keep you posted 
@PaulBoocock
You’re suspicion is correct!
Apologies for delay took a little longer to get it live than usual. The cookieSameSite Lax parm fixed the issue, domain_sessionidx no long increments for each event.
…and now grouped
Thanks very much on this
Kyle
1 Like
