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.
We heard a collection of common questions when talking with users.
Some of these were:
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 when an application is behaving as intended and that users are getting the expected value.
We provide app owners and developers the tools to understand when their application is behaving properly (or not) and then to learn about how users engage with the app. This allows app owners to move beyond only focusing on improving efficiency to instead focusing on improving effectiveness.
The Analytics Section is comprised of a single Stage, the Monitor stage. This stage has three groups:
The Product Analytics group focuses on allowing users to analyze product data to uncover insights about how 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.
The Observability group focuses on providing visibility into the health of running applications and how they are performing.
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.
See Observability target audience
The primary personas we address, in priority order, are:
We may need additional personas in the future.
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.
As part of considering these personas, consider what personas we are not including in this initial list. Specifically, we are not targeting executive personas or Directors with the initial offering. Sasha and Parker are individual contributors and have unique needs different than Directors or executives. They are focused mainly on specific applications and the analytics related to them, whereas executives and Directors will be concerned about multiple, or a "fleet", of applications. We intend to go after these personas eventually and will not intentionally create capabilities that exclude them, but they are not our primary focus at this point.
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:
Our 1 year plan is to:
The Monitor stage offerings for both Product Analytics and Observability will require separate infrastructure from what GitLab runs on today. This is due to the need to leverage technologies like ClickHouse, Snowplow, Cube.dev, and others. We have different requirements than the Rails monolith with respect to qualities such as data ingestion, and horizontal scalability as part of providing a data management platform. We are exploring this as part of an internal working group. We will provide multiple different deployment options for this for GitLab.com, GitLab Dedicated, and self-managed deployments of GitLab.
One deployment option is for allowing Bring-Your-Own-Cluster or BYOC. In this deployment option, users will need to configure, run, and connect all of their own infrastructure to GitLab. This can work for GitLab.com, Dedicated, and self-managed. It lets users maintain full control over all their data and infrastructure at the expense of having to manage, scale, and support it themselves.
The other deployment option is to allow GitLab Inc to manage the required infrastructure. In this deployment option, users will be given URLs and API tokens that they can use to connect to pre-configured infrastructure. This means they can use it directly and not have to worry about scaling or managing it themselves. This will work on GitLab.com since we will connect a cluster directly to it. It will also work for GitLab Dedicated and self-managed customers by leveraging our cloud connector functionality.
Today, both Observability and Product Analytics can be used on GitLab.com with the managed infrastructure approach. For Observability, only the cloud connector approach is available to Dedicated and self-managed users and in a beta state. In contrast, only the BYOC approach is available for Product Analytics for Dedicated and self-managed users.
Customers will choose one to use but it does not mean they are mutually exclusive from GitLab's perspective in terms of which to implement. Our ideal state is that both approaches are available for customers to choose from. Primarily it is a sequencing decision on which we will develop first and which second.
We will first focus on enabling the BYOC deployment option for Observability. We will then work on enabling the cloud connector approach for Product Analytics. This approach will let us create a BYOC option that can be released in a GA capacity more quickly than doing it in the opposite order. Providing a managed version via cloud connector requires additional operational support and maintenance after the initial release that will take longer for us to be in a position to provide. In contrast, we can create a BYOC version of observability, modeled after the BYOC of Product Analytics, in a shorter time.
To simplify our current and deployement planned deployment options, the table below summarizes this:
| Deployment Method | Available on GitLab.com | Available on GitLab Dedicated | Available on self-managed |
|---|---|---|---|
| Bring your own cluster | Planned | Planned | Planned |
| Cloud connector | N/A | Planned | Planned |
| GitLab managed | Beta | Planned | Planned |
| Deployment Method | Available on GitLab.com | Available on GitLab Dedicated | Available on self-managed |
|---|---|---|---|
| Bring your own cluster | GA | GA | GA |
| Cloud connector | N/A | Planned | Planned |
| GitLab managed | Beta | Planned | Planned |
Our Performance Indicators are TBD.
We are conducting research on critical jobs to be done for the Analytics section.
The Monitor stage will further extend GitLab's lead in being the One DevOps platform by consolidating yet another set of existing tools required to deliver software value to users.
All current DevOps platforms define their water's edge at Monitoring - ensuring a deployed idea is available and performant for users. The process of visualizing and learning from usage, collecting and organizing feedback, engaging and enabling users - those are all left to specialist vendors positioning their products at Marketing, Growth and Product teams. We feel this gives us an opportunity to combine these use cases and combine them with the rest of the GitLab platform to provide more value to our users.
We stay aware of other companies in the market and record information on our competitors page.
One critical trend in this market is a clear move to first-party data (partially a result of ITP) as the use of third-party SaaS services to store user data increasingly causes data privacy compliance and brand concerns.
From conversations analysts we expect the market definitions to become crisper and to see a new segmentation that includes developer-focused user engagement products called Product Analytics.
See Observability market trends
The traditional markets for this stage are fragmented across IT Operations, Observability, Marketing Automation, and Customer Data Platform markets. The market most closely aligned with Product Analytics is Customer Data Platforms - a market that IDC states was $1.3B in 2020 and expected to grow to $3B by 2025 (18% CAGR). For Observability, Gartner estimate the APM & Observability market at $6.56 billion in 2023 and expected to grow to $8.4 billion by 2026 (8.6% CAGR).