I’ve noticed Firefox 76 assigns a new SP cookie value upon page refresh and/or new tab. The impact of this is “DOMAIN_USERID” changes under the aforementioned conditions and subsequently “DOMAIN_SESSIONIDX” never increments higher than 1 therefore I can’t increase the visit count with Firefox.
In comparison, Chrome 81 doesn’t have this issue, in testing i’ve incremented the DOMAIN_SESSIONIDX to ‘46’. So far this issue is only limited to Firefox.
Anyone encounter this issue or have any suggestions?
@kfitzpatrick, is your tracking cookie stored as the 3rd party? Firefox probably blocks 3rd party cookie which results in resetting domain user ID and the session.
Thanks for the response @ihor,
I’m not explicitly setting it as 3rd party, really at this point I’m only testing on localhost and all I’ve done with sp_cookie is set the ‘discoverRootDomain: true’. I’m using the most current sp.js hosted locally along side index.html while collector is AWS hosted, no issue on the backend that’s all working perfectly, getting Yoffset, attribution, useragent enrichment etc. Firefox cookie issue is the only real stumbling block so far, the session ‘*’ but also the value sp_id changes on mentioned issue.
This is the expected behaviour and one you can eventually expect to see in Chrome too.
Safari will also exhibit similar behaviour due to ITP restrictions. You should find that disabling Enhanced Tracking Protection in Firefox leads to the cookie behaving as expected but this enabled by default.
These browser based changes are designed to protect user privacy and prevent third party tracking. We’ll likely see all Chromium based browsers adopting the same behaviour too soon (such as the case with Brave).
Due to these changes,
You’d be better placed to ensure your collector is running on a first party domain. i.e. if your site is www.example.com then your collector could be on sp.example.com or similar.
This means that the cookie which the collector sets is not restricted by ITP and similar as it behaves as a first party cookie. This sets the
network_userid in the atomic events table and should persist for up to 2 years based on your collector configuration.
For a bit more context on ITP in particular, you might find this blog post interesting: https://snowplowanalytics.com/blog/2019/12/16/how-itp-2.3-expands-on-itp-2.1-and-2.2-and-what-it-means-for-your-web-analytics/
Hi @PaulBoocock, appreciate the response on the weekend.
Thanks for the blog link, after digesting I understand now.