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.
Welcome to the GitLab Product Analytics group direction.
Given our focus on developers, the software delivery value stream, and DevOps - we will compose our new DevOps stage, Analyze, based on the set of categories we commonly see in User Engagement competitors.
Currently the Product Analytics group includes a single category, Product Analytics. This category is focused on understanding and gaining insight from usage patterns.
In the future we envision more categories as we broaden our scope to cover additional personas and use cases. Those new categories include (in priority order):
There are a number of existing (or considered) product categories in GitLab that could be considered part of the outer loop that the Analytics section will partner closely with to ensure we provide a cohesive experience. Those include:
We plan to collaborate and build with these categories where possible, rather than re-inventing new solutions for these related use cases.
There are many use cases for Product Analytics. One way you can think about these is to segment them by the type of digital product analyzes and the subsequent questions those who create it would seek to be answer. For example, a team that publishes a blog is primarily interested in page views of blog posts.
Our initial use case is focused on our ability to dogfood. As a result they focus on Web Apps. Our initial use case is:
It is important to identify the use cases and personas that we want to pursue and it is equally important to identify those that we do not wish to pursue. Because analytics can mean many things to many different people, this is especially important.
We do not plan at this time to pursue use cases and personas around:
Note that while the above are use cases and personas we are not actively pursuing, this does not mean that those personas will not find some value in what we provide. It means that they are not our primary focus. We do not intend to block functionality around these, just that they are not our primary focus. For example, page views and traffic trends are also useful for marketing personas, but we intend to use them for guiding product-related use cases, not for addressing marketing-related use cases. Similarly, understanding error reporting for a given feature may be important to understand a feature, but we are not focused on making a product quality or bug tracking platform using those pieces of data.
When conducting user research, a common theme we heard is that developers find it hard to add instrumentation code to their app or to successfully gather together the reported data. This could be because they are unfamiliar with their app's architecture, the specific SDK of the instrumentation tool, or because they had to use another tool to configure reporting and monitor results. GitLab is the One DevOps platform so has a unique opportunity to address these pain points that other solutions may have.
One area that we have an opportunity is to make it easy for developers to add instrumentation code. This is the first step in any analytics workflow. Our primary personas we work with so we know what they like, do not like, are good at, and what sorts of experiences they prefer. Additionally, they are already familiar with GitLab and many conventions of our product. This gives us the ability to create an approach to adding product instrumentation that is easy and familiar to our users. If developers are excited and easily able to add instrumentation to their apps, they will add more, which means their teams will get more valuable insights. Other functional counterparts, such as Product Managers, will see how easy it is for developers to use GitLab to instrument their apps, so they will also be excited to use GitLab, rather than another tool.
Another opportunity we have is to do the entire analytics reporting and analysis directly within GitLab, rather than requiring users to use another tool. We know from talking to users that accessing another tool is time-consuming and friction filled. Being able to go from reading a GitLab issue to looking at an MR to visualizing the latest Product Analytics data in a single place will make it easy for users to get access to the insights from their data quickly. Because it is so painless to view analytics data, these users will do so more and more often, which means that they get even more value out of GitLab.
A final, longer-term opportunity is because we store the user's application code, we have a larger amount of context about the app than any other analytics product could. It will be possible for us to suggest or even automatically add analytics instrumentation code to parts of the app. This will require a lot of research, but one way this experience could look may be that if a user creates an MR, GitLab provides suggestions directly within the MR with code snippets that will automatically instrument the newly added portions of code.
The market is divided between big tech entrants building on top of complete Marketing Automation platforms marketed towards enterprise marketing orgs and stand-alone tools user engagement tools that are marketed towards Product (and occasionally Development) teams.
Due to the heavy emphasis on SaaS and the high data volumes - most pricing in this market is consumption-based.
Our Performance Indicators are TBD.
We are conducting research on critical jobs to be done for the Analytics section.
The existing personas we serve are below, in priority order. We will likely 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.
Our tiering plan will leverage our buyer-based model. The Analytics section, as a bridge from Ops to Dev (Plan) is an inherently collaborative stage. As a result, there are significant Paid Tier possibilities. Core will be seen primarily as a developer on-ramp.