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

Category Vision - Collection

๐Ÿงบ Collection

A brief history of usage ping

Historically, GitLab has utilised 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 organisation at GitLab which requires a much more robust system for product usage data collection.

Additional Links:

Please reach out to Luca Williams, Product Manager for Fulfillment (E-Mail/ Twitter) 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. Our goal is to build an open source Telemetrics API that anyone can easily integrate into their product to help them make good decisions.

This API should be:

Our users should feel safe and protected while opting in to sending GitLab Telemetry data. They should know that their data is being used respectfully and only to further improve our products and make them more lovable. As always at GitLab, Transparency is a core value and this includes Telemetry. Users should always know what we are collecting and how, where and when we are using it.

Telemetry should also be a feature for our users, providing them with a great user experience through unique insights and tools. We aim to utilise the power and capabilities of Telemetry data to enrich everyone's lives, not just the people who are collecting and analysing the data.

๐ŸŽญ Target audience

We want to build the Telemetry API with significant empathy towards Data Teams and Software Engineers. It's essential that the data output of working with this API be of high integrity, and the API itself should require minimal effort to implement. So much so that it could quickly become a necessary step of merging a new feature into production: i.e. Does this have Telemetry tracking included? Check.

Parker (Product Manager) - Persona Description

Sasha (Software Developer) - Persona Description

Dana (Data Analyst) - Persona Description

For more information on how we use personas and roles at GitLab, please click here.

๐Ÿ“š Notable reading