Individual contributor metrics
DX provides settings to manage the visibility of individual contributor (IC) metrics. Use these controls to maintain privacy, limit access by role, and comply with regional regulations.
Configure visibility and de-identification in Access & visibility under Individual metrics visibility. Contact DX support to enable the system metrics anonymity threshold.
Visibility settings
Reports
Control who can view IC-level data in the following reports:
- Contributor metrics report
- Interactions report
- Breakdowns by IC
- Work Log by IC
- AI adoption by IC
- AI cost management by IC
- AI code percentage by IC
- Agent sessions
To configure, open the Reports dropdown and select an option.
| Option | Behavior |
|---|---|
| Everyone | All users can view IC metrics in reports |
| Everyone but limit visibility to user’s teams | Non-admin users can only view ICs within teams they belong to. |
| Admins and privileged users | Only administrators (snapshot admins, workspace admins, datacloud admins) and users with the privileged role can view IC metrics |
| Admins, privileged users, and team leads | Same as above, plus team leads can view IC metrics |
| Admins, privileged users, and team leads but limit visibility to lead’s teams | Same as above, however team leads can only view ICs within teams they belong to. |
| Nobody | No users can view IC metrics. Once selected, this setting requires DX support to re-enable. |
Group Dashboard
Control who can view IC breakdowns in the Group dashboard.
To configure, open the Dashboard dropdown and select an option.
| Option | Behavior |
|---|---|
| Everyone | All users can view IC breakdowns |
| Everyone but limit visibility to user’s groups | Non-admin users can only view IC breakdowns for groups they belong to |
| Admins and privileged users | Only administrators and users with the privileged role can view IC breakdowns |
| Admins, privileged users, and team leads | Same as above, plus team managers can view IC breakdowns |
| Admins, privileged users, and team leads but limit visibility to lead’s groups | Same as above, however team leads can only view IC breakdowns for groups they belong to |
| Nobody | No users can view IC breakdowns. Once selected, this setting requires DX support to re-enable. |
Note: Reports scoped to a single group with more than 500 members do not support per-user breakdowns.
DX AI chat
Control who can view IC-level data in chat sessions with DX AI. This setting applies to both DX AI chat and the Data Studio AI assistant.
To configure, open the DX AI chat dropdown and select an option.
| Option | Behavior |
|---|---|
| Everyone | All users can view IC-level data in AI chat sessions |
| Admins and privileged users | Only administrators (snapshot admins, workspace admins, datacloud admins) and users with the privileged role can view IC-level data |
| Admins, privileged users, and team leads | Same as above, plus team leads can view IC-level data |
| Nobody | No users can view IC-level data in AI chat sessions. Once selected, this setting requires DX support to re-enable. |
AI Code Insights transcripts
Control who can view full session transcripts, titles, summaries, and agent comments in AI reports.
This setting is only visible when server-side transcript retention and evaluation are enabled under Transcripts & Agent Experience for AI Code Insights. Supported integrations can still send scrubbed session messages to the ingestion endpoint when that setting is off; see Transcript handling.
To configure, open the AI Code Insights transcripts dropdown and select an option.
| Option | Behavior |
|---|---|
| Everyone | All users can view session transcripts |
| Everyone but limit visibility to user’s teams | Non-admin users can only view session transcripts within teams they belong to. |
| Everyone but limit visibility to user’s own sessions | All users can view transcripts but only for their own sessions. |
| Admins and privileged users | Only administrators (snapshot admins, workspace admins, datacloud admins) and users with the privileged role can view session transcripts |
| Admins, privileged users, and team leads | Same as above, plus team leads can view session transcripts |
| Admins, privileged users, and team leads but limit visibility to lead’s teams | Admins and privileged users can view all transcripts; team leads can only view transcripts for their teams. |
| Nobody | No users can view transcripts. Once selected, this setting requires DX support to re-enable. |
Pulse alerts
Control whether team leads can receive Pulse alerts about ICs on their team that may need support.
To configure, open the Pulse alerts dropdown and select an option.
| Option | Behavior |
|---|---|
| Allowed | Team leads can enable IC-based Pulse alerts |
| Not allowed | Team leads cannot enable IC-based Pulse alerts |
System metrics anonymity threshold
The system metrics anonymity threshold hides aggregate metrics when too few individuals are represented in a report or breakdown. Use it to limit visibility into small groups, including when a combination of team, group, and attribute filters narrows a report to an individual.
Note: This feature is in early access. Contact DX support to request access or a different threshold for your account.
How the threshold works
The default threshold is 3 individuals. When enabled, DX hides system metrics below this threshold in built-in reports and their Dashboard views:
- Entire report: When the report is below the threshold, DX hides its metrics and displays Not enough data with an explanation of the privacy threshold.
- Breakdown rows: When a row is below the threshold, DX replaces its metric values with a crossed-out eye icon. Hover over the icon to see why the data is hidden.
The threshold applies to the individuals represented after filtering. A team’s total membership does not by itself determine whether a filtered report meets the threshold. The count used for the check depends on the report; for example, PR throughput counts distinct PR authors represented in the selected data.
For example, your team has 10 members, but only one has the Back end developer attribute. With the default threshold of 3, filtering a report to that team and attribute hides the metrics. Breaking the team down by that attribute also hides metric values for the row containing one person.
Individual metrics visibility
Enabling this feature also disables access to IC-level metrics through the Reports, Dashboard, and DX AI chat visibility settings, and disables IC-based Pulse alerts. These restrictions apply to administrators and privileged users as well as other roles.
How this works with other privacy controls
The system metrics threshold is separate from these controls:
- Snapshot anonymity threshold: Snapshot results use a separate response threshold. Changing the system metrics threshold does not change the snapshot threshold.
- De-identifying protected users: De-identification hides identifying information for users marked as protected. The system metrics threshold hides metric values for small groups, whether or not their members are marked as protected. To hide identifying information in visible drilldowns, configure de-identification.
- Data Studio access: The threshold applies to built-in reporting. It does not apply automatically to custom SQL queries or custom reports in Data Studio, including custom reports pinned to a Dashboard. Manage access using the controls in Data Studio considerations.
The threshold does not hide team membership or attribute assignments on organization and team pages. For details on managing these assignments, see custom user attributes.
De-identifying users
For organizations that need to de-identify individual metrics based on region or policy requirements (such as a Works Council agreement), DX supports selective user de-identification.
Setup
Step 1: Enable protected metrics
- In Access & visibility, scroll to Individual metrics visibility
- Set De-identify protected users to “Enabled”
Step 2: Mark users for de-identification
Set the protected user property to true for each user that needs to be de-identified.
Step 3 (optional): Enable Data Studio warning
For an additional safeguard, enable the Data Studio workers council warning setting. When enabled, DX displays a compliance reminder dialog the first time a user accesses Data Studio in a session. The warning advises users to ensure their analysis complies with local labor laws and data protection regulations, and to consult their HR or legal team if unsure.
How de-identification works
When De-identify protected users is enabled, DX replaces all identifying information for protected users with the label “Hidden” across reports, dashboards, and exports. The following fields are redacted:
- Name
- Email address
- Username / login
- Avatar image
- External profile URLs (e.g., links to source control profiles)
This redaction is applied at the application layer. When DX builds queries and generates report output, it checks the protected flag on each user record and substitutes identifying fields before results are delivered to the UI.

De-identification replaces identifying fields in report output — the underlying data (commits, pull requests, survey responses, etc.) is still processed for aggregate metrics. This means team-level and organization-level metrics remain accurate even when individual users are de-identified.
Drilldown views
When de-identification is enabled, DX also prevents protected users from being found via text search in report drilldowns. Searching for a protected user’s name or email in any report drilldown will return no results for that user.
Reports and dashboards
De-identification applies to all IC-level views, including:
- Contributor metrics
- Interactions report
- Breakdowns by IC
- Work Log by IC
- AI adoption by IC
- AI cost management by IC
- Group dashboard IC breakdowns
- SLA breakdowns
In each case, the protected user’s row still appears in results (so aggregate counts remain correct), but identifying fields display as “Hidden”
DX AI
DX AI features that surface data within standard reports (such as AI-generated summaries or analysis) respect the same de-identification controls. Protected user names and emails are not exposed in AI-generated output within DX reports.
Data Studio considerations
Data Studio allows users with access to write and run custom SQL queries. Because these queries run directly against the underlying data, the application-layer redaction described above does not apply to Data Studio query results. Users with Data Studio access may be able to query tables that contain identifying information for all users, including protected users.
To manage this, DX provides the following controls:
| Control | Description |
|---|---|
| Data Studio visibility | Restricts who can access Data Studio. Configure under Access & visibility. |
| Data Studio workers council warning | Displays a compliance reminder when users first access Data Studio in a session, advising them to ensure their queries comply with local regulations. |
| Role-based access | Only users with appropriate roles can access Data Studio. |
If your organization requires that protected users cannot be identified under any circumstances, restrict Data Studio access to a trusted set of administrators using the Data Studio visibility setting.