Add user locale info to device context

[lhunath]

Problem Statement

Understanding the user demographics of certain issues can be relevant and useful information.

Solution Brainstorm

Sentry could expose a standard set of tags automatically added to events to describe demographic metrics which are made available by the system directly, such as Calendar, TimeZone and Locale. Other candidates might be: Storefront, UITraitCollection, TermOfAddress, AccessibilityRequest.

eg.

scope.setTag(value: Locale.current.identifier, key: "user.locale")
scope.setTag(value: TimeZone.current.identifier, key: "user.zone")
scope.setTag(value: Calendar.current.identifier.debugDescription, key: "user.calendar")
scope.setTag(value: Calendar.current.standaloneWeekdaySymbols[Calendar.current.firstWeekday - 1], key: "user.week_start")
scope.setTag(value: AccessibilityRequest.current?.technology.rawValue ?? "none", key: "user.accessibility")
scope.setTag(value: TermOfAddress.currentUser.pronouns.map(\.pronoun).joined(separator: ","), key: "user.pronouns")

Are you willing to submit a PR?

No response

[philprime]

Hi @lhunath, thanks for opening this feature request.

Is there a specific reason why these values should be added by default, instead of allowing SDK users to set them on demand?

[lhunath]

Since they are platform-provided, that makes them standardized values available for all.
Standardizing the set of tags that reflect these values will help ensure consistency across the Sentry platform as well as surface these standards for demographic use within Sentry to users who might not have previously considered their value or availability, thereby augmenting the inherent value provided by the Sentry product.
Whatever the rationale is for providing the current UIDevice values in standardized tags can be applied to these as well in order to evaluate their inclusion.

[philipphofmann]

We can add such information out of the box, but we must not add them as tags, because they are expensive to handle on the backend for us. Instead, we should add such info to the device or user context. If we want that to be searchable, we need to follow up on the backend to make these fields searchable.

[lhunath]

Thanks @philipphofmann! Is there some documentation I can consult to evaluate the costs and implications of tags vs. contexts?

Thus far, my evaluation determining tag vs. context has been:

1. Do I want to be able to search for it?
2. Do I want to be able to evaluate value breakdowns?

On these counts, demographic values seem to be a 2x yes, though I can of course appreciate your performance considerations, which no doubt have been part of the equation for the existing set of tags as well.

[philipphofmann]

@lhunath, you, as a user, can safely use tags for this. We don't want to add tags per default via the SDK for everybody. Adding common searchable properties for all users via the context and indexing them so they're searchable is cheaper for us.

[lhunath]

We do miss the breakdown which is a central element in demographics, but I will let the Sentry team assess internally and arrive at what is best 👍, thanks folks.