We have setup a single Scala Stream Collector server (xxx.cloudfront.net) to track multiple webpages under different domains (domain1.com, domain2.com, domain3.com).
Recently noted that third-party cookies has been blocked under ITP2.1 and also read ITP2.1 and its effect for Snowplow users for the handling. Understand that we can setup multiple endpoints for the single collector and make network_userid as first party cookie under the tracking website domains.
Below is my understanding:
- Do not use xxx.cloudfront.net as the domain of collector
- Add c.domain1.com, c.domain2.com, c.domain3.com as the CNAME of the collectors
- track using same domain endpoint
- then set-cookie of network_userid from collector can save as first party cookie under domain1, domain2 and domain3
HOWEVER, the network_userid will become domain specific which means they are not the same for multiple domains? somehow it becomes a domain_userid-like?
Please correct if I am wrong. and also guide me if there is any solution that can track multiple domains with third-party cookies being blocked. Thanks.
Hi @Shing_Poon, welcome to Discourse!
When using your own domain as a CNAME for the collector, you are correct that the cookie which represents
network_userid will be set against this domain.
network_userid is designed to give you first party cookies on a specific domain, and is not really designed to enable cross site user tracking in a first party manner (which is pretty much going to become impossible given the direction browsers are moving).
There are a couple of options for you here:
The simple option, is to run your collector on a third party domain and understand that you’ll have third party cookies so exact user counts from some browsers (Safari mainly) will be unreliable. The cookie should be set to SameSite=None; Secure in the collector configuration, so when Chrome rolls out the SameSite changes then this continues to work for Chrome (and Edge).
Run your collector on multiple CNAMEs, as you are doing, to get accurate first party network_userid so you can do accurate user counts on those domains. Use other userid fields to build a identity stitching table as a data modelling step, that can help you build a more accurate picture of users across the domains based on the variety of userids Snowplow can track (even better if you have, and track, your own user information for authenticated users in custom entities). See here for more ideas on this concept: Identifying users (identity stitching)
My favourite option is to move to a model that is going to be more robust with the direction the browsers are moving, allow users to maintain their individual privacy and start thinking of users in Cohorts rather than trying to identify specific users. i.e. group users with the same IP address that have visited a particular page to show an interesting in a particular topic (i.e. visited the menswear section of a clothing website).
Thanks @PaulBoocock for the clear explanation.
For Option 3, instead of IP address only, would you please share the experience/idea on which parameters can be used for user grouping? (since user fingerprint has been deprecated in recent version.)
Also, for Option 2, what is the difference from using domain_userid directly?
Thanks and welcome for any sharing on how to do multiple domains tracking under snowplow.
Option 2: The difference is that the Collector cookie can persist for up to 2 years, whereas ITP restrictions mean that the JS set cookies have a max lifespan of 7 days.
Option 3: This is extremely dependant on your site and what you believe good cohorts would be. Often parts of the page_url are useful along with their IP (even if the IP is Pseudonymised). Remember, we’re not trying to identify specific users with this option, but to find “groups” of users that are closely related so we can learn about their grouped behaviours - i.e. people who buy x on my site are also likely to buy y, or people who visit the x section of my site, are more likely to subscribe so I should target them with subscription advertisements.