Stage and Group Performance Indicators

1. You are here:
2. Handbook
3. Product Handbook
4. Stage and Group Performance Indicators

On this page

• SMAU Summary
• GMAU Summary
• Other Stage PIs Summary
• Other Group PIs Summary
• SMAU PI Details
  • Manage, Manage:Optimize - SMAU, GMAU - MAU Viewing Analytics Features
  • Plan, Plan:Project Management - SMAU, Paid GMAU - MAU Interacting With Issues
  • Create - SMAU - Unique users writing to a Git repository
  • Verify, Verify:CI - GMAU, SMAU - Unique users triggering pipelines
  • Package:Package - SMAU, GMAU - Count of users publishing packages
  • Release:Release - SMAU - Count of users triggering deployments using GitLab
  • Configure:Configure - SMAU, GMAU - MAU of GitLab Managed Terraform State
  • Monitor:Monitor - SMAU, GMAU - Unique users that interact with Alerts and Incidents
  • Sec, Secure - Section MAU, SMAU - Unique users who have used a Secure scanner
  • Protect:Container Security - SMAU, GMAU - Users running Container Scanning or interacting with Protect UI
• GMAU PI Details
  • Manage, Manage:Optimize - SMAU, GMAU - MAU Viewing Analytics Features
  • Manage:Access - Paid GMAU - MAU Using Paid SAML
  • Manage:Compliance - Paid GMAU - MAU Viewing Compliance Features
  • Manage:Import - GMAU - MAU importing
  • Plan, Plan:Project Management - SMAU, Paid GMAU - MAU Interacting With Issues
  • Plan:Product Planning - Paid GMAU - MAU creating Epics each Month
  • Create:Source Code - GMAU - Unique users writing to a project Git repository
  • Create:Editor - GMAU - Unique users committing via any web editor
  • Create:Ecosystem - GMAU - MAU of any integration
  • Enablement:Geo - Paid GMAU - Number of unique users utilizing a Geo secondary
  • Enablement:Global Search - Paid GMAU - The number of unique paid users per month
  • Enablement:Infrastructure - Paid GMAU - Number of unique paid users that perform an action on GitLab.com
  • Verify, Verify:CI - GMAU, SMAU - Unique users triggering pipelines
  • Verify:Pipeline Authoring - GMAU - Number of unique users interacting with gitlab-ci.yml file
  • Verify:Testing - Paid GMAU - Count of active paid testing feature users
  • Package:Package - SMAU, GMAU - Count of users publishing packages
  • Release:Release - SMAU - Count of users triggering deployments using GitLab
  • Configure:Configure - SMAU, GMAU - MAU of GitLab Managed Terraform State
  • Monitor:Monitor - SMAU, GMAU - Unique users that interact with Alerts and Incidents
  • Secure:Static Analysis - GMAU - Users running Static Analysis jobs
  • Secure:Dynamic Analysis - GMAU - Users running DAST
  • Secure:Composition Analysis - GMAU - Users running any SCA scanners
  • Secure:Fuzz Testing - GMAU - Users running fuzz testing
  • Secure:Threat Insights - GMAU - Users interacting with Secure UI
  • Protect:Container Security - SMAU, GMAU - Users running Container Scanning or interacting with Protect UI
• Other Stage PIs Details
  • Enablement - Section PPI, Stage PPI - Median End User Page Load Time
• Other Group PIs Details
  • Enablement:Distribution - Group PPI - Percentage of installations on the 3 most recent versions of GitLab
  • Enablement:Memory - Group PPI - Memory Consumed
  • Enablement:Database - Group PPI - Database Query Apdex (100ms target, 250ms tolerable)
  • Verify:Runner - Other - Total downloads of runner binaries and docker images per month
• Other PI Pages
• Legends
  • Health
• How to work with pages like this
  • Pages
    • Helper Functions
  • Data
  • Guidelines

SMAU Summary

Stage/Group	PI Type	PI	Health	SaaS / SM	Implementation Status
Manage, Manage:Optimize	SMAU, GMAU	MAU Viewing Analytics Features	Okay	Both	Complete
Plan, Plan:Project Management	SMAU, Paid GMAU	MAU Interacting With Issues	Attention	Both	Complete
Create	SMAU	Unique users writing to a Git repository	Okay	Both	Complete
Verify, Verify:CI	GMAU, SMAU	Unique users triggering pipelines	Okay	Both	Complete
Package:Package	SMAU, GMAU	Count of users publishing packages	Okay	Both	Complete
Release:Release	SMAU	Count of users triggering deployments using GitLab	Okay	Both	Complete
Configure:Configure	SMAU, GMAU	MAU of GitLab Managed Terraform State	Okay	Both	Complete
Monitor:Monitor	SMAU, GMAU	Unique users that interact with Alerts and Incidents	Okay	Both	Complete
Sec, Secure	Section MAU, SMAU	Unique users who have used a Secure scanner	Okay	Both	Complete
Protect:Container Security	SMAU, GMAU	Users running Container Scanning or interacting with Protect UI	Okay	Both	Complete

GMAU Summary

Stage/Group	PI Type	PI	Health	SaaS / SM	Implementation Status
Manage, Manage:Optimize	SMAU, GMAU	MAU Viewing Analytics 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	Attention	Both	Complete
Plan:Product Planning	Paid GMAU	MAU creating Epics each Month	Okay	Both	Complete
Create:Source Code	GMAU	Unique users writing to a project Git repository	Okay	Both	Complete
Create:Editor	GMAU	Unique users committing via any web editor	Okay	Both	Complete
Create:Ecosystem	GMAU	MAU of any integration	Unknown	Both	Instrumentation
Enablement:Geo	Paid GMAU	Number of unique users utilizing a Geo secondary	Attention	Both	Instrumentation
Enablement:Global Search	Paid GMAU	The number of unique paid users per month	Okay	Both	Complete
Enablement:Infrastructure	Paid GMAU	Number of unique paid users that perform an action on GitLab.com	Attention	SaaS	Complete
Verify, Verify:CI	GMAU, SMAU	Unique users triggering pipelines	Okay	Both	Complete
Verify:Pipeline Authoring	GMAU	Number of unique users interacting with gitlab-ci.yml file	Okay	Both	Implementation
Verify:Testing	Paid GMAU	Count of active paid testing feature users	Unknown	Both	Complete
Package:Package	SMAU, GMAU	Count of users publishing packages	Okay	Both	Complete
Release:Release	SMAU	Count of users triggering deployments using GitLab	Okay	Both	Complete
Configure:Configure	SMAU, GMAU	MAU of GitLab Managed Terraform State	Okay	Both	Complete
Monitor:Monitor	SMAU, GMAU	Unique users that interact with Alerts and Incidents	Okay	Both	Complete
Secure:Static Analysis	GMAU	Users running Static Analysis jobs	Okay	Both	Complete
Secure:Dynamic Analysis	GMAU	Users running DAST	Okay	Both	Complete
Secure:Composition Analysis	GMAU	Users running any SCA scanners	Okay	Both	Complete
Secure:Fuzz Testing	GMAU	Users running fuzz testing	Attention	Both	Definition
Secure:Threat Insights	GMAU	Users interacting with Secure UI	Attention	SaaS	Definition
Protect:Container Security	SMAU, GMAU	Users running Container Scanning or interacting with Protect UI	Okay	Both	Complete

Other Stage PIs Summary

Stage/Group	PI Type	PI	Health	SaaS / SM	Implementation Status
Enablement	Section PPI, Stage PPI	Median End User Page Load Time	Attention	Both	Complete

Other Group PIs Summary

Stage/Group	PI Type	PI	Health	SaaS / SM	Implementation Status
Enablement:Distribution	Group PPI	Percentage of installations on the 3 most recent versions of GitLab	Attention	Both	Complete
Enablement:Memory	Group PPI	Memory Consumed	Attention	Both	Complete
Enablement:Database	Group PPI	Database Query Apdex (100ms target, 250ms tolerable)	Attention	Both	Complete
Verify:Runner	Other	Total downloads of runner binaries and docker images per month	Unknown	SM	Definition

SMAU PI Details

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

The number of unique users viewing any Analytics page.

SaaS/SM: Both

Target: 116050

Is Primary PI: true

Metric Name: analytics_total_unique_counts_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Okay

• Insights - Growth in page views by SaaS users was relatively flat. This is not surprising because feature announcements for February were focused on the user availability feature. However, SaaS views of our key feature, Value Stream Analytics, continued to grow steadily with 12% growth at the group level, possibly attributable to the 13.10 announcement of UX improvements.
• Insights - There continues to be strong interest in Value Stream Analytics. Usage of the group-level feature is still low compared to the project-level feature, presumably because of the tier difference (available in Core at the project level and Premium at the group level). However, usage of the group-level feature continues to grow with an 11% increase in views by self-managed Premium and Ultimate customers from February to March.
• Insights - MR Analytics page views continued to climb after the 13.9 announcement of the Mean Time to Merge metric with another 17% increase in views from self-managed Premium customers and 30% from Ultimate. In the previous PI review we announced that views of this page by Premium customers (self managed) increased 78% from December to February.
• Improvements - The DevOps Adoption feature that was previously only available to self-managed admins is being added at the group level in 13.11, expanding availability to all Ultimate users.
• SaaS data is not available for the paid SMAU chart due to limitations of the redis counter that is used.

Implementation Status: Complete

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

URL(s)

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

Metric Name: redis_hll_counters.issues_edit.issues_edit_total_unique_counts_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Attention

• FY22 Q1 Goals - Achieved 105% attainment for All and 97% for Paid. New targets are set for FY22 Q2.
• Health - Downgraded from OK to Attention to bring visibility to underlying signals pointing to future contractions in Plan xMAU growth. April was the second consecutive month that Self-Managed Paid MAU from "Shrinking" instances (a.k.a. Churn) has been larger than Self-Managed Paid MAU from "New" instances. Self-Managed Paid MAU from "Expanding" instances has also been declining MoM from an all-time high in January for a total decline of -28%. Along with the concerns highlighted by the Starter EoL, severe error budget overage, and our constricted ability to make meaningful progress on strategic xMAU roadmap items, our lack of flexibility to provide competitive pricing for personas other than technical / developer roles (internal) is creating a "perfect storm" for encouraging attrition while limiting our ability to effectively mitigate buyer objections.
• Driver - For Paid, continue high level 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.

Implementation Status: Complete

Lessons Learned (April):

• Okay - Only 42% of instances are currently on a version with the new Plan xMAU metric counters.
• Attention - April saw 1.6 net new Paid GMAU for every 1 churned Paid GMAU, which is a decline of 0.8 points from March. (Self-Managed Only)
• Okay - Free MAU declined 8% from March (SaaS Only)
• Attention - Starter EoL Impact - Net decrease of 814 MAU (-4.3%) from March to April for Starter on Self-Managed. This is a significant decline in growth which saw 12.9% increases from February to March. For SaaS, loss of 1,098 Starter MAU (-8.4%) from March to April. The blended growth rate for Premium and Ultimate across SaaS and Self-Managed was 4.2% from March to April, which was the lowest in the trailing three months with February averaging 15.2% and March 11.6%.
• Attention - SaaS Premium (4.2%) and Ultimate (-5.1%) saw the lowest overall growth for Plan Paid MAU on SaaS, which appears to be a leading indicator that Plan may be most impacted by the Starter EoL.
• Okay - March saw a 2.5% increase in overall instances reporting usage ping (39% to 40%).
• Problem - Plan is currently 3,900% over our target error budget of 20 min in the last 28 days with 97.99% availability against a target of 99.95%.

Focus This Month (May):

• Shift focus from 13.12 feature goals to meet immediate performance needs for SaaS. This will likely carry on into 14.0 and beyond given sheer size of internal requests within our stage coupled with the temporary loss of engineering resources that have been assigned to other initiatives within R&D. The bulk of the Plan capabilities roadmap to drive xMAU now falls within the 8th, 9th and 11th positions on our prioritization matrix. This, coupled with EoL for Starter, has and will continue to significantly impact future xMAU performance for Plan.
• Continued preparation for a "feature freeze" starting in 14.1 in order to fix long running instabilities and technical/product debt within our span of control, as well as increase our future throughput on executing on our longer term product strategy.
• Merge architectural blueprint for consolidating Groups and Projects on the backend.

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

URL(s)

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

Metric Name: action_monthly_active_users_project_repo

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Okay

• Observation - December 2020 SMAU is less than November 2020 SMAU. A similar drop can be observed in GMAU as well, suggesting a common cause. The cause is likely seasonality consistent with the end of year. For this reason January SMAU and GMAU is expected to return to November 2020 levels and continue growing.
• Insight - on the median GitLab instance, 33% of users perform a Git write operation each month (source).
• Insight - on the median Paid GitLab instance (self-managed), 50% of users perform a Git write operation each month (source).

Implementation Status: Complete

• Improvement - AMAU is currently over counted. A deduplicated counter was implemented gitlab#234027 in GitLab 13.6. The charts do not yet reflect the new counter gitlab#291943.

Verify, Verify:CI - GMAU, SMAU - Unique users triggering pipelines

A rolling count of unique users triggering pipelines in the last 28 days because CI is the foundation for several downstream product areas, and improving SMAU for people using pipelines is important to help with discovery of these further features.

SaaS/SM: Both

Target: In FY22 Q1, we anticipate accomplishing this target of 1.1M unique users as predicted in our [tertiary chart](https://app.periscopedata.com/app/gitlab/798616/WIP-Linear-Predicted-Dashboard?widget=10611135).

Is Primary PI: true

Metric Name: ci_pipelines

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• Metric is instrumented for both SaaS and Self-managed

Implementation Status: Complete

• With ability to trigger a pipeline dependent on successful attempts to author CI yaml files, we have an issue to track number of new gitlab-ci.yml files created.
• We are also working to instrument other performance indicators for Verify:CI
• Updating dashboard to have both SM / SaaS and Paid / All breakouts
• Insight - Intial funnel analysis via verify-stage#48, shows there is a siginificant drop off from SCM users to user triggering pipelines. Within Verify, the percentage of users authoring a pipeline drops 88% from users triggering pipelines, and those who are using Paid Testing features drop 90% from the Pipeline Authoring Users. We are looking at what kind of user based metric of Runner is applicable, although, all portions of runner users would be included in SCM and Verify Users in this model.

Lessons Learned (April):

• Insight - In March 2021, we are have fully recovered from our dip in growth and our usage in both distributions is increasing. We are 20,000 users short of our FY22-Q1 target, which we can expect to accrue with organic growth in self-managed alone. SaaS grew 13K (4.2K users are Paid) and Self-managed grew 47K (12K are Paid).
• Insight - We are working with Data team via data#8400 to instrument more granular analysis of Verify MAU on .com.
• Insight - We are seeing an increase in expanding instances (by 5%), while shrinking instances are decreasing (by 9%) indicating our self-managed instances are growing.
• Improvement - We are are continuing to invest heavily in optimizing the performance of database queries in CI pipelines via gitlab&5434 and the mitigation of pipeline abuse via [gitlab&5583]. We have proposed adding a CI Scaling category to navigate these challenges of SaaS availabiity and performance. Both of these efforts have been prioritized over the investment in usability of Artifacts and Variables, which were the 1H FY22 direction.

Package:Package - SMAU, GMAU - Count of users publishing packages

The maximum distinct count of users who published a package to the Package Registry. In the future, this value will the distinct count of users across all Package AMAUs.

Funnel Description: Handbook Link

SaaS/SM: Both

Target: The target for FY22-Q1 is 40,000 unique users publishing packages across SaaS and self-managed combined.

Is Primary PI: true

Metric Name: user_packages_total_unique_counts_monthly

Chart (Sisense↗)

Health: Okay

• Improvements - In 14.0 we will evaluate rolling out weekly metrics, pending scalability and performance.

Implementation Status: Complete

Lessons Learned (April):

• Improvements - In 13.11, we shipped several key issues for Composer and Conan. Although these are the least frequently used formats, both had a large estimated lift in March. We hope that addressing these popular issues will translate into increased adoption in April.
• Improvements - In 13.11, we shipped a popular request to add support for SemVer to generic packages. Although it's early to tell, on GitLab.com we went from 3k events per day to 6k per day since the feature launched.
• Improvements - In 13.12, we are primarily focused on scalabilitiy, performance, and usability. However we have a stretch goal to add a group-level PyPI endpoint. When we added a similar feature for NuGet, we saw a 60% lift in activity.

Release:Release - SMAU - Count of users triggering deployments using GitLab

A rolling count of unique users triggering deployments with Gitlab in the last 28 days.

Funnel Description: Handbook Link

SaaS/SM: Both

Target: The target for FY22-Q1 is 453,000 for unique users triggering deployments, and 213,000 for paid unique users triggering deployments.

Is Primary PI: true

URL(s)

• https://app.periscopedata.com/app/gitlab/777879/Release-Stage-Dashboard?widget=10833391&udv=0

Metric Name: deployments

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Okay

• Insight - We have reached our yearly target for deployments for both SMAU and paid SMAU. There was a 9% increase in deployments from last month.
• Improvements - Release has recently shipped some of the DORA4 metrics and specifically deployment frequency which gives the user insights into their deployment efficiency and should encourage them to increase deployments.
• Improvements - In the next few milestones, we will add in-product guidance for users that have pipelines that are not triggering deployments.

Implementation Status: Complete

• We are currently tracking this data for GitLab.com via Snowplow and as a usage ping for self-managed instances.
• We need to Expand Revenue Attribution to Release SMAU
• Updating dashboard to have Paid / All breakouts

Configure:Configure - SMAU, GMAU - MAU of GitLab Managed Terraform State

Monthly active users of GitLab Managed Terraform State

Funnel Description: Handbook Link

SaaS/SM: Both

Target: The target for FY22-Q1 is 5000 monthly active users of GitLab Managed Terraform State

Is Primary PI: true

URL(s)

• https://app.periscopedata.com/app/gitlab/511813/Configure-team-business-metrics
• https://app.periscopedata.com/app/gitlab/677628/Infrastructure-as-Code

Metric Name: redis_hll_counters.terraform.p_terraform_state_api_unique_users_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• Improvement - I'm working with Mathieu on a simple way to add targets to our charts, when targets are defined in the PI yaml.

Implementation Status: Complete

• We have MAU based metrics.

Lessons Learned (April):

• Insight - As we were moving from generic adoption metrics to MAU, I've expected higher MAU numbers. I'm still looking into it.
• Blocker - We are short on resources, and I'm currently prioritising other areas that might have only indirect effects on the SMAU.

Monitor:Monitor - SMAU, GMAU - Unique users that interact with Alerts and Incidents

Unique users that interact with alerts or incidents. (This metric represents the GMAU for the Monitor:Monitor group as well as the SMAU for the Monitor stage. It is based on usage of the Incident Management category which is the only category in the group or stage that is being actively developed. The definition for Monitor SMAU will be seperated from Monitor:Monitor GMAU when we are able to expand the definition to include usage of the other categories. That work is currently not a priority.)

Funnel Description: Handbook Link

SaaS/SM: Both

Target: The target for FY22-Q1 is 15,000 estimated total unique users that interact with alerts and incidents.

Is Primary PI: true

URL(s)

• https://app.periscopedata.com/app/gitlab/769975/Monitor-Stage-Dashboard

Metric Name: incident_management_total_unique_counts_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• We exceeded our target of FY22-Q1 target of 15,000 in 2021-03!

Implementation Status: Complete

• Instrumentation complete - issue.

Lessons Learned (April):

• March saw a 8% increase over February
• Looking over the past 2 quarters, we saw on average a 6% growth month over month
• We released the on-call schedule management in 13.11. Additional improvements are planned in 13.12. We also need to add instrumentation to schedule management
• Improvements - We are staring work on Escalation Policies. Escalation policies are a required part of object relationship in Incident Management. This feature will enable us to add paging

Sec, Secure - Section MAU, SMAU - Unique users who have used a Secure scanner

The number of unique users who have run one or more Secure scanners.

SaaS/SM: Both

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

Is Primary PI: true

Metric Name: user_unique_users_all_secure_scanners

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• currently instrumented to meet OKRs (see instrumentation, Lessons Learned for more details)

Implementation Status: Complete

• Can't currently differentiate between free-to-OSS/education Gold/Ultimate users and paid Gold/Ultimate users
• Threat Insights data is not yet included in this count until we support user-level metrics in Snowplow for self-managed

Focus This Month (May):

• Identify a way to denote underreporting on Secure-related *MAU charts to remove confusion / clarify metrics interpretation
• Identify usage by product tier while removing free-to-OSS/education Gold/Ultimate users
• Support Data team on improving Self-Managed Uplift for Secure

Protect:Container Security - SMAU, GMAU - Users running Container Scanning or interacting with Protect UI

The number of users who have run a container scanning job or interacted with the Protect UI in the last 28 days of the month.

SaaS/SM: Both

Target: Progressively increasing month-over-month, >2%

Is Primary PI: true

Metric Name: user_container_scanning_jobs

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• Usage growth is rapidly accelerating. It is estimated that the uplift is largely due to closed Gold/Ultimate deals in 2020 that are now adopting Secure.
• The shift from Clair to Trivy has generated a lot of customer interest. Although we are unable to slice the data by the type of scanning engine used, some of this uplift may be due to customers trying out the new Trivy scanning engine.

Implementation Status: Complete

• Limitations in data (see SCA limitations above)
• Although we have released the Alert Dashboard, we do not yet have a good way of tracking monthly active users for this area. Instrumentation is expected to be complex (1-2 months of one developer's time) and usage is expected to remain low until additional alert times are added to the dashboard. Currently instrumenting these metrics is a low priority.

Lessons Learned (April):

• The switch from Clair to Trivy has allowed us to close 20+ outstanding customer issues and bugs. Adoption is expected to increase significantly after the 14.0 release.

Focus This Month (May):

• Project-level DAST Scan Schedule Policies (pipeline) (https://gitlab.com/groups/gitlab-org/-/epics/5329) is available behind a feature flag
• Project-level DAST Scan Schedule Policies (scheduled scans) (https://gitlab.com/groups/gitlab-org/-/epics/5360) is being worked on for a May release
• Replacing Clair with Trivy (https://gitlab.com/groups/gitlab-org/-/epics/5398) will be the default beginning in the 14.0 release and will set the foundation for us to be able to scan containers in production environments

GMAU PI Details

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

The number of unique users viewing any Analytics page.

SaaS/SM: Both

Target: 116050

Is Primary PI: true

Metric Name: analytics_total_unique_counts_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Okay

• Insights - Growth in page views by SaaS users was relatively flat. This is not surprising because feature announcements for February were focused on the user availability feature. However, SaaS views of our key feature, Value Stream Analytics, continued to grow steadily with 12% growth at the group level, possibly attributable to the 13.10 announcement of UX improvements.
• Insights - There continues to be strong interest in Value Stream Analytics. Usage of the group-level feature is still low compared to the project-level feature, presumably because of the tier difference (available in Core at the project level and Premium at the group level). However, usage of the group-level feature continues to grow with an 11% increase in views by self-managed Premium and Ultimate customers from February to March.
• Insights - MR Analytics page views continued to climb after the 13.9 announcement of the Mean Time to Merge metric with another 17% increase in views from self-managed Premium customers and 30% from Ultimate. In the previous PI review we announced that views of this page by Premium customers (self managed) increased 78% from December to February.
• Improvements - The DevOps Adoption feature that was previously only available to self-managed admins is being added at the group level in 13.11, expanding availability to all Ultimate users.
• SaaS data is not available for the paid SMAU chart due to limitations of the redis counter that is used.

Implementation Status: Complete

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: 61000. See https://gitlab.com/gitlab-com/Product/-/issues/2258 for further detail.

Is Primary PI: true

Metric Name: user_auth_by_provider (Group_SAML)

Chart (Sisense↗)

Health: Okay

• Insights - April had the highest number of new SAML setup in groups ever! The number of newly configured SAML groups is a leading indicator, so this means that we can expect GMAU to keep going up in the coming months.
• Improvements - Changes to enforce SAML SSO by default for new groups are in progress! While digging into SAML usage data, I found that less than half of the groups that have SAML SSO enabled are enforcing it. This means that while you can access a group through SSO, you are not required to have an active SAML SSO session and you can access the group through other authentication methods.
• Attention - Due to Manage:Access focus on Rapid Action and Engineering Allocation work, we will be slowing down feature work for the next few milestones.

Implementation Status: Complete

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

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↗)

Health: Attention

• We're still building out the compliance features that are tracked by this metric so we expect trends may change in the future.
• 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.

Implementation Status: Complete

• Completed

Lessons Learned (April):

• We saw a decrease in our users this month. Looking at individual metrics, this was primarily driven by a decrease in users looking at our audit events screens.
• Hypothesis to explain this change is two main reasons - (1) some of the large growth we saw in February was from users who were exposed to the feature for the first time not continuing to use it. (2) Compliance users do not get enough value from the screen to continue using it after they explore it initially.
• We have repeatedly heard that actionability is important from users. They don't just want info, they want info they could use to make decisions.

Focus This Month (May):

• Re-factoring of audit events to prepare for adding new events in the future
• Start refinement and validation on webhook-based audit events
• We saw a large growth in self-managed users compared to .com users. This could be because more of our instance-specific features are getting adoption, from .com data integrity issues, or from something else. We will need to keep investigating.

Manage:Import - GMAU - MAU importing

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

SaaS/SM: Both

Target: 96,000 MAU importing projects

Is Primary PI: true

Metric Name: usage_activity_by_stage_monthly.manage.unique_users_all_imports

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Okay

• Target - Initial target set to 96,000, which is a 20% increase from the current user engagement level.
• Insights - A slight drop in the Saas numbers from March to April was offset by a slight increase in the self-managed numbers.
• Improvement - Reducing friction for GitLab-to-GitLab migrations - Our progress toward achieving feature parity with the existing Group Export/Import has been significantly slowed down, due to a focus on infradev performance improvements and support for migrating new customers.
• Note - SaaS data is not available for the paid GMAU chart due to limitations of the redis counter used.

Implementation Status: Complete

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

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

URL(s)

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

Metric Name: redis_hll_counters.issues_edit.issues_edit_total_unique_counts_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Attention

• FY22 Q1 Goals - Achieved 105% attainment for All and 97% for Paid. New targets are set for FY22 Q2.
• Health - Downgraded from OK to Attention to bring visibility to underlying signals pointing to future contractions in Plan xMAU growth. April was the second consecutive month that Self-Managed Paid MAU from "Shrinking" instances (a.k.a. Churn) has been larger than Self-Managed Paid MAU from "New" instances. Self-Managed Paid MAU from "Expanding" instances has also been declining MoM from an all-time high in January for a total decline of -28%. Along with the concerns highlighted by the Starter EoL, severe error budget overage, and our constricted ability to make meaningful progress on strategic xMAU roadmap items, our lack of flexibility to provide competitive pricing for personas other than technical / developer roles (internal) is creating a "perfect storm" for encouraging attrition while limiting our ability to effectively mitigate buyer objections.
• Driver - For Paid, continue high level 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.

Implementation Status: Complete

Lessons Learned (April):

• Okay - Only 42% of instances are currently on a version with the new Plan xMAU metric counters.
• Attention - April saw 1.6 net new Paid GMAU for every 1 churned Paid GMAU, which is a decline of 0.8 points from March. (Self-Managed Only)
• Okay - Free MAU declined 8% from March (SaaS Only)
• Attention - Starter EoL Impact - Net decrease of 814 MAU (-4.3%) from March to April for Starter on Self-Managed. This is a significant decline in growth which saw 12.9% increases from February to March. For SaaS, loss of 1,098 Starter MAU (-8.4%) from March to April. The blended growth rate for Premium and Ultimate across SaaS and Self-Managed was 4.2% from March to April, which was the lowest in the trailing three months with February averaging 15.2% and March 11.6%.
• Attention - SaaS Premium (4.2%) and Ultimate (-5.1%) saw the lowest overall growth for Plan Paid MAU on SaaS, which appears to be a leading indicator that Plan may be most impacted by the Starter EoL.
• Okay - March saw a 2.5% increase in overall instances reporting usage ping (39% to 40%).
• Problem - Plan is currently 3,900% over our target error budget of 20 min in the last 28 days with 97.99% availability against a target of 99.95%.

Focus This Month (May):

• Shift focus from 13.12 feature goals to meet immediate performance needs for SaaS. This will likely carry on into 14.0 and beyond given sheer size of internal requests within our stage coupled with the temporary loss of engineering resources that have been assigned to other initiatives within R&D. The bulk of the Plan capabilities roadmap to drive xMAU now falls within the 8th, 9th and 11th positions on our prioritization matrix. This, coupled with EoL for Starter, has and will continue to significantly impact future xMAU performance for Plan.
• Continued preparation for a "feature freeze" starting in 14.1 in order to fix long running instabilities and technical/product debt within our span of control, as well as increase our future throughput on executing on our longer term product strategy.
• Merge architectural blueprint for consolidating Groups and Projects on the backend.

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

The number of unique users creating Epics each month.

SaaS/SM: Both

Target: 3,900 Combined Unique Users for Self Managed and SaaS

Is Primary PI: true

Metric Name: epics

Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Okay

• March 2021 - 7706 GMAU is nearly double old target with a 30% increase in April.
• Note - Our new tracking for all epic interactions is only 2% adopted on instances >= 13.10. We expect this to increase over 3-4 months.
• Note - I want to give a few months before I comment on which epic actions are most affecting our GMAU
• Improvement - Epic Boards MVC 2 is planned to ship in 13.12 with a full roll out in 14.0 and should continue the trend into the end of FY21 by enabling Portfolio-level planning.
• Our next target will be set after 14.0 and epic boards release and verifying our new graphs for GMAU.

Implementation Status: Complete

• New Sisense graph WIP GMAU - Users interacting with Epics
• All epic interactions were instrumented during 13.9 - 13.12. Instrumentation issue and dasboard issue.
• We've added trackers for epic board creation ahead of the release in 14.0 - Epic board tracking issue
• A new target will be selected when we have a baseline.

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

URL(s)

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

Metric Name: action_monthly_active_users_project_repo

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Okay

• Starting in GitLab 13.6 AMAU for this metric takes into consideration all repository types.
• Insight - GMAU has increased avg of 7% MoM in FY22Q1 (against goal of 3%) compared to 3% MoM in FY20Q4.
• Insight - Paid GMAU has increased avg of 5% MoM in FY22Q1 (against goal of 4%) compared to 2% in FY20Q4.
• We continue to use this as the group's primary indicator. In order to align with our SaaS first and product depth direction, during FY22 we will also have an increased focus around performance as our secondary PI.

Implementation Status: Complete

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

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

URL(s)

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

Metric Name: action_monthly_active_users_ide_edit

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Okay

• Insight - Healthy growth, particularly in self managed, likely due to adoption of versions containing analytics and organic growth.
• Improvement - The Web IDE was updated in 13.9 to use Editor Lite which brings consistency to the underlying editors powering Snippets, Single-file Editor, and Web IDE as well as a moderate performance improvement.

Implementation Status: Complete

• Instrumentation of Static Site Editor and Wiki to roll up into GMAU completed in 13.7, waiting for data to be reflected in the charts.

Create:Ecosystem - GMAU - MAU of any integration

Monthly Unique Users of any GitLab integration.

SaaS/SM: Both

Target: TBD

Is Primary PI: true

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

Metric Name: TBD

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

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)

Enablement:Geo - Paid GMAU - Number of unique users utilizing a Geo secondary

Number of unique users utilizing a Geo secondary. This adoption metric helps us understand whether end users are actually seeing value in, and are using, geo secondaries.

SaaS/SM: Both

Target: TBD

Is Primary PI: true

URL(s)

• https://gitlab.com/groups/gitlab-org/-/epics/4660
• https://app.periscopedata.com/app/gitlab/500159/Enablement::Geo-Metrics

Metric Name: geo_nodes

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Attention

• We've enabled gathering usage data from Geo secondaries and have added git fetch metrics to the usage data. These metrics are not yet available; we are working on getting them plotted in Sisense. We also intend to add tracking for git push operations on a Geo secondary.
• GMAU is currently based on logging into the Secondary web interface. Git access is more common and we will begin tracking Git pulls in 13.11 with tracking for Git pushes planned as part of the Geo Usage Ping Epic. We also know that the UX of the secondary web interface is not good and we want to remove it, see Opportunity Canvas(internal). In order to assess the impact of our planned changes, having this (low) GMAU is really important. We've recently completed a PoC to make the secondary UI indistinguishable from the primary. Implementation work is in progress and can be tracked in the secondary mimicry epic.
• For Disaster Recovery we are measuring potential Geo users - the number of active licenses. In an ideal world, no regular user would ever need to rely on Geo because there is no disaster, but if one occurs everyone benefits. Based on the node number distribution ~60% of our customers use Geo mainly for DR. I think this is worth measuring because setting up Geo is always a conscious decision by the customer - it must be configured.
• We are working to add support for replicating all data types, so that Geo is on a solid foundation for both DR and Geo Replication.The Testing group added replication for Pipeline Artifacts in 13.11.
• In April 2020 (before the release of 12.10), we replicated ~56% of all data types (13 out of 23 in total) and verified ~22%. In 13.11 we replicate ~86% of all data types (25 out of 29 in total) and verify ~45%. In the last year GitLab released six new features that needed Geo support. We replicate a 100% of those new features and verify ~57%

Implementation Status: Instrumentation

• Geo is not available on GitLab.com today, so cannot use Snowplow or the .com database.

Lessons Learned (April):

• While there was a large jump from January to February, the number is still very low right now. Two potential reasons a) data is incomplete b) WebUI is read-only and requires a different UI. We are planning to change this, see this opportunity canvas and in-progress implementation work in the secondary mimicry epic.
• Steady month over month growth with 4.6% increase in new Geo customers from March to April.

Enablement:Global Search - Paid GMAU - The number of unique paid users per month

The number of unique active users and unique paid users interacting with either Basic Search or Advanced Search per month.

SaaS/SM: Both

Target: 10% month over month (SaaS and self-managed combined)

Is Primary PI: true

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• In March, Paid GMAU is up 6.2%. SaaS up 5.4%, Self-Manged up 11.6%
• The Self-Manged growth is due to the increased interest in code search of existing very larger customers

Implementation Status: Complete

• Data collected is incomplete for September and October 2020 and January 2021

Lessons Learned (April):

• The performance of the SaaS Latency has improved by 50%
• There is an increase in interest in code search across organizations. In the last 6 months, we have seen the request for “product to customer engagement” grow by 700%

Enablement:Infrastructure - Paid GMAU - Number of unique paid users that perform an action on GitLab.com

The sum of all monthly active users on gitlab.com that roll up to paid accounts in a 28 day rolling period.

SaaS/SM: SaaS

Target: 122000

Is Primary PI: true

Metric Name: COUNT_EVENTS_ACTIVE_USERS_LAST_28_DAYS_BY_PLAN_WAS_PAID

Chart (Sisense↗)

Health: Attention

• Paid Monthly Active Users on GitLab.com increased by 5.9% in March to 120K.
• Reset Q1 target after surpassing original target last month. Will set a Q2 target in next month's update.
• Insight - The increase was driven by several large expansion deals in the Premium tier.
• Improvement - To influence Paid GMAU, we have created a framework to guide SaaS-first thinking among PMs. Additionally, we are focusing on improving uptime and stability of GitLab.com via the InfraDev process, introducing error budgets with stage groups, and giving them metrics dashboards to better monitor their product areas. Additionally, we are tracking key features needed to achieve Enterprise Readiness on GitLab.com and extending our compliance posture on Gitlab.com.

Implementation Status: Complete

• Instrumentation complete.

Lessons Learned (April):

• Need to account for seasonal fluctuations into target projections.

Verify, Verify:CI - GMAU, SMAU - Unique users triggering pipelines

A rolling count of unique users triggering pipelines in the last 28 days because CI is the foundation for several downstream product areas, and improving SMAU for people using pipelines is important to help with discovery of these further features.

SaaS/SM: Both

Target: In FY22 Q1, we anticipate accomplishing this target of 1.1M unique users as predicted in our [tertiary chart](https://app.periscopedata.com/app/gitlab/798616/WIP-Linear-Predicted-Dashboard?widget=10611135).

Is Primary PI: true

Metric Name: ci_pipelines

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• Metric is instrumented for both SaaS and Self-managed

Implementation Status: Complete

• With ability to trigger a pipeline dependent on successful attempts to author CI yaml files, we have an issue to track number of new gitlab-ci.yml files created.
• We are also working to instrument other performance indicators for Verify:CI
• Updating dashboard to have both SM / SaaS and Paid / All breakouts
• Insight - Intial funnel analysis via verify-stage#48, shows there is a siginificant drop off from SCM users to user triggering pipelines. Within Verify, the percentage of users authoring a pipeline drops 88% from users triggering pipelines, and those who are using Paid Testing features drop 90% from the Pipeline Authoring Users. We are looking at what kind of user based metric of Runner is applicable, although, all portions of runner users would be included in SCM and Verify Users in this model.

Lessons Learned (April):

• Insight - In March 2021, we are have fully recovered from our dip in growth and our usage in both distributions is increasing. We are 20,000 users short of our FY22-Q1 target, which we can expect to accrue with organic growth in self-managed alone. SaaS grew 13K (4.2K users are Paid) and Self-managed grew 47K (12K are Paid).
• Insight - We are working with Data team via data#8400 to instrument more granular analysis of Verify MAU on .com.
• Insight - We are seeing an increase in expanding instances (by 5%), while shrinking instances are decreasing (by 9%) indicating our self-managed instances are growing.
• Improvement - We are are continuing to invest heavily in optimizing the performance of database queries in CI pipelines via gitlab&5434 and the mitigation of pipeline abuse via [gitlab&5583]. We have proposed adding a CI Scaling category to navigate these challenges of SaaS availabiity and performance. Both of these efforts have been prioritized over the investment in usability of Artifacts and Variables, which were the 1H FY22 direction.

Verify:Pipeline Authoring - GMAU - Number of unique users interacting with gitlab-ci.yml file

Count the number of users that are pushing MRs to gitlab-ci.yml files. Since we'd like to count the on-going usage of our users with pipelines.

Funnel Description: Handbook Link

SaaS/SM: Both

Target: The target for FY22-Q1 is 150,000 unique users interacting with the gitlab-ci.yml file on SaaS.

Is Primary PI: true

Metric Name: redis_hll_counters.pipeline_authoring.o_pipeline_authoring_unique_users_committing_ciconfigfile_monthly

Chart (Sisense↗)

Health: Okay

• Metric is instrumented for both SaaS and Self-managed

Implementation Status: Implementation

• Insight - Instrumentation for .com is complete
• Insight - We started receiving self managed data

Lessons Learned (April):

• Insight - We started to measure pipeline authoring GMAU on both .com and self managed to achieve a baseline and measure up to 125,000 unique users in March 2021.
• Improvement - Improvements that will continue to drive this metric, will include the empty state for pipeline editor and a pipeline drawer , which will allow new users to easily start using pipeline editor, In addition, we plan to add support for Branch selector in the pipeline editor to allow users to work with the pipeline editor from any non-master branch.

Verify:Testing - Paid GMAU - Count of active paid testing feature users

A rolling count of unique users who have interacted with a paid testing feature in the last 28 days.

Funnel Description: Handbook Link

SaaS/SM: Both

Target: We are targeting 17,500 unique paid testing users by end of FY22-Q1.

Is Primary PI: true

Metric Name: NA

Chart (Sisense↗)

Health: Unknown

• The aggregate metric is implemented and in the Dashboard.

Implementation Status: Complete

• Target has been added to the dashboard and handbook page.
• We are continuing to add to the aggregate metric as new functionality is added.

Lessons Learned (April):

• Insights - We learned that the usage ping was double counting self-managed usage ping. We to reset the target to be more realistic based on usage patterns.
• Insights - In March 2021, we had about 2K users on self-managed and 1.6K users on SaaS.
• Improvements - The first iteration of MR Diff decoration with Code Quality data is scheduled for 13.11 along with tracking which we think will be a popular and engaging feature.
• Improvements - Several MR Widget UX cleanups shipped in 13.10 for Core and Premium widgets. We are interested to see if this corresponds with an improvement in engagement which we will monitor for on gitlab.com.
• Initial funnel analysis via April 2021 prep issue for Code Quality shows we have some gaps in the funnel. This is because we have been focused on PGMAU metrics, the next to last step in the funnel. Getting tracking on engagement with the MR Widget and the upcoming MR Diff view should help fill in the gaps and provide a good view of the discoverability of these features.

Package:Package - SMAU, GMAU - Count of users publishing packages

The maximum distinct count of users who published a package to the Package Registry. In the future, this value will the distinct count of users across all Package AMAUs.

Funnel Description: Handbook Link

SaaS/SM: Both

Target: The target for FY22-Q1 is 40,000 unique users publishing packages across SaaS and self-managed combined.

Is Primary PI: true

Metric Name: user_packages_total_unique_counts_monthly

Chart (Sisense↗)

Health: Okay

• Improvements - In 14.0 we will evaluate rolling out weekly metrics, pending scalability and performance.

Implementation Status: Complete

Lessons Learned (April):

• Improvements - In 13.11, we shipped several key issues for Composer and Conan. Although these are the least frequently used formats, both had a large estimated lift in March. We hope that addressing these popular issues will translate into increased adoption in April.
• Improvements - In 13.11, we shipped a popular request to add support for SemVer to generic packages. Although it's early to tell, on GitLab.com we went from 3k events per day to 6k per day since the feature launched.
• Improvements - In 13.12, we are primarily focused on scalabilitiy, performance, and usability. However we have a stretch goal to add a group-level PyPI endpoint. When we added a similar feature for NuGet, we saw a 60% lift in activity.

Release:Release - SMAU - Count of users triggering deployments using GitLab

A rolling count of unique users triggering deployments with Gitlab in the last 28 days.

Funnel Description: Handbook Link

SaaS/SM: Both

Target: The target for FY22-Q1 is 453,000 for unique users triggering deployments, and 213,000 for paid unique users triggering deployments.

Is Primary PI: true

URL(s)

• https://app.periscopedata.com/app/gitlab/777879/Release-Stage-Dashboard?widget=10833391&udv=0

Metric Name: deployments

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Tertiary Chart (Sisense↗)

Health: Okay

• Insight - We have reached our yearly target for deployments for both SMAU and paid SMAU. There was a 9% increase in deployments from last month.
• Improvements - Release has recently shipped some of the DORA4 metrics and specifically deployment frequency which gives the user insights into their deployment efficiency and should encourage them to increase deployments.
• Improvements - In the next few milestones, we will add in-product guidance for users that have pipelines that are not triggering deployments.

Implementation Status: Complete

• We are currently tracking this data for GitLab.com via Snowplow and as a usage ping for self-managed instances.
• We need to Expand Revenue Attribution to Release SMAU
• Updating dashboard to have Paid / All breakouts

Configure:Configure - SMAU, GMAU - MAU of GitLab Managed Terraform State

Monthly active users of GitLab Managed Terraform State

Funnel Description: Handbook Link

SaaS/SM: Both

Target: The target for FY22-Q1 is 5000 monthly active users of GitLab Managed Terraform State

Is Primary PI: true

URL(s)

• https://app.periscopedata.com/app/gitlab/511813/Configure-team-business-metrics
• https://app.periscopedata.com/app/gitlab/677628/Infrastructure-as-Code

Metric Name: redis_hll_counters.terraform.p_terraform_state_api_unique_users_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• Improvement - I'm working with Mathieu on a simple way to add targets to our charts, when targets are defined in the PI yaml.

Implementation Status: Complete

• We have MAU based metrics.

Lessons Learned (April):

• Insight - As we were moving from generic adoption metrics to MAU, I've expected higher MAU numbers. I'm still looking into it.
• Blocker - We are short on resources, and I'm currently prioritising other areas that might have only indirect effects on the SMAU.

Monitor:Monitor - SMAU, GMAU - Unique users that interact with Alerts and Incidents

Unique users that interact with alerts or incidents. (This metric represents the GMAU for the Monitor:Monitor group as well as the SMAU for the Monitor stage. It is based on usage of the Incident Management category which is the only category in the group or stage that is being actively developed. The definition for Monitor SMAU will be seperated from Monitor:Monitor GMAU when we are able to expand the definition to include usage of the other categories. That work is currently not a priority.)

Funnel Description: Handbook Link

SaaS/SM: Both

Target: The target for FY22-Q1 is 15,000 estimated total unique users that interact with alerts and incidents.

Is Primary PI: true

URL(s)

• https://app.periscopedata.com/app/gitlab/769975/Monitor-Stage-Dashboard

Metric Name: incident_management_total_unique_counts_monthly

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• We exceeded our target of FY22-Q1 target of 15,000 in 2021-03!

Implementation Status: Complete

• Instrumentation complete - issue.

Lessons Learned (April):

• March saw a 8% increase over February
• Looking over the past 2 quarters, we saw on average a 6% growth month over month
• We released the on-call schedule management in 13.11. Additional improvements are planned in 13.12. We also need to add instrumentation to schedule management
• Improvements - We are staring work on Escalation Policies. Escalation policies are a required part of object relationship in Incident Management. This feature will enable us to add paging

Secure:Static Analysis - GMAU - Users running Static Analysis jobs

The highest of the number of unique users who have run SAST or Secret Detection jobs.

SaaS/SM: Both

Target: Progressively increasing month-over-month, >10%

Is Primary PI: true

URL(s)

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

Metric Name: user_sast_jobs, user_secret_detection_jobs

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• On track, continued healthy growth of static analysis usage.

Implementation Status: Complete

• Can't currently differentiate between free OSS Ultimate users and paid Ultimate users.

Lessons Learned (April):

• Tracking upgrades is really difficult to today, but we're starting to get directional data to better understand how many and what vectors upgrades from SAST come from.

Focus This Month (May):

• Explore upgrade paths for non-ultimate customers discovering the value of ultimate and upgrading. We're working with the verify team to explore ways to encourage SAST usage and hopefully better track upgrades.
• Moving forward we are focused strongly on data accuracy and reduction of false positives. We have a new exploration to validate a new vulnerability tracking improvement from Vulnerability Research which could materially reduce false positives. This approach is appearing to work out and produce more accurate tracking. This also opens a new metrics problem that we need a way to track accuracy with real-world data. We intend to measure the improvements of this change via the new vulnerabilities data in Sisence to ensure this change results in material positive impact before rolling it out. This feature has gotten heavily delayed due to rapid action DB work and upstream bugs with vulnerability reports that our group does not directly control.
• To increase efficiency and reduce maintenance costs of our 10 linter analyzers we are transitioning to SemGrep for many of our linter analyzers. If successful we will reduce ~10 open source analyzers into 1 while also improving the detection rules and proving a more consistent rule management experience across these analyzers, this will be materially impactful as we seek to build our proprietary SAST engine on top of these results. This effort is on track and we will be GAing the Semgrep analyzer in 13.12. Experimental availibility is [generating a good amount of usage(https://app.periscopedata.com/app/gitlab/718481/Static-Analysis-Metrics—@tmccaslin?widget=11703484&udv=1090066).

Secure:Dynamic Analysis - GMAU - Users running DAST

Number of unique users who have run one or more DAST jobs.

SaaS/SM: Both

Target: Progressively increasing month-over-month, >10% per-month

Is Primary PI: true

URL(s)

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

Metric Name: user_dast_jobs

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• On track, usage continues to trend upwards.

Implementation Status: Complete

• Can't currently differentiate between free OSS Gold/Ultimate users and paid Gold/Ultimate users.

Lessons Learned (April):

• Reported self-managed usage jumped significantly in April. The reason for this is unknown and could be due to usage ping being enabled on more instances, new customers, or more awareness of DAST capabilities. Investigation into the sudden increase is on-going.
• Customers have stopped using DAST in the past because of the huge number of vulnerabilities produced in the dashboard, vulnerability aggregation is the first step in addressing this.

Focus This Month (May):

• Aggregating noisy vulnerabilities to stop DAST from overwhelming the Vulnerability Report (https://gitlab.com/gitlab-org/gitlab/-/issues/254043)
• Add more options to Site profile (https://gitlab.com/groups/gitlab-org/-/epics/3771)

Secure:Composition Analysis - GMAU - Users running any SCA scanners

The highest of the number of unique users who have run one or more Dependency Scanning jobs, or number of unique users who have run one or more License Scanning jobs.

SaaS/SM: Both

Target: 2% higher than current month (SaaS and self-managed combined) for All and Paid

Is Primary PI: true

URL(s)

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

Metric Name: user_license_management_jobs, user_dependency_scanning_jobs

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• On track

Implementation Status: Complete

• 13.11 and 13.12 team was dedicated to rapid action, no PI work in place. Currently our data is MVC and a lagging indicator, trends are accurate but due to extrapolation of self-hosted, low opt-in of self-hosted, overall missing granularity, and 28 day cycles actual numbers are imprecise, in addition I believe there was another data event this month resulting in not being able to view SaaS, but using my own data charts as well as this charts self hosted data, it allows high level trending comparisons.

Lessons Learned (April):

• Nothing through use of xMAU Metrics.

Focus This Month (May):

• Handle the rapid action event and then focus on Software Composition Analysis removals and deprecations for 14.0. We hope there is then time for Consistency in default behaviour of AST scanners and jobs. After which we will resume to our usual, nothing directly related to these lagging indicators, but continue work on Dependency Scanning to complete however auto remediation is still blocked by a token issue.

Secure:Fuzz Testing - GMAU - Users running fuzz testing

The highest of the number of unique users who have run one or more Fuzz Testing jobs.

SaaS/SM: Both

Target: Progressively increasing month-over-month, >10% per-month

Is Primary PI: true

URL(s)

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

Metric Name: user_coverage_fuzzing_jobs, user_api_fuzzing_jobs, user_api_fuzzing_dnd_jobs on self-managed, (options like '%gitlab-cov-fuzz%' OR SECURE_CI_JOB_TYPE='api_fuzzing') on .com

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Attention

• We have a good growth rate and need more users to use fuzz testing.

Implementation Status: Definition

• Can't currently differentiate between free OSS Gold/Ultimate users and paid Gold/Ultimate users.

Lessons Learned (April):

• Data integrity issues with processing usage ping means we aren't confident in this month's data or its relationship to previous trends.

Focus This Month (May):

• Corpus management for coverage-guided fuzz testing (https://gitlab.com/groups/gitlab-org/-/epics/2915)
• Add support for AFL fuzz targets (https://gitlab.com/gitlab-org/gitlab/-/issues/321075)
• Improve our documentation based on known pain points (https://gitlab.com/gitlab-org/ux-research/-/issues/1273)
• Continue analysis of new data to understand how often and how many users successfully use fuzz testing.
• Monitor inflow of new data and update performance indicator charts as needed.
• Any changes needed to restore or update reporting as a result of the outages.

Secure:Threat Insights - GMAU - Users interacting with Secure UI

Number of unique sessions viewing a security dashboard, pipeline security report, or expanding MR security report. Same as Paid until OSS projects can be separated.

SaaS/SM: SaaS

Target: Progressively increasing month-over-month, >2% per-month

Is Primary PI: true

URL(s)

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

Metric Name: n/a

Chart (Sisense↗)

Health: Attention

• GMAU currently showing ~6% dip, reversing 6-month trend of gains. May be related to current days-long lag in metrics data refresh.

Implementation Status: Definition

• Collection is complete for .com only
• Snowplow data is session only, not unique users
• Can't currently differentiate between free OSS Gold/Ultimate users and paid Gold/Ultimate users.
• Cannot separate out GitLab employee usage from customers

Lessons Learned (April):

• Even if data for April is incomplete, overall page views are up at least 7%, pointing to continued rise in individual user engagement
• Increase was smaller but Project Vulnerability Reports and MR security widget usage increased from March
• Pipeline security views are down while MR views are up, could indicate users who discover the Pipeline view are not getting distinct value

Focus This Month (May):

• Continue executing on roadmap based on input from other sensing mechanisms
• Focus on key technical debt around performance, scalability, and maintainability
• Evaluate main drivers of Error Budget overages and work to address

Protect:Container Security - SMAU, GMAU - Users running Container Scanning or interacting with Protect UI

The number of users who have run a container scanning job or interacted with the Protect UI in the last 28 days of the month.

SaaS/SM: Both

Target: Progressively increasing month-over-month, >2%

Is Primary PI: true

Metric Name: user_container_scanning_jobs

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Okay

• Usage growth is rapidly accelerating. It is estimated that the uplift is largely due to closed Gold/Ultimate deals in 2020 that are now adopting Secure.
• The shift from Clair to Trivy has generated a lot of customer interest. Although we are unable to slice the data by the type of scanning engine used, some of this uplift may be due to customers trying out the new Trivy scanning engine.

Implementation Status: Complete

• Limitations in data (see SCA limitations above)
• Although we have released the Alert Dashboard, we do not yet have a good way of tracking monthly active users for this area. Instrumentation is expected to be complex (1-2 months of one developer's time) and usage is expected to remain low until additional alert times are added to the dashboard. Currently instrumenting these metrics is a low priority.

Lessons Learned (April):

• The switch from Clair to Trivy has allowed us to close 20+ outstanding customer issues and bugs. Adoption is expected to increase significantly after the 14.0 release.

Focus This Month (May):

• Project-level DAST Scan Schedule Policies (pipeline) (https://gitlab.com/groups/gitlab-org/-/epics/5329) is available behind a feature flag
• Project-level DAST Scan Schedule Policies (scheduled scans) (https://gitlab.com/groups/gitlab-org/-/epics/5360) is being worked on for a May release
• Replacing Clair with Trivy (https://gitlab.com/groups/gitlab-org/-/epics/5398) will be the default beginning in the 14.0 release and will set the foundation for us to be able to scan containers in production environments

Other Stage PIs Details

Enablement - Section PPI, Stage PPI - Median End User Page Load Time

Median end user page performance collected by Real User Monitoring. This metric captures how well we are doing in serving our primary customers, our end users, by measuring their end user experience.

SaaS/SM: Both

Target: 1.3

Is Primary PI: true

Metric Name: performanceTiming

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Attention

• We seem to have had a performance regression, which is showing up in our page load times. This is corroborated by our Sitespeed testing, with 13% fewer pages <2.5s and average LCP growing by 0.5s. We need to investigate. This does not seem related to our stability challenges recently.

Implementation Status: Complete

• We are still working to improve our per-geo views.
• Established a target of 1.3s for median page load time. The p90 and p95 consistently track the trends in median, and so we should be able to just pick one. Rationale for 1.3s is that we attained that once back in Jan/Feb, however have regressed since. We should attempt to reverse the trend we've seen in the last few months.

Lessons Learned (April):

• We did not have a front-end performance OKR this past quarter, and saw regressions on both sitespeed LCP as well as RUM page load timings. This seems to suggest that we need to improve our tooling and awareness of these metrics so we no longer need OKR's to maintain desired performance levels.

Other Group PIs Details

Enablement:Distribution - Group PPI - Percentage of installations on the 3 most recent versions of GitLab

Of the total number of self-managed installs, what percentage are on one of the three most recent versions.

SaaS/SM: Both

Target: 40%

Is Primary PI: true

URL(s)

• https://app.periscopedata.com/app/gitlab/441909/Active-Instances?widget=10278985&udv=1102166
• https://app.periscopedata.com/app/gitlab/441909/Active-Instances?widget=10279895&udv=1102166

Metric Name: versions_behind_latest

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Attention

• A target of 40% has been set. 40% is the upgrade rate that was reached in early 2019.
• Insights - Age seems to have leveled off, % on latest 3 versions begins to climb after low January numbers.
• Positive month across the board, need to analyze possible reasons to keep momentum going.

Implementation Status: Complete

• Primary PPI is complete, and target is set.

Lessons Learned (April):

• This month appears to have steered away from the expected result slightly and the trend potentially is beginning to level off for median age of version for all versions and license plans. We do not know what has caused this change in trend. This will be investigated to see how we can use these results to beginning a downward trend.
• There was a slight upward trend for all install types for percentage on the latest 3 versions. The helm install is still well above the target of 40, and the other install types are beginning to approach 40. Perhaps this bottom of the dip was due to low upgrade rate around/after the holiday season in January. A study was also conducted on ease of upgrading for users. This in conjunction with analysis of causes for the trend will be used for actionable issues to drive positive metrics directions.
• We are in the process of analyzing the feedback from a study related to the ease of install and upgrade now. We have also recieved some results from this study, which was focused on the choice of CE vs EE and respondants left some comments related to openess to receive more notifications about upgrading. We will conduct more research on the best way to notify users of upgrading and how to automate the upgrade process. The initial issue can be found here
• Work has begun on better highlighting when instances are out of date to administrators. This will impact results once it has been completed, estimated for next milestone.

Enablement:Memory - Group PPI - Memory Consumed

Average memory consumed by all invididual GitLab processes

SaaS/SM: Both

Target: 1.5GB

Is Primary PI: true

Metric Name: topology.nodes[0].node_services

Chart (Sisense↗)

Health: Attention

• Memory consumption has stabilized in versions 13.7-13.10 but increased slightly in 13.11.
• We are currently working on reducing the memory consumption for Puma and Sidekiq.
• To further reduce memory consumption, we are planning to work on splitting the application into functional parts to ensure that only needed code is loaded and on reducing the memory consumption for Puma and Sidekiq endpoints.

Implementation Status: Complete

• Working to adjust chart to include how many of each process are started by default to better represent a default configuration.
• A bug in the plot displays the versions out of order (13.11 next to 13.1). Investigating a fix.

Enablement:Database - Group PPI - Database Query Apdex (100ms target, 250ms tolerable)

Database query Apdex, with 100ms the target and 250ms tolerable. This measures the ratio of queries which complete within the satisfactory time, informing how well the database is scaling and performing.

SaaS/SM: Both

Target: 0.99

Is Primary PI: true

URL(s)

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

Metric Name: query_apdex_weekly_average

Chart (Sisense↗)

Secondary Chart (Sisense↗)

Health: Attention

• The query Apdex has decreased in all charts after the release of 13.10, including the weekly one, which has a pretty constant number of instances reporting stats. No similar trend on the GitLab.com charts, nor any other clear signal indicating what may be affecting the Apdex. We'll monitor closely and will revisit this in ~2 weeks.
• We expect the updates performed in the scope of Research Database queries for performance and frequency to further improve the ratio of queries which complete within 250ms and lower the variance of the Apdex even further.
• We expect our work on automated database migration testing to indirectly improve the database performance by minimising the number of database related incidents during deployments.

Implementation Status: Complete

• The PPI has been instrumented in 13.4.

Lessons Learned (April):

• Apdex on GitLab.com exceeds our group PPI (see 100ms - Tolerable 250ms and 50ms - Tolerable 100ms) but reflects with sharp drops the production incidents that related to the database.
• The vast majority of GitLab 13.9 instances use PostgreSQL 12.5. Only 2.4% of EE instances are still in PostgreSQL 11.x.

Verify:Runner - Other - Total downloads of runner binaries and docker images per month

Count of downloads of runner binaries grouped by platform, gitlab-runner and gitlab-runner helper container images. Measuring runner binaries' downloads will provide insight into whether we are making the right investments in core runner features and capabilities by platform (operating system and computing architecture). The assumption is that if self-managed users continue to maintain and upgrade their GitLab Runner build infrastructure, this may suggest continued long-term use of GitLab as their DevOps platform.

Funnel Description: Handbook Link

SaaS/SM: SM

Target: TBD

Is Primary PI: true

Metric Name: NA

Health: Unknown

• Not instrumented

Implementation Status: Definition

• We need to start collecting the AWS S3 bucket metrics and integrate them into the data warehouse. Issue for tracking is in the Infra Project pending scheduling.

Lessons Learned (April):

• Insight - Total downloads of 17M of the GitLab-Runner docker image in March 2021 reflects a 3% increase from Feb 2021. The download count of the runner docker image daily remains steady, with a daily average of 852K in March and 879K to date in April. Our theory is that this is one positive indicator of continued growth in the use of GitLab CI for self-managed.

Other PI Pages

• Performance Indicator Maturity Table
• Engineering Function Performance Indicators
  • Customer Support Department Performance Indicators
  • Development Department Performance Indicators
    • Dev Sub-Department Performance Indicators
    • Ops Sub-Department Performance Indicators
    • Secure Sub-Department Performance Indicators
    • Protect Sub-Department Performance Indicators
    • Growth Sub-Department Performance Indicators
    • Enablement Sub-Department Performance Indicators
  • 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
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.