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.
Our vision is to continue to extend DevOps across its most painful gap - measuring user value. The Analytics Section closes the DevOps loop. It is not enough to deploy an app and hope for the best. It is critical to understand and explore the data and signals that GitLab provides to make the best, insight-based decisions. We will do this by providing a comprehensive solution to gather and interact with data for both our users and internal teams.
This will increase the value of GitLab as a platform since users will have a unified experience. They will know where to find definitive locations for the data they are interested in and have a single place to interact with it. It will also make our organization more efficient since teams can focus on building lovable features rather than re-building how we collect, store, and present data. We will create new product experiences where we can combine data from different features for user use cases that we uncover that would have previously been difficult to serve.
We heard a collection of common questions when talking with users that helped us create this vision.
Some of these were:
We previously were primarily focused on helping customers measure the usage and performance of their deployed apps. This was done with our Product Analytics and Observability offerings. What we learned is that many customers either did not prioritize this highly or had solutions in place. What they do not have, and where our opportunity lies, is understanding how their teams are using GitLab or how to combine all the different data signals we provide today. We will use the technology we built for those use cases and adapt it to focus on our GitLab platform use cases instead. We will continue to listen to customers and engage with those that are interested in measuring their deployed apps and consider if and when to re-focus on deployed apps.
The Analytics Section is comprised of a single Stage: the Monitor stage. This stage has two groups:
The Platform Insights group focuses on allowing users to analyze product data to uncover insights about how their teams are using GitLab and their apps are being used. This is done through preconfigured dashboard and reports as well as enabling users to build their own dashboards and reports.
The Analytics Instrumentation group focuses on empowering both internal and external users to send usage data to GitLab by providing SDKs and a stable reporting platform. Internally, this means tools like Service Ping and Snowplow as well as providing support to the groups that use them. External users will use the SDK that this group publishes to instrument their own apps. This group focuses on data unification efforts across the platform as part of the product usage data efforts.
Despite the name, the Analytics section doesn't encompass all analytics capabilities in GitLab. Categories like Value Stream Analytics and capabilities like Issue Analytics, Release Metrics, or CI/CD analytics analytics those are not within the scope of the Analytics section.
We know that many groups and teams within GitLab as well as users rely on data to understand how they are using GitLab. There are multiple approaches to produce and consume data currently, which introduces confusion and friction. Our long-term vision is to unify these so that there is a Single Source of Truth for both how to record data about how GitLab is being used as well as how to consume it. There are additional details on this vision at our cross-stage directional vision page.
The primary personas we address, in priority order, are:
Some nuance can be added to our personas and how we approach them. Nearly all analytics questions, workflows, funnels, or any metrics gathering will require technical work to add instrumentation, test, and deploy it. This is the reason we are focusing on Sasha as our primary persona before Parker. We are addressing Sasha in the context that they are supporting Analytics efforts for their team. This means they are interested in how to do tasks related to adding instrumentation code, deploying it, and debugging it in support of analytics-related questions and projects. This is a more focused version of the Sasha overall persona.
Both of these personas exist on our users' teams and they also exist on our own GitLab team. Our internal members share many of the same use cases and pain points as our external users. We keep this in mind when developing features and capabilities and try to dogfood as much as possible. We also need to remain mindful that while we share many use cases, we will not have all use cases our external users have, so we should not build only for ourselves and not validate with external users. This aligns with our you're not the customer product principle.
We have the right to win in this Section because:
We will pursue this opportunity with the following principles:
Thematically, our direction centers around:
Our 1 year plan is to:
There is a discussion on the different deployment options related to our Product Analytics and Observability technology on our deployments page. This was particularly important for when we were asking customers to deploy ClickHouse and related services but since we will now focus on internal teams, it will be less work that we ask external users to do. It will also be updated over time as the data unification efforts make progress and decisions on how to best bundle these services with GitLab.