このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
Telemetry manages a variety of technologies that are important for GitLab's understanding of how our users use our products. These technologies include but are not limited to: Snowplow Analytics and an in-house tool called Usage Ping which is hosted on version.gitlab.com and includes a separate service calledVersion Check.
If you'd like to discuss this vision directly with the Product Manager for Telemetry, feel free to reach out to Hila Qu via e-mail.
The primary purpose of telemetry is to help us build a better Gitlab. Data about how Gitlab is used is collected to better understand what parts of Gitlab needs improvement and what features to build next. Telemetry also helps our team better understand the reasons why people use Gitlab and with this knowledge we are able to make better product decisions.
The overall vision for the Telemetry group is to ensure that we have a robust, consistent and modern telemetry data framework in place to best serve our internal Product, Finance, Sales, and Customer Success teams. The group also ensures that GitLab has the best visualization and analysis tools in place that allows the best possible insights into the data provided through the various collection tools we utilize.
| Category | Description |
|---|---|
| 🧺 Collection | The structure(s) and platform(s) of how we collect Telemetry data |
| 🔍 Analysis | Manages GitLab's internal needs for an analysis tool that serves the Product department |
To learn more about implementing telemetry, read our guides for Telemetry, Usage Ping, and Snowplow.
Dashboards at GitLab have been created for the team to have better insights into how various parts of the company are performing. Today in Periscope we have dashboards that range from GitLab's overarching company KPIs, financial performance, Customer success, Sales forecasts to Product focused SMAU dashboards.
Please reference the “Self-Serve Analysis in Periscope” handbook page for a thorough step by step guide
Quick steps to get-started:
| Driver | GitLab.com | Self-Managed |
|---|---|---|
| % of Revenue | 10% | 90% |
| MAU | ~750K | Millions (paid and CE ~5.5M) |
| Ease of Data Collection | Easy | Complicated |
| Data Sources Today | GitLab.com db Snowplow (basic) | Usage Ping |
| Data Sources in Future | GitLab.com db Snowplow (enhanced) | Usage Ping |
| Opt-out? | TBD | Yes |
| Priority | Focus | Why? |
|---|---|---|
| 1️⃣ | Enhance Usage Ping to Measure AMAU/SMAU | After this epic is closed, we should be able to measure usage activity from Usage Ping and have an internally consistent view of that data between self-managed and .com. |
| Priority | Focus | Why? |
|---|---|---|
| 2️⃣ | Harden Usage Ping | 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. Usage Ping is a key provider of that data but Usage Ping in it's current state is fragile. If another stage team adds a complex counter to Usage Ping, we need to ensure the entire Usage Ping does not break. This parent issue will serve as the aggregation of issues required to improve the performance and stability of Usage Ping, so we can have a world-class data platform at GitLab. |
| 3️⃣ | Telemetry Documentation & Guides | 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. |
| Priority | Focus | Why? |
|---|---|---|
| 1️⃣ | AMAU/SMAU Dashboards | Parallel to enabling the measurement of AMAU/SMAU, it's important that we are capturing the right metrics for each stage so that each Product Manager has visibility into how users are using their stage and stage categories. |
| Priority | Focus | Why? |
|---|---|---|
| 2️⃣ | Explore Alternate Analytics Tools for Product | Product team members have a hard time having their needs met by Periscope, there is a need for the data to be explored easily without the need for SQL or getting a dashboard built. |
We follow the same prioritization guidelines as the product team at large. Issues tend to flow from having no milestone, to being added to the backlog, to a directional milestone (e.g. Next 3-4 releases), and are finally assigned a specific milestone.
Our entire public backlog for Telemetry can be viewed here, and can be filtered by labels or milestones. If you find something you are interested in, you're encouraged to jump into the conversation and participate. At GitLab, everyone can contribute!