Calculation of the sampling score based on user_Id field should be disabled by default to ensure in successful correlation across many services on operation_Id field.
With the current implementation, user_Id is not propagated further than the first backend server. That means that first components in the app architecture are sampled based on user_Id while all others are sampled on operation_Id. This leads to inability to provide a distributed trace for the most of the transactions. An attempts to propagate user_Id beyond the cookie in the client-server relationship is a privacy concern as it would expose user behavior (although, not any of the user info) to the application's external dependencies, not only to the next internal service in the chain.
Note: While disabling user_Id sampling fixed cross-component correlation and distributed tracing from the sampling perspective, it actually affects several scenarios we might rely on in UI and it requires a discussion to agree on the right approach with this change.
For instance, switching from the user_Id sampling to operation_Id sampling in all server-side SDKs will lead to the partial info displayed in this UI:
Switching in JavaScript SDK will lead to issues with the use session event tracking unless customer events and page views are exempt of the sampling.
Making this switch between user_Id and operation_Id configurable is considered in #221 . This might allow customers to override the behavior for the purposes of sampling full info about the certain users rather than certain operation for the user. However, this option will require a careful privacy review and notes for the customers.
Calculation of the sampling score based on
user_Idfield should be disabled by default to ensure in successful correlation across many services onoperation_Idfield.With the current implementation,
user_Idis not propagated further than the first backend server. That means that first components in the app architecture are sampled based onuser_Idwhile all others are sampled onoperation_Id. This leads to inability to provide a distributed trace for the most of the transactions. An attempts to propagateuser_Idbeyond the cookie in the client-server relationship is a privacy concern as it would expose user behavior (although, not any of the user info) to the application's external dependencies, not only to the next internal service in the chain.Note: While disabling
user_Idsampling fixed cross-component correlation and distributed tracing from the sampling perspective, it actually affects several scenarios we might rely on in UI and it requires a discussion to agree on the right approach with this change.For instance, switching from the
user_Idsampling tooperation_Idsampling in all server-side SDKs will lead to the partial info displayed in this UI:Switching in JavaScript SDK will lead to issues with the use session event tracking unless customer events and page views are exempt of the sampling.
Making this switch between
user_Idandoperation_Idconfigurable is considered in #221 . This might allow customers to override the behavior for the purposes of sampling full info about the certain users rather than certain operation for the user. However, this option will require a careful privacy review and notes for the customers.