Dev Section Performance Indicators

1. You are here:
2. Handbook
3. Product Handbook
4. Dev Section Performance Indicators

On this page

• Section PI Overview
• Regular Performance Indicators
  • Dev - Section CMAU - Estimated & Recorded Sum of Dev Section SMAU
  • Manage, Manage:Optimize - SMAU, GMAU - MAU Viewing Optimize Features
  • Manage, Manage:Optimize - Error Budget for GitLab.com
  • Manage:Access - Paid GMAU - MAU Using Paid SAML
  • Manage:Access - Error Budget for GitLab.com
  • Manage:Compliance - Paid GMAU - MAU Viewing Compliance Features
  • Manage:Compliance - Other - Projects Marked with a Compliance Framework
  • Manage:Compliance - Error Budget for GitLab.com
  • Manage:Import - GMAU - MAU importing
  • Manage:Import - Other - Share of New Projects Imported
  • Manage:Import - Error Budget for GitLab.com
  • Plan, Plan:Project Management - SMAU, Paid GMAU - MAU Interacting With Issues
  • Plan, Plan:Project Management - Error Budget for GitLab.com
  • Plan:Product Planning - Paid GMAU - MAU creating Epics each Month
  • Plan:Product Planning - Error Budget for GitLab.com
  • Plan:Certify - Paid GMAU - MAU Interacting with Requirements
  • Plan:Certify - Other - Number of Requirements Created Monthly
  • Plan:Certify - Error Budget for GitLab.com
  • Create - SMAU - Unique users writing to a Git repository
  • Create - Error Budgets
  • Create:Source Code - GMAU - Unique users writing to a project Git repository
  • Create:Source Code Secondary - Other - GitLab.com performance scores
  • Create:Source Code - Error Budget for GitLab.com
  • Create:Code Review - Category MAU - Unique users using Merge Requests
  • Create:Code Review - Other - Code Review/SCM Ratio by UMAU and Subscription Tier
  • Create:Code Review - Editor Extension (VS Code) - Category MAU
  • Create:Code Review - Error Budget for GitLab.com
  • Create:Gitaly - Other - Availability
  • Create:Gitaly - Other - Unique instances with Gitaly Cluster enabled
  • Create:Gitaly - Error Budget for GitLab.com
  • Create:Editor - GMAU - Unique users committing via any web editor
  • Create:Editor - AMAU - Unique users committing by web editor
  • Create:Editor - Other - Number of Commits per Month from the Web IDE
  • Create:Editor - Other - Number of new Snippets per Month
  • Create:Editor - AMAU - Unique users committing via the Static Site Editor
  • Create:Editor - AMAU - Uniques users of Wiki
  • Create:Editor - Error Budget for GitLab.com
  • Create:Ecosystem - GMAU - MAU of any integration
  • Create:Ecosystem - Other - Total active project integrations
  • Create:Ecosystem - Other - Integrations managed at Group or Instance level
  • Create:Ecosystem - Error Budget for GitLab.com
• Other PI Pages
• Legends
  • Health
• How to work with pages like this
  • Pages
    • Helper Functions
  • Data
  • Guidelines

Note: This page is dynamically generated via the Dev Section performance indicators .yml file.

Section PI Overview

Stage/Group	PI Type	PI	Health	SaaS / SM	Implementation Status
Dev	Section CMAU	Estimated & Recorded Sum of Dev Section SMAU	Okay	Both	Complete
Manage, Manage:Optimize	SMAU, GMAU	MAU Viewing Optimize Features	Okay	Both	Complete
Manage:Access	Paid GMAU	MAU Using Paid SAML	Okay	SaaS	Complete
Manage:Compliance	Paid GMAU	MAU Viewing Compliance Features	Attention	Both	Complete
Manage:Import	GMAU	MAU importing	Okay	Both	Complete
Plan, Plan:Project Management	SMAU, Paid GMAU	MAU Interacting With Issues	Okay	Both	Complete
Plan:Product Planning	Paid GMAU	MAU creating Epics each Month	Okay	Both	Complete
Create	SMAU	Unique users writing to a Git repository	Okay	Both	Complete
Create	Error Budgets		Problem	Both
Create:Source Code	GMAU	Unique users writing to a project Git repository	Okay	Both	Complete
Create:Code Review	Category MAU	Unique users using Merge Requests	Okay	Both	Complete
Create:Gitaly	Other	Availability	Unknown	Both	Instrumentation
Create:Editor	GMAU	Unique users committing via any web editor	Attention	Both	Complete
Create:Ecosystem	GMAU	MAU of any integration	Unknown	Both	Instrumentation

Regular Performance Indicators

Dev - Section CMAU - Estimated & Recorded Sum of Dev Section SMAU

A sum of all SMAUs across the three stages in the Dev Section (Manage, Plan, and Create) for All users and Paid users.

SaaS/SM: Both

Target: FY22Q2 -- Section CMAU growth 8% QoQ with a goal of 3.57M for Estimated CMAU & a goal of 856K for Estimated Paid CMAU

Is Primary PI: true

Health: Okay

• CMAU is fully instrumented
• Dev Section recorded its highest Estimated CMAU at 3.31M!
• Dev Section recorded its highest Estimated Paid CMAU at 793K!
• Overall CMAU growth lower than current average with investigation ongoing

Metric Name: issues, action_monthly_active_users_project_repo, analytics_unique_visits_for_any_target

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Implementation Status: Complete

Focus This Month (August):

• Work with Data team to better calculate "Estimated Self-Managed Uplift" to help balance out calculations

Manage, Manage:Optimize - SMAU, GMAU - MAU Viewing Optimize Features

The number of unique users viewing any Optimize page.

SaaS/SM: Both

Target: 116050

Is Primary PI: true

Health: Okay

• Insights - DevOps Adoption was made available to SaaS users in 13.11. Previously it was only available at the Instance level for self-managed users. We received the first set of usage data in May, showing that 55 SaaS users tried DevOps Adoption within the first month of it being released. This feature is restricted to Ultimate users.
• In 13.11 we announced a series of improvements to group-level Value Stream Analytics and saw a 14% increase in adoption in May with the biggest increase being in the Ultimate tier.
• Improvements - Over the next 2 releases, we will be adding security scanning features to the DevOps Adoption report, making the report more useful for Ultimate customers.
• SaaS data is not available for the paid SMAU chart due to limitations of the redis counter that is used.

Metric Name: analytics_total_unique_counts_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Implementation Status: Complete

Manage, Manage:Optimize - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Manage:Access - Paid GMAU - MAU Using Paid SAML

The number of unique users logging into GitLab using SAML SSO for Groups.

SaaS/SM: SaaS

Target: Q3FY22 goal 8700

Is Primary PI: true

Health: Okay

• Insights - An increase of ~10% in MAU from last month. A huge increase in self-manage SMAU of 87% from the previous month!
• Insights - This month also showed a record high of new group memebers on a SMAL group - over 9k new group members (33% increase from last month)!

Metric Name: user_auth_by_provider (Group_SAML)

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Implementation Status: Complete

Manage:Access - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana
• Improvements - The team has rolled out the fix for linear queries on June 30th, so we wxpwct to see an iimprovement in next month's data.
• Improvement - The team has worked on rapid action for AuthorizedProjectsWorker, Comparing the improvement” … “a 99.38% decrease in the number of jobs being generated. This has not been enabled yet, so it is not visible in the June data.

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Manage:Compliance - Paid GMAU - MAU Viewing Compliance Features

The number of unique users viewing Audit Events, Compliance Dashboard, or Credential Inventory.

SaaS/SM: Both

Target: 10% quarter-over-quarter

Is Primary PI: true

Health: Attention

• We are biasing for action and setting a target with the information we have, rather than waiting. We expect this may need to be adjusted in the future. We can use our predictive models to set initial targets in the future.

Metric Name: i_compliance_audit_events_monthly, g_compliance_audit_events_monthly, g_compliance_dashboard_monthly, i_compliance_credential_inventory_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Implementation Status: Complete

• Completed

Lessons Learned (July):

• We saw a 2% decrease in our users this month looking at our "total compliance actions" metric, which combines group and instance-level audit events, compliance dashboard, and credential inventory usage. Looking at individual metrics, this was primarily caused by a fewer users viewing the audit events screen. Instance-level statistics were flat with no change. That said, the number of audit event users is still markedly (86%) than where it was two quarters ago in December, primarily driven by us opening the screen to more users.
• We continue to hear about the needs of compliance-concious users and needing to be able to apply fine-grained controls, as opposed to blanket "everyone gets enforcement" checkboxes. This further underscores the need of bringing group-level controls for our GitLab.com and self-managed customers. It also underscores the importance of focusing on subgroups, beyond just root groups, since the root group on GitLab.com is essentially equivalent to an instance-level setting for those users.
• There is a distinction between acting on "what is in production" and "what were all changes between release X and Y" for users in different compliance environments. Internal stakeholders will care about the former while external stakeholders, such as auditors and regulatory bodies, care about the latter. This give us good insight into the types of experiences we need to build for users.

Focus This Month (August):

• Add additional audit events (1, 2, 3)
• Group-level MR settings
• Continue refinement and validation on webhook-based audit events
• We will investigate using the predictive and regreession capabilities in Sisense to build projected usage models that will be live updated with data as it comes in. This will help us understand if we are having a "slow" or "fast" month in terms of growth compared to what we would expect.
• Assuming we can get predictive models set up in Sisense, we will begin to use those projections to help us inform our planning for the future in terms of maintaining a scalable infrastructure and deciding on the urgency of needing to make archtiectural changes. This will also help inform us on how urgent the need for webhook-based audit events is, which will offload some processing from GitLab, will become in the future.
• We will consider if this metric should be updated to include more parts of the product that Compliance group is focused on, such as MR settings or exteral status checks. This will allow us to better understand which parts of our product users are using, in addition to the areas we already are tracking.
• We will focus on backfilling open engineering roles to allow us to increase our team velocity.

Manage:Compliance - Other - Projects Marked with a Compliance Framework

New and cumulative number of projects using compliance frameworks.

SaaS/SM: Both

Target: 10% quarter-over-quarter growth in new projects using compliance frameworks (SaaS and self-managed combined)

Health: Attention

• In process

Metric Name: projects_with_compliance_framework

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Implementation Status: Complete

Lessons Learned (July):

• We saw a growth of 2.5% this month.
• We continue to get positive feedback about compliance frameworks. When discussing with users, the use case generally resonates around compliance teams only having to define their pipeline jobs once and that no effort is needed by developers to use them.
• We have learned more about how our users plan to use and have tried using compliance frameworks in practice. As part of that, we have found a few opportunities for enchancements, issues to resolve, as well as a few use cases that we need to focus on in the short term.

Focus This Month (August):

• We are rolling out a new metric in 14.1 to provide visibility into compliance pipeline usage. This will help us differentiate our compliance framework users, since frameworks themselves are available in Premium & Ultimate, while pipelines are Ultimate-only. My hypothesis is we will be able to correlate growth in compliance frameworks with growth in compliance pipelines, as I predict most new usage of them will be because of the compliance pipelines. Very excited to review the data as it arrives!
• More qualitative conversations with users to find out what they like about compliance frameworks and pipelines as well as what they still need to help guide future directions.
• We will continue looking at the predictive model for our data to see what conclusions we can make about future growth and what we can change to increase that growth rate.
• We are adding a new audit event so users can see changes that are made to projects and when compliance frameworks are added or removed. This will give them the visibility they need to confidently use compliance frameworks as part of defining and enforcing organizational compliance.

Manage:Compliance - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana
• We believe these results are because the audit events page takes a long time to load, rather than actual 500 errors.
• We are investigating how we might make this page load faster. One idea is to introduce pagination

Manage:Import - GMAU - MAU importing

A monthly count of the unique number of users performing an import

SaaS/SM: Both

Target: 88,000 MAU importing projects

Is Primary PI: true

Health: Okay

• Target - Initial target set to 88,000 by the end of the year, which is a 10% increase from the initial user engagement levels in March and April.
• Improvement - Reducing friction for GitLab-to-GitLab migrations - The feature parity with the existing Group Export/Import, which is the first milestone on this path is targeted for 14.2.
• Note - SaaS data is not available for the paid GMAU chart due to limitations of the redis counter used.

Metric Name: usage_activity_by_stage_monthly.manage.unique_users_all_imports

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Implementation Status: Complete

• Instrumentation has been implemented in 13.9.
• The charts are completed and data is available starting with February 2021.

Manage:Import - Other - Share of New Projects Imported

Share of projects created via import within 90 days of the namespace's creation.

SaaS/SM: Both

Target: TBD - See Health section below for details

Health: Unknown

• No target defined yet.
• Target will be defined once the dashboard shows both Saas and self-managed.

Metric Name: N/A

Chart (Sisense↗)

Implementation Status: Instrumentation

• Instrumented for Saas.
• Dashboard shows only Saas at this time.
• Instrumentation for self-managed implemented in 14.0.
• Dashboard will be updated with self-managed data after July 2021, once data is available.

Manage:Import - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• The Project Export/Import API creates the largest negative impact on Import's error budget. We are addressing this issue in the long-term by replacing this feature with a more efficient GitLab-to-GitLab Migration solution.
• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Plan, Plan:Project Management - SMAU, Paid GMAU - MAU Interacting With Issues

Number of unique users interacting with an issue (open, close, reopen, adjust label, adjust milestone, adjust weight, comment)

SaaS/SM: Both

Target: 557,290 for All, 157,571 for Paid

Is Primary PI: true

Health: Okay

• Given the variables of missing SaaS data, customers purging their usage ping data, and the majority of self-managed customers not sending us usage ping data at all, it is not possible to draw any meaningul health-related conclusions from our data at this point in time.
• Driver - For Paid, continue progress on achieving feature parity between an Instance, Group, and Project, making issues more extensible, and continuing to make incremental progress on iterations.
• Improvement - For All, work towards addressing the problem areas that emerged out of the Category Maturity Scorecard exercise for Issue Tracking.
• Improvement - For All, continue making progress on quality of life improvements for existing features.

Metric Name: redis_hll_counters.issues_edit.issues_edit_total_unique_counts_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

URL(s)

• https://about.gitlab.com/direction/plan/issue_tracking/
• https://app.periscopedata.com/app/gitlab/775807/Plan-xMAU-(monthly)

Implementation Status: Complete

Lessons Learned (July):

• As of the time this update was written, 25% of SaaS usage ping data is missing from the last 8 weeks. > 60% of our paying self-managed customers do not have usage ping enabled. This makes an accurate analysis of overall trends impossible. Keep this in mind as you read on.
• Only 47% of instances are currently on a version with the new Project Management xMAU redis counters.
• May saw 1.9 net new Paid GMAU for every 1 churned Paid GMAU, which is a 19% improvement over May. (Self-Managed Only)
• From a macro perspective, it is worth highlighting that the total count of self-managed customers with usage ping enabled has remained relatively flat over the previous four reporting periods. This is strongly correlated with Dev Paid CMAU and Plan Paid MAU.
• After relatively strong MoM growth this year, extrapolated revenue per Paid MAU decreased by 7% from May to June (see cell V189 - internal only). This is by no means scientific, but it can be traced back to a strong decline in Self-Managed Ultimate Paid GMAU, which experienced a 19% decrease from May to June. It is unclear if this trend is local to Plan or could be related to larger Ultimate customers disabiling Using Ping and purging all historical data.
• Recorded xMAU has remained flat the past three reporting periods. The decline in All seems to be attributed to a drop in Estimated xMAU. It seems as though there may be room to improve how we estimate xMAU. For example, Estimated GMAU dropped by 3% from May to June while Recorded Self-Managed GMAU increased by only .5%, all while the overall percent of customers with usage ping enabled only increased by .6%.
• Total blended Plan MAU growth by tier from January to June - Core (18.3%), Trial (49.6%), EE Free (51.9%), Starter (-14.9%), Premium (72.2%), Ultimate (19.9%)

Focus This Month (August):

• Merge architectural blueprint for consolidating Epics, Requirements, and Issues into a single, parentable "work item" object.
• Finalize and validate the mobile-first MVC for the new issue UI/UX to set the foundation for long term improvements in SuS, reducing technical debt, improving performance, and making issues update in real-time. We will begin shipping iterations on the new issue view behind a feature flag starting in 14.2.
• Merge architectural blueprint for consolidating Groups and Projects. Complete a PoC for enabling Issues at the Group level with the proposed implementation path.
• Support the ongoing research Pricing and Packaging is conducting around the non-developer use cases.
• Collaborate closely with a large customer to build out a robust PoC to model their full SDLC within GitLab. The long term goal is enabling them to migrate away from Jira Align and Jira, which will drmatically improve the quality of life for the engineers. We will leverage the learnings to inform our product roadmap and create "blueprints" for enabling other larger organizations to migrate their planning needs to GitLab.

Plan, Plan:Project Management - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• An initial assessment into hotspots as been completed. Plan is crafting an OKR for FY22Q3 to improve Error Budgets.
• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Plan:Product Planning - Paid GMAU - MAU creating Epics each Month

The number of unique users creating Epics each month.

SaaS/SM: Both

Target: 10,301 Combined Unique Users for Self Managed and SaaS

Is Primary PI: true

Health: Okay

• May 2021 - 7126 GMAU has a slight decline of 7.57% since April.
• Insight - All of our epic event actions saw increases, so not sure why there was a slight drop. We'll see if this continues in June.
• Only 17% of instances are currently on a version with the new Product Management xMAU metric counters (15% increase in May).
• Improvement - Epic Boards full feature will ship in 14.0!
• Our next target will be set after 14.0 and epic boards release and verifying our new graphs for GMAU.

Metric Name: epics

Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Implementation Status: Complete

• New Sisense graph WIP GMAU - Users interacting with Epics
• We've added trackers for epic board creation ahead of the release in 14.0 - Epic board tracking issue

Plan:Product Planning - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• In 14.2 we continue to investigate memory issues associated with the discussions endpoint. This is a primary consumer of our error budget, sometimes taking upwards of 2s to complete.
• In 14.2 we will scheduled the list of 500 errors and any other we find and we validated the accuracy of our Grafana Board.
• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Plan:Certify - Paid GMAU - MAU Interacting with Requirements

The number of unique users interacting (create, view, reference) each month

SaaS/SM: Both

Target: 2000 interactions by December 2021

Health: Attention

• Note - Due to lack of data for June, limited insights can be provided.
• Improvement - Requirements in the process of being converted to issue type, which will have the added benefit of improved tracking using redis counters.
• Insight - 90 Day rolling average page views for requirements maintaining 57k level, showing consistent interest.

Metric Name: requirements_interactions

Chart (Sisense↗)

Implementation Status: Dashboard

• Dashboarding - Requirement Creation instrumented is complete. Tracking issue for gmau dashboard here

Plan:Certify - Other - Number of Requirements Created Monthly

A monthly count of the number of requirements created.

SaaS/SM: Both

Target: 1000 by end of September 2021

Health: Okay

• Note - Due to lack of data for June, limited insights can be provided.
• Improvement - Link Test Cases to Requirements planned for 14.2
• Insight - Self-managed instances creating requirements continues to grow.

Metric Name: requirements_created

Chart (Sisense↗)

URL(s)

• https://gitlab.com/gitlab-data/analytics/-/issues/5270

Implementation Status: Dashboard

• Dashboarding - accurate instrumentation on Self Managed, still needs verification for SaaS - issue

Plan:Certify - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Okay

• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Create - SMAU - Unique users writing to a Git repository

A rolling count of the number of unique users who performed any Git write operation within the last 28 days.

SaaS/SM: Both

Target: Our target growth rate is 3% higher than the previous month for SMAU, and 4% for Paid SMAU.

Is Primary PI: true

Health: Okay

• Insight - SMAU growth for SaaS appears to have stalled over the last 3 months while Self-managed numbers continue to steadily rise.
• Insight - On the median GitLab instance (self-managed), 33% of users perform a Git write operation each month (source). On the median Paid GitLab instance (self-managed), 50% of users perform a Git write operation each month (source).
• Improvement - Overall the Create stage is focused on maintaining growth via support for large MRs, implementing the Content Editor in Wikis, incremental back-ups for repositories, and preparing gitlab-ssh to replace Open SSH.
• Improvement - 3 of the 4 Groups in Create are focused on initiatives aimed at scaling GitLab for large customers. We expect it to contribute to retention of enterprise customers and we expect some growth in the medium term as we meet the performance expectations of some large prospects. We do not expect immediate growth from this work.

Metric Name: action_monthly_active_users_project_repo

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

URL(s)

• https://app.periscopedata.com/app/gitlab/728380/WIP-Create-Stage-Dashboard

Implementation Status: Complete

• Create SMAU metrics are being deduplicated.

Create - Error Budgets

Summed availablity across all groups in Create stage

SaaS/SM: Both

Target: 99.99%

Is Primary PI: true

Health: Problem

• Insight - Error budgets for all groups except Gitaly are under target
• Improvement - FY22Q3 OKR to improve error budgets in each group by 0.05%

Chart (Sisense↗)

Create:Source Code - GMAU - Unique users writing to a project Git repository

A rolling count of the number of unique users who performed any Git write operation within the last 28 days.
Why: We want to ensure all the features in our group provide a great experience that ultimately will allow everyone to contribute more often. A great experience in SCM is a critical starting point for this.

SaaS/SM: Both

Target: Our target growth rate is 3% higher than the previous month for SMAU, and 4% for Paid SMAU.
- Q1FY22 targets - 2.44M GMAU, 590k paid GMAU
- Q2FY22 targets - 2.67M GMAU, 644k paid GMAU
- Q3FY22 targets - 2.92M GMAU, 704k paid GMAU
- Q4FY22 targets - 3.19M GMAU, 769k paid GMAU

Is Primary PI: true

Health: Okay

• Insight - GMAU increased less than 1% from April to May but we are still on track to achieving our Q2FY22 target
• Insight - Paid GMAU increased 3% April to May which is slightly under target.
• Improvement - The team is currently focused on performance as our secondary PI. We do not anticipate this to drive immediate improvement in our primary PI but over time it will contribute to retention and enable us to continue to land bigger and bigger customers.

Metric Name: action_monthly_active_users_project_repo

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

URL(s)

• https://app.periscopedata.com/app/gitlab/728380/WIP-Create-Stage-Dashboard?widget=9520571&udv=0

Implementation Status: Complete

• Enabled on GitLab.com
• Released for self-managed in GitLab 13.3

Create:Source Code Secondary - Other - GitLab.com performance scores

Performance of the top 3 backend services for Source Code (apdex), and its related frontend counterparts (LCP) showing improvememnts over time.
Why: Aligning with our SaaS first and product depth direction, we recognize the performance of GitLab.com is a large factor considered when evaluating GitLab. We firmly believe speed is the killer feature and as such will work to provide a speedy experience to set a great stage for new and existing users.

Target: TBD

Health: Unknown

• Insight - total time taken to process pull mirror operations has steadily increased. We will re-evaluate its implementation to enhance or refactor.
• Insight - recent performance improvements have decreased LCP of commits view by ~20% 💪
• We continue to investigate which are the most relevant measures to track and how to aggregate sensibly. We will measure apdex for the top 3 services used (BE) and LCP for its corresponding application pages (FE). This is currently WIP, see investigation issue.

URL(s)

• https://gitlab.com/gitlab-org/gitlab/-/issues/327659
• https://dashboards.gitlab.net/d/stage-groups-source_code/stage-groups-group-dashboard-create-source-code?orgId=1&from=1618343400000&to=1618365059999&var-PROMETHEUS_DS=Global&var-environment=gprd&var-stage=main&var-controller=All&var-action=All&viewPanel=12
• https://dashboards.gitlab.net/d/stage-groups-source_code/stage-groups-group-dashboard-create-source-code?orgId=1

Implementation Status: Instrumentation

• The Create:Source Code group is investigating which of the many measures currently instrumented for GitLab.com are suitable for dual apdex and LCP Tracking. Once selection is complete we will work to bring into a single dashboard and set targets.

Create:Source Code - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Create:Code Review - Category MAU - Unique users using Merge Requests

This is defined as users who perform one or more of the following actions in a merge request - create, merge, or close a Merge Request.

SaaS/SM: Both

Target: Our target growth rate is 3% higher than the previous month for SMAU, and 4% for Paid SMAU.

Is Primary PI: true

Health: Okay

• Target - This aligns with our current understanding that Code Review is about 50% of the MAU of the stage metric and continuing to maintain that difference.

Metric Name: merge_requests_users

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

URL(s)

• https://app.periscopedata.com/app/gitlab/526749/Create---Code-Review-category-dashboard

Implementation Status: Complete

• Enabled on GitLab.com 2020-07-04
• Enabled for self-managed on GitLab 13.2

Lessons Learned (July):

• Attention - Code Review is focused on performance of large merge requests for Q2. While this is a net positive impact to the product, it is not expected to drive growth or adoption of features among new users. Code Review is also significantly over error budget and further investigations/work in to those areas will be required.
• FYI - New aggregated metrics data is in, but only 34% of instances are on a version that supports these metrics so we can't make the switch yet.
• Insight - New aggregated metrics are showing a 17%+ increase for GitLab SaaS over current tracking methods.

Create:Code Review - Other - Code Review/SCM Ratio by UMAU and Subscription Tier

SaaS/SM: Both

Target: TBD - Primarily this metric is used for monitoring the relationship between SCM GMAU and Code Review GMAU to make sure it doesn't not fall out of alignment.

Health: Unknown

• Target - this metric is primarily monitored to remain at a consistent level.
• Insight - Paid Instances with 10+ users more closely track to 75% of SCM Users using Code Review
• Insight - Free Instances and those with less than 10 users drive down the SCM<->Code Review Ratio as most have less than 50% adoption

Metric Name: merge_requests_users

Chart (Sisense↗)

Secondary Chart (Sisense↗)

URL(s)

• https://app.periscopedata.com/app/gitlab/801102/SCM-%3C%3E-Code-Review-%3C%3E-Verify
• https://app.periscopedata.com/app/gitlab/801102/SCM-%3C%3E-Code-Review-%3C%3E-Verify?widget=10728688&udv=1218043

Implementation Status: Complete

Create:Code Review - Editor Extension (VS Code) - Category MAU

This is defined as users who use [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) for VS Code and make at least one API request to a GitLab instance.

SaaS/SM: Both

Target: Our target is 100k monthly active users (outpacing Web IDE adoption). Ambitiously a 20% MoM growth rate would achieve this target in 9 months, but we should aim to hit this faster.

Health: Attention

• Target - Defining a target of 100k monthly active users puts us on a path to 50% of developers using GitLab (market share data) and aligns us to more users than the Web IDE (investment hypothesis).

Chart (Sisense↗)

URL(s)

• https://app.periscopedata.com/app/gitlab/825329/Editor-Extension-(VS-Code)-MAU-Metrics

Implementation Status: Complete

• Enabled in GitLab 13.9
• Target defined 2021-06-07

Lessons Learned (July):

• Improvement/Highlight - GitLab Workflow 3.21.0 released with a complete code review experience
• Attention - Brainstorming opportunities to promote GitLab Workflow and increase adoption

Create:Code Review - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Create:Gitaly - Other - Availability

Percentage of time during which Gitaly is fully operational and providing service to users within SLO parameters. Availability is measured according by Apdex (latency) and error rate. Gitaly is considered available when at least 50% of users are experiencing satisfactory latency, and 50% of requests are completing successfully. If either of these conditions is not met, the service is experiencing an outage.

SaaS/SM: Both

Target: 99.95%, consistent with GitLab.com availability service level objectives

Is Primary PI: true

Health: Unknown

• Instrumentation for this metric started in 13.4 and is still ongoing. Currently utilizing SaaS metrics via Grafana.

Metric Name: gitaly_apdex

URL(s)

• https://dashboards.gitlab.net/d/gitaly-main/gitaly-overview
• https://gitlab.com/gitlab-org/gitlab/-/issues/216683

Implementation Status: Instrumentation

• Rolling 7 day metrics available in Grafana for GitLab.com. Current availability per Adpex is 99.98%.
• Improvement - self-managed availability metrics are planned, but not currently in the backlog due to technical limitations.

Create:Gitaly - Other - Unique instances with Gitaly Cluster enabled

Number of recorded GitLab instances with Gitaly Cluster enabled

SaaS/SM: Self-Managed

Target: 75 Paid Customers using Gitaly Cluster by August 2021

Health: Okay

• Insight - On track to exceed target of 75 paying instances by August (rose from 65 to 71 from May to June)
• Insight - Ultimate usage continues to rise
• Improvement - Updated instructions for migration to Gitaly Cluster
• Improvement - Repository level incremental backups should be released soon, which is a much requested feature.

Metric Name: gitaly_clusters

Chart (Sisense↗)

URL(s)

• https://dashboards.gitlab.net/d/gitaly-main/gitaly-overview

Implementation Status: Complete

• Instrumentation for reporting on instances with Gitaly Cluster enabled was introduced in 13.0 with the GA of Gitaly Cluster.
• Insight - Team has worked hard and has consistently been under the error budget allocated.

Create:Gitaly - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Okay

• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Create:Editor - GMAU - Unique users committing via any web editor

A rolling count of the number of unique users who performed a Git write operation to any repository using the Web IDE, Web Editor or Snippet within a stage in the last 28 days

SaaS/SM: Both

Target: 4% growth month over month for All

Is Primary PI: true

Health: Attention

• Insight - Relatively flat for the third month, with self-managed somewhat slightly outpacing web editor usage. We'll be shifting focus back on the Web IDE in 14.1 so we hope to see this pick up again in late Q2 - early Q3.
• Insight - A higher percentage of self-managed users are committing write operations from web editors when compared to the total number of MAU writing to a git repo. It's not a dramatic difference (16.6% on self-managed vs 13.5% on SaaS) but investigation into the usage patterns here could uncover areas for faster growth in SaaS usage.
• Improvement - Source Editor is going to be used to render files in the repository view, making it possible to switch immediately into "edit" mode. Expectations are an uptick in commits over the next quarter by reducing friction and improving performance .

Metric Name: action_monthly_active_users_ide_edit

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

URL(s)

• https://app.periscopedata.com/app/gitlab/741875/Create:Editor-xMAU

Implementation Status: Complete

Create:Editor - AMAU - Unique users committing by web editor

A rolling count of the number of unique users who performed a Git write operation to any respository using the Web IDE, Web Editor or Snippet within a stage in the last 28 days - users grouped by editor used

SaaS/SM: Both

Target: TBD

Health: Unknown

• Insight - Editing through the Web Editor (single file editor) is 2-to-1 for users of the Web IDE though the gap is narrowing slightly over time. This confirms data recognized previously based on navigation paths that the single file editor is more widely used. We need to continue monitoring this to determine future investments in the Web IDE.
• Note - Important to call out that these are not unique users, so the same user can be reported as using multiple web editors.

Metric Name: action_monthly_active_users_web_ide_edit, action_monthly_active_users_sfe_edit, action_monthly_active_users_snippet_editor_edit

Chart (Sisense↗)

URL(s)

• https://app.periscopedata.com/app/gitlab/741875/Create:Editor-xMAU

Implementation Status: Completed Dashboard

Create:Editor - Other - Number of Commits per Month from the Web IDE

The total number of commits made via the Web IDE.

SaaS/SM: Both

Target: Maintain organic growth, 800K by end of Q2 2021

Health: Okay

• Insight - Interesting trend to watch where the number of commits increased while the number of MAU creating those commits remained flat or trended slightly down. Those users who are committing from the Web IDE are doing it with increasing frequency.

Metric Name: web_ide_commits

Chart (Sisense↗)

URL(s)

• https://app.periscopedata.com/app/gitlab/723366/Create:Editor-Expanded-for-Embed

Implementation Status: Complete

Create:Editor - Other - Number of new Snippets per Month

The number of new Snippets created each month.

SaaS/SM: Both

Target: 4% Growth month-over-month to 82k Snippets per Month by Q2 2021

Health: Okay

• Insight - Another dip but overall trends seem steady, especially given the lack of new features in this category.
• Insight - Self-Managed continues to account for about 8x the number of snippets. Investigation into the user behavior here is warranted but it's likely due to the nature of snippets visibility and permissions. Self-Managed users may be more comfortable creating snippets for their instance.

Metric Name: snippets_change

Chart (Sisense↗)

URL(s)

• https://gitlab.com/gitlab-data/analytics/-/issues/4400

Implementation Status: Complete

• Instrumentation for number of snippets is complete for self-managed and SaaS.

Create:Editor - AMAU - Unique users committing via the Static Site Editor

Monthly unique users that have made at least one commit via the static site editor.

SaaS/SM: Both

Target: None defined until we shift focus back to this category

Health: Attention

• Insight - Consistently flat, likely the same 25-30 GitLab users editing the Handbook each month.
• Goal - Removed our Q1 goal since we're not investing in features that would meaningfully impact adoption in the near future.

Metric Name: static_site_editor_create_commit

Secondary Chart (Sisense↗)

URL(s)

• https://app.periscopedata.com/app/gitlab/684213/WIP-Static-Site-Editor-Usage-Metrics
• https://about.gitlab.com/direction/create/editor/static_site_editor/

Implementation Status: Complete

• Improvement - Instrumentation for Usage Ping completed in 13.7

Create:Editor - AMAU - Uniques users of Wiki

Monthly unique users that have viewed or edited a wiki

SaaS/SM: Both

Target: 10% higher than current month (SaaS and self-managed combined)

Health: Okay

• No target defined

Metric Name: action_monthly_active_users_wiki_repo

Chart (Sisense↗)

Secondary Chart (Sisense↗)

URL(s)

• https://gitlab.com/gitlab-org/gitlab/-/issues/230481

Implementation Status: Complete

• Insight - Similar trend in May that we see with web editor commits - MAU slightly decreased on SaaS and slightly increased on self-managed, overall flat.
• Improvement - The WYSIWYG/visual markdown editor for Wiki, is available now (self-managed in 14.0). We don't expect immediate impact to MAU since we're still maturing the editor to fully support GitLab Flavored Markdown, but by Q3 we expect the new editor to be the default editing experience for Wikis and drive increased usage.

Create:Editor - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Create:Ecosystem - GMAU - MAU of any integration

Monthly Unique Users of any GitLab integration.

SaaS/SM: Both

Target: TBD

Is Primary PI: true

Health: Unknown

• No target defined
• Improvement - Adding Group and Instance integration will allow larger sets of projects to be integrated easily
• Improvement - Improvements and new functionality in the Jira integration should increase adoption, expanding on the success of our most popular integration

Metric Name: TBD

URL(s)

• https://gitlab.com/groups/gitlab-org/-/epics/5181
• https://gitlab.com/gitlab-org/gitlab/-/issues/297401
• https://gitlab.com/gitlab-data/analytics/-/issues/7974

Implementation Status: Instrumentation

• Awaiting implementation of data in Usage Ping
• Improvement - (March 2021) Updates are in progress, GMAU tracking is implemented and data is starting to flow in, will be on the dashboard once updates complete
• Awaiting implementation of Sisense dashboard (blocked by Usage Ping implementation)

Create:Ecosystem - Other - Total active project integrations

The total number of active project service integrations across all usage ping data (which includes GitLab.com)

SaaS/SM: Both

Target: Maintain flat adoption rate relative to overall GitLab growth

Health: Okay

• Observation - Growth tracks fairly evenly against overall usage growth (total number of projects created), demonstrating flat relative adoption rate of integrations
• Observation - GitLab.com users integrate at ~1/3 the rate that self-managed users do

Metric Name: projects_asana_active, projects_assembla_active, projects_bamboo_active, projects_bugzilla_active, projects_buildkite_active, projects_campfire_active, projects_confluence_active, projects_custom_issue_tracker_active, projects_discord_active, projects_drone_ci_active, projects_emails_on_push_active, projects_external_wiki_active, projects_flowdock_active, projects_github_active, projects_gitlab_slack_application_active, projects_hangouts_chat_active, projects_hipchat_active, projects_irker_active, projects_jenkins_active, projects_jira_active, projects_jira_cloud_active, projects_jira_dvcs_cloud_active, projects_jira_dvcs_server_active, projects_jira_issuelist_active, projects_jira_server_active, projects_mattermost_active, projects_mattermost_slash_commands_active, projects_microsoft_teams_active, projects_packagist_active, projects_pipelines_email_active, projects_pivotaltracker_active, projects_prometheus_active, projects_pushover_active, projects_redmine_active, projects_slack_active, projects_slack_notifications_active, projects_slack_slash_active, projects_slack_slash_commands_active, projects_teamcity_active, projects_unify_circuit_active, projects_webex_teams_active

Chart (Sisense↗)

Implementation Status: Dashboard

• Good overall tracking of project integrations, detailed breakdown available per-integration
• Updating dashboards to for Paid / All breakouts

Create:Ecosystem - Other - Integrations managed at Group or Instance level

The total number of active project integrations that are being defined by a Group or Instance integration

SaaS/SM: Both

Target: Not defined

Health: Unknown

• No data so far

Metric Name: TBD

URL(s)

• https://gitlab.com/gitlab-data/analytics/-/issues/7974

Implementation Status: Dashboard

• Improvement - (March 2021) Dashboard update in progress that will add this data to the dashboard.

Create:Ecosystem - Error Budget for GitLab.com

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. Spent budget is the time (in minutes) during which user facing services have experienced a percentage of errors below the specified threshold and latency is above the specified objectives for the service.

Target: 99.95% availability, allowed unavailability window is 20 minutes per month

Health: Problem

• This is a new PI and is a shared PI with Infrastructure availability targets
• The dashboards are located in grafana

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Other PI Pages

• Performance Indicator Maturity Table
• Engineering Function Performance Indicators
  • Customer Support Department Performance Indicators
  • Development Department Performance Indicators
    • Centralized Dashboards
  • Infrastructure Department Performance Indicators
  • Quality Department Performance Indicators
  • Security Department Performance Indicators
  • UX Department Performance Indicators
• Product Performance Indicators
  • Dev Section Performance Indicators
  • Ops Section Performance Indicators
  • Sec Section Performance Indicators
  • Enablement Section Performance Indicators
  • Stage and Group Performance Indicators
• Corporate Finance Performance Indicators
• Talent Acquisition Performance Indicators
• People Success Indicators
• KPI Index

Legends

Health

Value	Level	Meaning
3	Okay	The KPI is at an acceptable level compared to the threshold
2	Attention	This is a blip, or we’re going to watch it, or we just need to enact a proven intervention
1	Problem	We'll prioritize our efforts here
-1	Confidential	Metric & metric health are confidential
0	Unknown	Unknown

How to work with pages like this

Pages

Pages, such as the Engineering Function Performance Indicators page are rendered by an ERB template that contains HTML code.

• Any changes to the Performance Indicator (PI) ERB template will cascade to all links under the Other PI Pages section
• To add, delete, or update (K)PI information (including title, description, etc), make changes to the corresponding Performance Indicators data file. See more details in the Data section below.
• To update the way each individual (K)PI displays:
  • make changes to the Performance Indicators List ERB file for how the (K)PI is displayed on the KPI Index page
  • make changes to the Performance Indicators ERB file for any other properties and its format
• When adding a new PI page,
  • create the new PI page in the business division's handbook section (like the Engineering Division page)
  • include the relative link to the PI page in the Performance Indicators List ERB file
  • add all the (K)PI information into the corresponding Performance Indicators data file

Helper Functions

These ERB templates calls custom helper functions that extract and transform data from the Performance Indicators data file.

• The kpi_list_by_org(org) helper function takes a required string argument named org (deparment or division level) that returns all the KPIs (pi.is_key == true) for a specific organization grouping (pi.org == org) from the Performance Indicators data file.
• The pi_maturity_level(performance_indicator) helper function automatically assigns a maturity level based on the availability of certain data properties for a particular PI.
• The pi_maturity_reasons(performance_indicator) helper function returns a reason for a PI maturity based on other data properties.
• The performance_indicators(org) takes a required string argument named org (deparment or division level) that returns two lists - a list of all KPIs and a list of all PIs for a specific organization grouping (department/division).
• The signed_periscope_url(data) takes in the sisense_data property information from Performance Indicators data files and returns a signed chart URL for embedding a Sisense chart into the handbook.

Data

The heart of pages like this are Performance Indicators data files which are YAML files. Each - denotes a dictionary of values for a new (K)PI. The current elements (or data properties) are:

Property	Type	Description
name	Required	String value of the name of the (K)PI. For Product PIs, product hierarchy should be separate from name by " - " (Ex. {Stage Name}:{Group Name} - {PI Type} - {PI Name}
base_path	Required	Relative path to the performance indicator page that this (K)PI should live on
definition	Required	refer to Parts of a KPI
parent	Optional	should be used when a (K)PI is a subset of another PI. For example, we might care about Hiring vs Plan at the company level. The child would be the division and department levels, which would have the parent flag.
target	Required	The target or cap for the (K)PI. Please use Unknown until we reach maturity level 2 if this is not yet defined. For GMAU, the target should be quarterly.
org	Required	the organizational grouping (Ex: Engineering Function or Development Department). For Product Sections, ensure you have the word section (Ex : Dev Section)
section	Optional	the product section (Ex: dev) as defined in sections.yml
stage	Optional	the product stage (Ex: release) as defined in stages.yml
group	Optional	the product group (Ex: progressive_delivery) as defined in stages.yml
category	Optional	the product group (Ex: feature_flags) as defined in categories.yml
is_key	Required	boolean value (true/false) that indicates if it is a (key) performance indicator
health	Required	indicates the (K)PI health and reasons as nested attributes. This should be updated monthly before Key Reviews by the DRI.
health.level	Optional	indicates a value between 0 and 3 (inclusive) to represent the health of the (K)PI. This should be updated monthly before Key Reviews by the DRI.
health.reasons	Optional	indicates the reasons behind the health level. This should be updated monthly before Key Reviews by the DRI. Should be an array (indented lines starting with dashes) even if you only have one reason.
urls	Optional	list of urls associated with the (K)PI. Should be an array (indented lines starting with dashes) even if you only have one url
funnel	Optional	indicates there is a handbook link for a description of the funnel for this PI. Should be a URL
sisense_data	Optional	allows a Sisense dashboard to be embeded as part of the (K)PI using chart, dashboard, and embed as neseted attributes.
sisense_data.chart	Optional	indicates the numeric Sisense chart/widget ID. For example: 9090628
sisense_data.dashboard	Optional	indicates the numeric Sisense dashboard ID. For example: 634200
sisense_data.shared_dashboard	Optional	indicates the numeric Sisense shared_dashboard ID. For example: 185b8e19-a99e-4718-9aba-96cc5d3ea88b
sisense_data.embed	Optional	indicates the Sisense embed version. For example: v2
sisense_data_secondary	Optional	allows a second Sisense dashboard to be embeded. Same as sisense data
sisense_data_secondary.chart	Optional	Same as sisense_data.chart
sisense_data_secondary.dashboard	Optional	Same as sisense_data.dashboard
sisense_data_secondary.shared_dashboard	Optional	Same as sisense_data.shared_dashboard
sisense_data_secondary.embed	Optional	Same as sisense_data.embed
public	Optional	boolean flag that can be set to false where a (K)PI does not meet the public guidelines.
pi_type	Optional	indicates the Product PI type (Ex: AMAU, GMAU, SMAU, Group PPI)
product_analytics_type	Optional	indicates if the metric is available on SaaS, SM (self-managed), or Both.
is_primary	Optional	boolean flag that indicates if this is the Primary PI for the Product Group.
implementation	Optional	indicates the implementation status and reasons as nested attributes. This should be updated monthly before Key Reviews by the DRI.
implementation.status	Optional	indicates the Implementation Status status. This should be updated monthly before Key Reviews by the DRI.
implementation.reasons	Optional	indicates the reasons behind the implementation status. This should be updated monthly before Key Reviews by the DRI. Should be an array (indented lines starting with dashes) even if you only have one reason.
lessons	Optional	indicates lessons learned from a K(PI) as a nested attribute. This should be updated monthly before Key Reviews by the DRI.
lessons.learned	Optional	learned is an attribute that can be nested under lessonsand indicates lessons learned from a K(PI). This should be updated monthly before Key Reviews by the DRI. Should be an array (indented lines starting with dashes) even if you only have one lesson learned
monthly_focus	Optional	indicates monthly focus goals from a K(PI) as a nested attribute. This should be updated monthly before Key Reviews by the DRI.
monthly_focus.goals	Optional	indicates monthly focus goals from a K(PI). This should be updated monthly before Key Reviews by the DRI. Should be an array (indented lines starting with dashes) even if you only have one goal
metric_name	Optional	indicates the name of the metric in Self-Managed implemenation. The SaaS representation of the Self-Managed implementation should use the same name.

Guidelines

Please reference the Engineering Metrics Page for guidelines on chart visualization formatting.