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.
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
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
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.
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
You are free to use the IDFA or IDFV instead, but it doesn’t hurt to have one extra datapoint.
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
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
Ah ok that all makes sense. I definitely think renaming the user_id field in client_session context would be helpful as well. Thanks!