Add enduser.anon_id to general attributes
#443
Conversation
amertak
changed the title
enduser.anon_id to general attributes
|
@amertak Can you explain, please, why would need a new attribute for this instead of just extending the definition/description of |
|
@AlexanderWert enduser.id and enduser.anon_id are complementary. For example you want to model Enduser can be later on identified on the client's platform - can register/login and this Hope this makes sense. |
|
@AlexanderWert this is to represent an anonymous user in the client side apps, web and mobile apps, prior to user logging in. In a session when a user logs in, we will stop sending Please let us know if this explanation is sufficient. |
|
|
||
| <!-- semconv identity --> | ||
| | Attribute | Type | Description | Examples | Requirement Level | | ||
| |---|---|---|---|---| | ||
| | `enduser.id` | string | Username or client_id extracted from the access token or [Authorization](https://tools.ietf.org/html/rfc7235#section-4.2) header in the inbound request from outside the system. | `username` | Recommended | | ||
| | `enduser.anon_id` | string | Randomly generated id of an anonymous user that is persisted throughout the lifetime of the visits. | `V1StGXR8_Z5jdHi6B-myT` | Recommended | |
There was a problem hiding this comment.
I'd like to see it called out (a bit more) that this value can be any (attribute) "valid" value such as a GUID.
Here is a description of this field (which we called a different name as part of our planning), which has the same meaning as what you are introducing. here.
Client RUM description: Anonymous user id - will be the same for a given browser session. It will persist across page navigations in the same browser session
Value: String / GUID
There was a problem hiding this comment.
I wonder if we should also clarify that this is different than a session. The user ID will will persist across page navigations like session ID. However, session can expire while the user ID will not. In other words, user ID will be the same across multiple sessions. Am I understanding this correctly?
There was a problem hiding this comment.
This is true, but I think semantic conventions only what the attribute represents and not any other details.
|
|
||
| <!-- semconv identity --> | ||
| | Attribute | Type | Description | Examples | Requirement Level | | ||
| |---|---|---|---|---| | ||
| | `enduser.id` | string | Username or client_id extracted from the access token or [Authorization](https://tools.ietf.org/html/rfc7235#section-4.2) header in the inbound request from outside the system. | `username` | Recommended | | ||
| | `enduser.anon_id` | string | Randomly generated id of an anonymous user that is persisted throughout the lifetime of the visits. | `V1StGXR8_Z5jdHi6B-myT` | Recommended | |
There was a problem hiding this comment.
persisted throughout the lifetime of the visits
If I understood correctly, it'd be an ID that would only persist for as long as the user interacts with the app, if that's the case, wouldn't this use case be already covered by the session.id attr? - The session id might also help with tracking the whole process of before, during, and after the user login happens, since the same session id will get sent even the user logs in, whereas it seems like enduser.anon_id would not be sent after the user has been authenticated?
There was a problem hiding this comment.
@LikeTheSalad The same browser instance can be used to have multiple sessions at different times but the anonymous user will be the same in all these sessions.
There was a problem hiding this comment.
Got it, it's similar to device.id ?
There was a problem hiding this comment.
yes, it's close to device.id, but not the same. Browsers, including on mobile, in incognito mode will generate a new enduser.anon_id. For mobile apps is there a possibility of ever requiring a different anon_id? If not, then I guess device.id can be used for enduser.anon_id.
There was a problem hiding this comment.
Mildly 🌶 take but I would say people used to web dev would be understanding that incognito and cross-TLD (considering cookie limitations) would lead to multiple IDs from same "physical" device - even if the attribute would be called device.id
So I'd be fine with just using device.id for this use case with asterisks that "runtime sandboxes" could lead to multiple different ID's for physical device
There was a problem hiding this comment.
@t2t2 I am concerned about the intent of this attribute. The reason to put this under enduser namespace is really to represent an anonymous user, although its value can be device's id whenever it's available. And this attribute goes beyond Client side situations - for anonymous sessions, the backend telemetry too can include the anonymous user id too - the clients will have to pass it via baggage or some such mechanism to the backends. In this context, I also want to note that we cannot use session.id for this purpose since the same anonymous user can have multiple sessions.
I still feel it's good to have this attribute enduser.anon_id to represent anonymous users.
@open-telemetry/specs-semconv-approvers I am curious what your thoughts are on this since this goes beyond Client instrumentation concerns.
There was a problem hiding this comment.
@open-telemetry/specs-semconv-approvers can we get some attention on this please? This is an attribute that some of us vendors would like to add to all signals via processors, and so shouldn't be an issue to others. Is there a general guidance on semantic conventions on attributes added by processors, not necessarily by instrumentations? if there is a general agreement from your side on this PR, we can go ahead make the required text changes further. Thank you!
amertak
force-pushed
the
patch-1
branch
2 times, most recently
from
a4a9b66 to
55c411d
Compare
|
|
||
| <!-- semconv identity --> | ||
| | Attribute | Type | Description | Examples | Requirement Level | | ||
| |---|---|---|---|---| | ||
| | `enduser.anon_id` | string | Randomly generated id of an anonymous user that is persisted throughout the lifetime of the visits. | `V1StGXR8_Z5jdHi6B-myT` | Recommended | |
There was a problem hiding this comment.
just wanted to raise the question of anon_id vs anonymous_id, I'm not sure if we have good (any?) guidance on when to use abbreviations in attribute names
There was a problem hiding this comment.
(btw I opened #602 to seek more comments / guidance on the general question of abbreviations)
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Changes
Adding enduser.anon_id to handle case of enduser which is not authorized/authenticated but we want a way to track their visits throughout the lifetime
Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.
Merge requirement checklist