I’m sorry if there is already a post for it, but so far I haven’t found anything related.
The collector is running on its own domain and is used by multiple sites of ours.
The Clojure collector sets a 3rd party cookie named sp, which contains the user id, if I’m not mistaken.
But the current chrome version already warns that this won’t work with the upcoming release.
A cookie associated with a cross-site resource at http://our-tracking-domain.com was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at Chrome Platform Status and Chrome Platform Status.
The Clojure collector & the Elastic Beanstalk-backed pipeline are quite old tech now - Amazon are deprecating support for EB in fact, which has led us at Snowplow begin to phase the Clojure collector out of support - there’s a detailed post form Yali here, which might be useful in understanding the associated decisions.
The Scala collector does indeed have these features, but they’re not planned for Clojure collector. I think the best thing to do to handle the changing cookie landscape, and to future-proof your stack, is to look into an upgrade.
There are some people in the community with experience of this kind of upgrade, so I’m optimistic that we’ll be able to help you get your head around that process if it’s the route you do go for!
Amazon aren’t deprecating support for Elastic Beanstalk entirely - just Tomcat 8.0 (which the Clojure collector) on 1st March 2020. There’s a list of the other platforms / versions being deprecated here.
Thanks for pointing that out, I wasn’t aware of that. I guess we have to look into the setup of the Scala collector then. Are there any upgrade articles or best practices that we can follow through? Or should we simply follow the wiki?
Thanks for the clarification Mike, my bad on that one - the details were hazy but yes, it’s tomcat 8 support that’s the sticking point, & our planned deprecation of batch is the real consideration as to why we’re not evolving the Clojure collector to handle this.
That is correct. It will cause the clojure collector to generate a new network_userid for all requests that don’t include the cookie.
So if you are counting users via the network_userid then this number will become inflated once Chrome roll out these changes.