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 helping customers understand and gain insights from usage patterns in their software.
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 in which we have an opportunity is to make it easy for developers to add instrumentation code. This is the first step in any analytics workflow. Given that developers represent a key persona we collaborate with, we have a better sense of 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.
In addition to the benefits mentioned previously, our ability to store the user's application code presents a significant longer-term opportunity. By leveraging this contextual information, we can offer more comprehensive analytics solutions than any other product. For instance, we could explore the possibility of suggesting or automatically adding analytics instrumentation code to different parts of the app. While this requires extensive research, one potential outcome could be direct suggestions within merge requests (MRs) along with code snippets to automatically instrument newly added sections of code.
The ideal customers for Product Analytics are GitLab customers who have no usage tracking today and because of that cannot explore and share the value the software they are shipping is providing or where they should invest in features next. We have found this may be but is not limited to an internal tools team who offers self-serve capabilities to other teams but do not know how that investment is paying off today.
We have a plan to iteratively develop Product Analytics. We will start small and incrementally add new capabilities. Each iteration will let us learn more and solicit feedback to improve, before we start our next iteration. Our first iteration was primarily internally focused and we are now turning our attention to the first customer facing releases.
The list below is in rough priority order and is by no means final. We will update it as we learn more and add or remove items. If you have feedback, please share it, we'd love to hear your thoughts and ideas!
With our Intrnal Previewe complete we have started engaging with external users to show them Product Analytics which will conclude with our first release to users. We will engage with external users and customers iteratively, with the set of milestones below outlining this. These roughly correlate to our current guidance in the handbook and documentation about phased releases. We will provide timing guidance for each as we make progress.
We are tracking work for this release in the Experiment release epic. This release may or may not include features intended for the General Availability release. We expect there to be many open questions going into this release and also coming out of it about what features are being used, valued and the underlying technology.
We may or may not have a finalized pricing and packaging proposal for Product Analytics by this stage.
Beta This iteration will be available to anyone interested in signing up to try Product Analytics. Our goal with this release will be to identify any potential issues, bugs, or edge cases with our features that would prevent us from being ready for production-grade usage and fully opening up for GA.
Once we are in Beta, we will be feature complete for what will be available in the GA release. The Beta is intended primarily to understand tweaks that may need to be made to existing features, ensure we are ready for production-grade loads, and fix any bugs.
Pricing and packaging should be relatively complete by this release, though may change before the GA release.
A key difference between the Experiment and Beta is that we will expect much greater load on GitLab during this period, since any customer can sign up for it.
Our minimal feature set that we will work on to get us to our first GA will likely include:
Once our first user-facing release is available, we will respond to feedback on where we'll next focus our efforts. We have several ideas for follow-on iterations after this release, which are listed below. Several of these may also be included in our initial GA release.
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. This section is subject to change without notice.