Is there a way to modify the domainUserId in the browser JavaScript tracker?
Specifically, I need to modify the parameter sent in the URL when using the crossDomainLinker function.
The crossDomainLinker attaches the snowplow Domain User ID to the URL of the new address, but I would like to send a custom ID instead. Is there some other option to do this?
Thanks
Hi @munichdev,
No, there isn’t a way to do this, and I don’t think I’d recommend using crossDomainLinker to achieve what you describe - it is generally a good idea to leave the tracker’s cookie values untouched, and to treat custom values separately.
I think the best way to achieve what you’re describing is to append your value to the url yourself, then use setUserIdFromLocation to set the value as the user_id.
Alternatively you could grab the value from the querystring and attach it to a custom entity.
Hope this helps. 
Okay thank you, I can do this.
Is there a reason that there isn’t a method to set the Domain User ID in the browser tracker, as there is in other tracker implementations (setDomainUserId()). It would be useful in our case to use our own custom ID instead of the Snowplow Domain User ID. Just curious.
Thanks!
Yeah so it’s an argument based in data design - the general philosophy of Snowplow is that you should define your data structures up front and strictly stick to those definitions. (Of course flexibility is often required, but where possible it’s best to rigidly adhere to data definitions).
Domain User ID is defined as a web (domain based) cookie value - like the session ID, the javascript tracker creates and manages all logic associated with it. All of the downstream logic in all of our products that interact with this value expect it to be so.
Some of the server side trackers allow you to set this value, because servers don’t have access to cookies, and this feature facilitates a server-side tracking of web events. For example, if you want your web transaction events to come from a server-side source of truth, you can pass the cookie value to the server, and set the domain userid.
The user ID field is defined as a custom ID field, and so that’s what we’d normally suggest to use if what you need is a custom ID.
There are of course practical considerations - for example if you overwrite domain usuerid, then you’ve removed the most convenient and reliable way to identify logged out users, but the above is the philosophical argument at least.
Is there some reason that using a custom ID specifically in the domain user column, and using the user ID column won’t work for your use case? Or, alternatively, using a custom event?
Edit: The above is the theoretical argument, in my opinion. In reality, it’s been requested before and I don’t know what the product-based reasoning would be - is just one engineer’s opinion. If I were to guess though I’d imagine that reasoning is along the lines of “we don’t want to make it easy for our users to create problems with other tooling downstream (eg the web data model)”.
Thank you for the thorough response! I’m new to Snowplow so this information is useful.
To answer your questions, we are already using a custom event. And I just want to use the crossDomainLinker function in Snowplow to track across domains. Since we already have a version of the Domain User ID, I would like to send that ID in the URL as a parameter using the crossDomainLinker, since it’s easy to implement in Snowplow. But I think there is another way that will work in our case.
But I understand the argument with sticking to data structures. I think it’s just not ideal for our particular use case since we aren’t utilizing the tooling downstream, and since we already had some existing infrastructure before adding Snowplow.