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.
GitLab's 3-year strategy centers on empowering our customers by driving use case adoption. By offering intuitive and effective instrumentation tools that support the entire lifecycle, we empower teams to efficiently capture the data they need for informed, evidence-based decisions with minimal external support. This data-driven approach not only helps teams optimize their features but also provides both customers and internal teams with valuable insights into feature adoption, which is essential for driving broader use case adoption.
We will leverage our deep expertise and technical foundation to help users easily instrument their applications, analyze data, and optimize their experience. Through strong collaboration across GitLab—Product, Engineering, CSMs, Data and external customers—we are building a data-driven, product-led culture that fosters growth and success for both our customers and GitLab.
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 | Current Status | 1 Year Target | Mid Term Target | Reasoning |
|---|---|---|---|---|
| Easy instrumentation: Providing infrastructure and tools that enable teams to efficiently instrument with minimal support | 🟢 Adopted | 🟢 Adopted | ❤️ Optimized | In the past few milestones, we've made significant improvements to simplify instrumentation. With internal events, teams no longer have to worry about the underlying complexity of different systems. With the CLI generator, they no longer have to manually create event and metric definition files, and with the metrics dictionary, they can more easily find the metrics they need. These and many other improvements the team has worked on have made instrumentation much easier, and our ease of instrumentation scores have improved from 'hard' to 'very easy'. While we’ll focus on low-hanging fruits to improve ease of instrumentation this year, major improvements will be taken on the long term so we can prioritize moving to the green category for our other areas. You can track our work in this area here |
| Cover all use cases | 🔵 Implemented | 🟢 Adopted | ❤️ Optimized | We now support instrumenattion outside of the GitLab domain in applications such as the AI gatewayand Switchboard. Our goal is to ensure teams can instrument features consistently and easily, regardless of their specific use case or platform. You can track our work here |
| Instrumentation coverage: Ensure all our categories have instrumentation | 🟠 In Progress | 🟡 Under Review | 🟢 Adopted | Ensuring complete instrumentation across all features is critical for maximizing data quality and enabling comprehensive insights. We'll continue to work on ensuring instrumentation coverage on our lighthouse metrics and then move to ensuring all our categories have instrumentation |
| 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 | 🟠 In Progress | 🟢 Adopted | 🔵 Implemented | Ensuring data accuracy and reliability is critical for effective decision-making. While we've made progress, ongoing improvements are needed to ensure data integrity at scale. You can track our work here |
| Data to Insights: Ensure the data we collect can be effectively transformed into actionable insights by our internal teams and customers | 🔵 Implemented | 🟢 Adopted | ❤️ Optimized | The data we collect is compatible with our downstream systems, maintained by the data team, and can be accessed through Tableau and Snowflake. Self-managed customers can more easily access aggregated metrics via the REST API. We aim to enable both customers and internal teams to access usage data more effectively and easily, ensuring they can derive value from it. We will actively support product data unification efforts to ensure internal teams and customers can more easily derive insights from the data we collect. |
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. |