Getting multiple Domain user id & Session ID for same user

1

I have hosted the snowplow javascript tracker on domain recen.abc.com and calling the tracker on my multiple website domain which are www.xyz.com , m.cbd.com , m.abc.com etc .

I am getting unique network user ID accross domain but for each request different domain_sessionid and domain_userid .
It has also been observed that only third party cookie is set for recen.abc.com but cannot set first party cookie which might be causing the issue of different id for each request .
when specifying domain www.xyz.com , m.cbd.com , m.abc.com in configuration the browser is not accepting it and showing error as the javascript is hosted on different domain .

my configuration for cookie :
cookie {
enabled = true
expiration = 365 days# e.g. “365 days”
name = sp
domains = [
“abc.com” # e.g. “domain.com” -> any origin domain ending with this will be matched and domain.com will be returned
“recen.abc.com” # e.g. “secure.anotherdomain.com” -> any origin domain ending with this will be matched and secure.anotherdomain.com will be returned

]
fallbackDomain = "recen.abc.com"
secure = true
httpOnly = false
sameSite = "None"

}

2

@tarunsood, this is expected. The values for domain_sessionid and domain_userid are set in the 1st party cookie by the Javascript (client-side). The network user ID, on the other hand, is set by the collector (3rd party cookie) - your collector settings are relevant to network_userid only.

To be able to stitch the domain_userid across different domains you might need to utilize crossDomainLinker.

1 Like
3

CrossDomain linker will append query string in parameter which i don’t want my end user to see.

Is there any other way to set first party cookie correctly to avoid this issue.

4

@tarunsood, for cross-domain tracking you should rely on network_userid. The domain_userid is always bound to the domain the tracked page is implemented on due to its nature. You have confirmed network_userid is persistent across those domains. Why do you cling to domain_userid?

5

My Requirement is to track session id .

6

@tarunsood, session ID on its own has no meaning (from my point of view). It’s required to determine what events have fired within the same session. This is done during data modeling (analytics) step.

Do you intend to expend sessions between different domains? If so, it is still could be done at data modeling step even with different session IDs on those domains. The user can be identified by network_userid. When navigating between different domains you control you could use referers and thus extend your sessions by stitching them as well.

You might want to consider passing the session ID between your domains by utilizing getDomainUserInfo method which allows you to acquire the current session ID. It could be passed over somehow to the other domains for stitching purposes.

7

I’m new to Snowplow and we too have the issue of tracking the user journey across multiple domains, although only two in the main.
With third party cookies being blocked by some browsers (e.g. Safari and Firefox) network_userid is changing throughout the user journey and so is not a reliable way to identify a unique user.
So, we have the scenario where the domain_sessionid changes per domain (as I would expect given it’s name) plus the network_userid also changes on some browsers (and probably all at some point in the not too distant future).
Should we be looking at cross-domain tracking to gain an id that we can use to stitch a user journey together?
Any guidance gratefully received!

8

Hi @af-geoffdoughty,

You have a few avenues to explore here.

With third party cookies being blocked by some browsers (e.g. Safari and Firefox) network_userid is changing throughout the user journey and so is not a reliable way to identify a unique user.

So to start with, this isn’t necessarily the case. The network_userid is a server-side cookie, but it doesn’t have to be a third-party cookie, as long as you also own the domain you’re tracking on. These restrictions exist in order to block third parties from setting cookies (eg. if you’re sending data to some hosted provider) - because you own your entire data infrastructure (which is the case whether you run open-source or Snowplow Insights), they need not apply with Snowplow. It’s perfectly legitimate to set collector cookies against a first party domain - but it requires a bit of setup.

You need a CNAME for your tracking endpoint which lives on the same domain as the site you’re tracking, and you need to configure the collector as described in this release post.

Of course, if you don’t own the domains you’re tracking on you can’t set a first party cookie - which is exactly the use case that these browser restrictions are aimed at.

So, we have the scenario where the domain_sessionid changes per domain

This is indeed the expected scenario, since it’s a domain cookie. If you have two subdomains of the same root domain, you can configure the tracker to set cookies against the root domain, and you don’t have this problem. If you have two distinct domains, then you are correct - you can use cross-domain linking to pass values across domains, and link the session together in the datamodeling phase.

Additionally, if you have more nuanced requirements, you can use the tracker’s callback methods to retrieve relevant values and pass them around according to however your own logic needs to work.

I hope that’s helpful!

Best,

9

Hi @Colm,

I have configured the collector as you specified here:

You need a CNAME for your tracking endpoint which lives on the same domain as the site you’re tracking, and you need to configure the collector as described in this release post .

It stills identifies the cookies as third-party:
image

image
image1136×236 14.1 KB

I own both domains. What else would I need to configure?

Thank you in advance!