Customer Product Usage Information

Customer Product Usage Information

GitLab’s Product Usage Data policies

GitLab is committed to providing value and functionality through our free, open-source software and paid offerings (collectively, the “Software”). In order to continue innovating and supporting our growing user base, it is helpful to have in-depth knowledge of how our users are utilizing the Software, which we collect as certain metrics generated through a customer or a users’ use of the Software (“Metrics”). To achieve the foregoing, GitLab collects information about how the features and functionality of the Software are used at an instance, namespace, or user level.

Instance or namespace level Metrics constitute total counts, such as the total number of projects, pipelines, issues, and merge requests related to that entire instance or namespace. These Metrics may also include an instance or namespace’s settings, such as database_version or container_registry_enabled. User level Metrics are events related to specific user interactions with the Software, such as whether a user viewed a certain page or clicked a certain button in the Software. Subject to the exceptions described in the proceeding sections, the personal data of individual users is generally not collected.

The Metrics collected can be separated into three collection services: Service Ping, Snowplow, and License Sync (collectively, “Product Usage Data”). The details of each collection service can be found below, including the applicable Software type in which the Product Usage Data operates, the cadence for collection, and the types of Metrics collected.

What are the data collection services that constitute Product Usage Data

As stated above, there are three collection services GitLab uses to generate Product Usage Data, which in turn allow us to invest more efficiently and continue to expand both the open source and paid Software offerings.

Service Ping (formerly known as Usage Ping)

Purpose: GitLab collects Service Ping Metrics to collaborate with our customers to accelerate value attribution, achieve return-on-investment (ROI) goals, and accomplish business outcomes with the Software. Service Ping Metrics are composed of aggregate count Metrics related to an entire instance, tenant or namespace, as well as true/false Metrics regarding the enablement of certain settings or features. Aggregate counts are tallied in an “all-time” format and a “28-day” format. Please see our Service Ping FAQ here.

Applicable Software: Service Ping Metrics are collected in the Self-Managed, GitLab.com and Dedicated versions of the Software. Generally, “Service Ping” is the name of the technology that collects the applicable Metrics from individual Self-Managed installations and Dedicated. Since GitLab.com is essentially a GitLab-hosted multi-tenant version of a Self-Managed instance, a version of Service Ping has been implemented for GitLab.com and provides GitLab.com equivalent Metrics to what we achieve with Self-Managed instances. For more information on how Service Ping operates exclusive to Self-Managed instances, please see our Service Ping Guide.

Configuration: Self-Managed and Dedicated Service Ping payloads contain instance-level Metrics for each individual Self-Managed installation and Dedicated tenant. GitLab.com Service Ping Metrics relate to both the entire GitLab.com instance as well as every GitLab.com namespace. Additionally, page views are automatically instrumented on GitLab.com.