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 Analyze 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.
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:
Our Performance Indicators are TBD.
We are conducting research on critical jobs to be done for the Analytics section.
The Analytics section 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.
The traditional markets for this stage are fragmented across IT Operations, Marketing Automation, and Customer Data Platform markets. The market most closely aligned to our intent is Customer Data Platforms - a market that IDC states was $1.3B in 2020 and expected to grow to $3B by 2025 (18% CAGR).