The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
We provide intuitive instrumentation tools that capture essential product usage data throughout the product lifecycle, enabling evidence-based decisions with minimal friction. These tools help teams derive actionable insights on feature usage to build better features and increase adoption.
Through collaboration across Product, Engineering, Customer Success, and Data teams, we're building a culture where customer usage data drives growth. This directly supports customer-focused innovation (Objective 3) by providing visibility into actual feature usage, helping teams identify pain points and prioritize development based on user behavior rather than assumptions. Our instrumentation creates a continuous feedback loop between customer usage and product development.
The key thesis of our group is that providing more visibility into how GitLab is used allows us to make better decisions which lead to better business outcomes for ourselves and our customers. In order to build the best DevOps product we can and provide the most value for our customers, we need to collect and analyze usage data across the entire platform to investigate trends, patterns, and opportunities. Insights generated from instrumentation enable GitLab to identify the best place to invest time and resources, which categories to push to maturity faster, where our UI experience can be improved, and how product changes effect the business.
We understand that usage tracking is a sensitive subject, and we respect and acknowledge our customers' concerns around what we track, how we track it, and what we use it for. We will always be transparent about what we track and how we track it. In line with our company's value of transparency, and our commitment to individual user privacy, our tracking source code and documentation will always be public.
As we build solutions for GitLab and our users to instrument their apps, aspects we will focus on are:
| Top Goals | Epic | Current Status | FY26 Target | Mid Term Target |
|---|---|---|---|---|
| Broaden instrumentation support/Cover all use cases: teams within GitLab are able to instrument using internal events irrespective of their use case | https://gitlab.com/groups/gitlab-org/-/epics/18240 | 🔵 Implemented | 🟢 Adopted | ❤️ Optimized |
| Data quality: Ensure the accuracy and reliability of the data we collect for trusted decision-making. Adhering to legal and privacy policies to ensure compliance and protect user privacy | https://gitlab.com/groups/gitlab-org/-/epics/18243 | 🟠 In Progress | 🔵 Implemented | 🟢 Adopted |
| Deepen Instrumentation adoption/Instrumentation coverage: Ensure all our categories have instrumentation | https://gitlab.com/groups/gitlab-org/analytics-section/analytics-instrumentation/-/epics/6 | 🟠 In Progress | 🟡 Under Review | 🟢 Adopted |
| Easy instrumentation: Providing infrastructure and tools that enable teams to efficiently instrument with minimal support | https://gitlab.com/groups/gitlab-org/-/epics/10700 | 🟢 Adopted | 🟢 Adopted | ❤️ Optimized |
| Data to Insights: Ensure the data we collect can be effectively transformed into actionable insights by our internal teams and customers | 🔵 Implemented | 🟢 Adopted | ❤️ Optimized |
In this GitLab Unfiltered video Niko is talking about the groups's approach to Analytics Instrumentation tools improvements and evolution
A key aspect of aligning on our direction is understanding who we are building for. This allows us to best understand the problems they may have and the context that they will be approaching our offerings with.
Product groups within GitLab consist of a Product Manager, Engineering Manager, engineers, and other stable counterparts. These groups implement new features in GitLab and want to understand how users interact with those features. These teams have understanding of how the GitLab code base works as it relates to their features, but not necessarily how the instrumentation APIs and architecture work. They are not necessarily aware of the end-to-end story about how information flows from when a user clicks a button to a result being shown in Sisense or a report.
These product groups are our primary customer that we are serving and developing solutions for.
Consider reading more about Parker, our Product Manager persona.
Product Managers within these groups will have an understanding of how their group's features work from a user perspective, the problem those features solve, and what sorts of actions result in a user "succeeding" at the job to be done, and have growth and usage goals for that feature. They will be able to describe a user journey and key points that should be instrumented along that journey to measure success or need for improvement. They will not necessarily understand what the underlying code for the feature looks like or how all the technology pieces fit together. They need to be able to easily understand which kinds of tracking are available and how they are differentiated to be able to understand the resulting data. If they find it difficult to add the instrumentation they want, they will instead rely solely on qualitiative analysis, such as direct user conversations, rather than a blend of both qualititative and quantitative analysis.
Consider reading more about Sasha, our Software Developer persona.
Engineers within these groups will have an understanding of how GitLab is built and run but likely are not familiar with the product instrumentation architecture nor APIs. They heavily rely on documentation, examples, and previous MRs to add instrumentation that their PM requests. When they are unable to self-serve, they will ask the Analytics Instrumentation group for help or give up.
This persona relies on what we provide to them, which means it is critical for us to keep examples up to date and have clear guidance around deprecated APIs so that engineers use our newer, preferred APIs instead of older ones.
The GitLab data program is responsible for surfacing data and data-driven insights to the business. They have expertise in building data pipelines, models, and managing data once collected. They are not necessarily familiar with the GitLab code base and rely on product groups to add instrumentation for new metrics or update existing ones. They rely on Analytics Instrumentation to effectively collect and send data to Snowflake, which is their main interface with the data.
Customer Success team members play a crucial role in partnering with clients to ensure they realize the full value of GitLab's offerings. Although they are experts in customer engagement and optimizing the GitLab experience, they may not have deep knowledge of the product’s instrumentation details. They rely on the Analytics Instrumentation group to help them easily find the relevant metrics and data for features and capabilities and to provide guidance and support on implementing missing instrumentation where needed. Effective support hinges on our ability to assist them in accessing the metrics they need and offering clear, actionable guidance for incorporating necessary instrumentation.
External GitLab users are a broad category of individuals with different needs and who have different skill sets. These users may be interested in reading about what data we collect and how to interact with it. In the future, external users will use the application instrumentation SDKs our group provides to be able to instrument their own apps.
External users rely on our handbook pages and sites like metrics.gitlab.com to understand what data is collected from their GitLab use, how to view it, and how to interact with it. If they are unable to get clear answers to their questions, they become frustrated. In that case, they may reach out to their account manager to help them, post on a forum, or stop using GitLab.
External users will use the application instrumentation SDKs we provide to instrument their apps. These teams will be similar to our own product groups within GitLab. That is, PMs will understand user journeys about their features, developers will understand how their own app is built, but neither will be familiar with our instrumentation SDKs. They will rely heavily on our documentation and examples or else they will give up and do something else.
It is a valid question to ask why analytics instrumentation can not be automated to a high extent by automatically tracking API hits based on the URL or button clicks in the UI. While this would be the most usable solution, as it does not require any manual instrumentation, it is neither scalable nor manageable or adaptable:
Instrumentation should be easy as possible while still clearly documenting the intent to track a specific behavior and getting out of the way of feature changes.
For more information on Analytics Instrumentation, you can checkout our Analytics Instrumentation Guide which details a high-level overview of how we make data usable, the Collection Frameworks we leverage, our Metrics Dictionary, and much more!
Analytics Instrumentation provides the necessary frameworks, tooling, and expertise to help us build a better GitLab. Naturally we sit in the middle of many projects, initiatives and OKRs at GitLab. In order to provide clarity and realistic expectations to our stakeholders and customers we practice relentless prioritization (per Product Principle #6), identifying what is above the line, what is below, and what is unfunded and not possible for us to action on in a given timeline.
This table lists recurring activities that are part of working groups and cross-functional initiatives.
| Activity | Cadence | Type | Teams Involved |
|---|---|---|---|
| GTM Product Usage Data Working Group | Weekly | Sync | Fulfillment PMs, Analytics Instrumentation, Data, Customer Success, Sales |
| Data & Analytics Program for R&D Teams | Every 2 Weeks | Sync | Fulfillment PMs, Analytics Instrumentation, Growth, Data |
| Product ARR Drivers Sync | Monthly | Sync | Customer Success, Sales, Product Leadership |
| ClickHouse Datastore | Weekly | Sync | Multiple |
| Resource | Description |
|---|---|
| Internal Analytics Docs | An implementation guide for Usage Ping |
| Metrics Dictionary | A SSoT for all collected metrics from Usage Ping |
| Privacy Policy | Our privacy policy outlining what data we collect and how we handle it |
| Implementing Product Performance Indicators | The workflow for putting product performance indicators in place |
| Analytics Instrumentation Development Process | The development process for the Analytics Instrumentation groups |
| Project resposibilities | List of several projects that our group is the DRI for |
| Incident Reporting | Analytics instrumentation specific incident reporting process |
| Technical Roadmap FY25/FY26 | The technical roadmap for Analytics instrumentation. |