Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add enduser.anon_id to general attributes #443

Closed
wants to merge 2 commits into from
+8 −2
Closed

Add enduser.anon_id to general attributes #443

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
eef5d0d
feat: add enduser.anon_id
amertak Oct 25, 2023
7bc3081
chore: semantic fix
amertak Nov 8, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/general/attributes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -306,11 +306,12 @@ Examples of `peer.service` that users may specify:

## General identity attributes

These attributes may be used for any operation with an authenticated and/or authorized enduser.
These attributes may be used for any operation with an authenticated or anonymous enduser.

<!-- 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 |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is true, but I think semantic conventions only what the attribute represents and not any other details.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, it's similar to device.id ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(btw I opened #602 to seek more comments / guidance on the general question of abbreviations)

| `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.role` | string | Actual/assumed role the client is making the request under extracted from token or application security context. | `admin` | Recommended |
| `enduser.scope` | string | Scopes or granted authorities the client currently possesses extracted from token or application security context. The value would come from the scope associated with an [OAuth 2.0 Access Token](https://tools.ietf.org/html/rfc6749#section-3.3) or an attribute value in a [SAML 2.0 Assertion](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html). | `read:message, write:files` | Recommended |
Expand Down
7 changes: 6 additions & 1 deletion model/general.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ groups:
prefix: enduser
type: span
brief: >
These attributes may be used for any operation with an authenticated and/or authorized enduser.
These attributes may be used for any operation with an authenticated or anonymous enduser.
attributes:
- id: id
type: string
Expand All @@ -52,6 +52,11 @@ groups:
[Authorization](https://tools.ietf.org/html/rfc7235#section-4.2)
header in the inbound request from outside the system.
examples: 'username'
- id: anon_id
type: string
brief: >
Randomly generated id of an anonymous user that is persisted throughout the lifetime of the visits.
examples: 'V1StGXR8_Z5jdHi6B-myT'
- id: role
type: string
brief: 'Actual/assumed role the client is making the request under extracted from token or application security context.'
Expand Down