I’m trying to understand the client_session context. It appears it is only being sent with our mobile trackers and not our javascript tracker. Is that expected behavior? Also, the user_id field of the client_session context doesn’t appear to map to IDFAs or any other IDs in other tables such as atomic.events. What is this user_id field within the client_session context typically used for in data analysis?
Hi @travisdevitt,
You are correct that the client session context is specific to the iOS and Android trackers, for now. This is the approach we’ll take if we were to add client-side sessionization to other trackers.
The Javascript tracker has supported client-side sessionization for much longer, which is why it doesn’t use the client session context yet. Instead, it sets the domain_userid, domain_sessionidx, and domain_sessionid fields in atomic.events. We plan to migrate these fields to the client session context. You can find several tickets related to this migration on our GitHub page: https://github.com/snowplow/snowplow/issues/1894
The user_id field in the client session context is a UUID that is generated by the tracker and stored on the device. It should persist until the app is uninstalled, and is very similar to the domain_userid that is generated by the Javascript tracker.
I should map very closely onto the IDFV, so I’m not sure I fully understand that part of the question.
I hope this answers your questions - but let me know if not.
Christophe
For the user_id from client_session I was speaking to the fact that it’s not the same value as IDFA/IDFV (not sure why a second device ID called user_id would be needed?). I did check and see that most IDFAs map one-to-one with a user_id but there are a few cases where IDFAs map to multiple user_id.
You are free to use the IDFA or IDFV instead, but it doesn’t hurt to have one extra datapoint.
It’s an ID which was generated using code we control (which would prevent issues in the unlikely scenario that either Apple or Google were to change their policies). The ID is generated in a way that’s consistent with how we do it in all trackers, and, once we update the Javascript tracker to also use the client session context, we will have one field across all trackers that generates a random user ID in the exact same way.
The user_id gets reset if a user reinstalls an app, which is probably why you are seeing a couple of cases where a single IDFA maps onto more than one user_id.
One extra thing to point out is that we’re considering renaming this particular user_id field to something else: https://github.com/snowplow/snowplow/issues/2696 (because it sometimes creates confusion with the user_id field in atomic.events).
Ah ok that all makes sense. I definitely think renaming the user_id field in client_session context would be helpful as well. Thanks!
1 Like
We rely heavily on the user_id fields, as we set that value for each know visitor. Our data is primarily collected using the javascript collectors so as you migrate to the the user session context will be able to keep our existing user_id(s).