Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Vision - Collection

🧺 Collection

Please reach out to Tim Hey, Interim Product Manager for Telemetry (E-Mail if you'd like to provide feedback or ask questions about what's coming.

🔭 Collection Vision

Data is becoming more and more important for building products. Unfortunately, it's tricky to implement usage tracking, and often requires either complex and confusing code/integrations, or expensive, proprietary tools (or both).

Everyone should be able to easily track how their users are using their product whether they are a small team working on an Android app or a vast, enterprise company.

When thinking about telemetry collection, we are guided by a few North Stars:

🚀 What's next & why

🔥 Current focus

Priority Focus Why?
1️⃣ Define and measure monthly active users, overall and per-stage After this epic is closed, we should have an internally consistent view of MAU and SMAU across GitLab.com and self-managed. We should be able to measure active use in a Periscope dashboard, enabling us to improve MAU and SMAU. We can then tackle improving this further with SMAU/MAU v2.0.

🎉 Next up

Priority Focus Why?
2️⃣ SMAU/MAU v2.0. As our organization grows, we require better data to inform our product, marketing, and sales team as they make decisions to grow the business and realize our strategic goals. This epic will serve as the aggregation of issues required to improve our monthly active user metrics, so we can have a world-class data platform at GitLab.
3️⃣ Improve telemetry data collection from self-managed instances Currently we have little to no visibility into how many of our largest and most valuable customers are using GitLab. We need to understand how we can collect data more consistently from our Self-Managed users in order to better serve them.
4️⃣ Telemetry Documentation It is important that as we roll out new changes and develop processes and workflows, we clearly and transparently document everything in a way that is easily discoverable and digestible by both GitLab team members and users/customers.

A brief history of Usage Ping

Historically, GitLab has utilized a primitive and limited product usage tracking system (developed in-house) called usage ping. This consists primarily of counts, e.g. how many pipelines, issues, projects, etc. that a user has in their instance/group. A snapshot of this data is sent once a week to GitLab's Version application (which is also managed by Fulfillment), this ping also includes a version check to understand what version of GitLab is currently implemented. Further Documentation on usage ping.

The above is where we are today, but we need to move towards becoming a more data-informed Product organization at GitLab which requires a much more robust system for product usage data collection.