Obtain more telemetry data from self-managed instances
Problem
We have very little visibility into how many of our largest and most valuable customers are using GitLab, this is because we allow telemetry data to be switched off on on-prem installs (Starter, Premium, Ultimate). On-prem customers make up 60% of our customer base at 6019 customers - this is a huge amount of data we are not getting, assuming none of them has telemetry data switched on.
Usage data is one of the most effective ways of evaluating the relevancy and value of a system. By knowing what users are viewing or not viewing, organizations are able to understand what is of value to their users and effectively manage when a change needs to be communicated. Effective change management requires the use of data but few companies are transforming their data into insights to understand the needs and interests of their users.
We already collect usage data from GitLab.com namespaces and groups, we should do that same for on-premise installations.
Proposal(s)
-
Switching telemetry data off is no longer an option and the customer agrees to send usage data back to GitLab as part of the product's terms and conditions, especially since we are not collecting PII from self-managed instances and are not sharing the data with any third parties. -
Make it harder to turn off telemetry data at the instance level by only allowing it to be toggled via the CLI upon installation/upgrade (and also deactivate the ability to disable it via the gitlab.rb file as per option 4).
-
Add tiered collection options for self-managed instances.
-
Disable the ability to turn off usage ping in
gitlab.rb
and instead, require deactivating it in the UI. -
Thoughts/suggestions welcome.
Result
A tremendously robust collection of data from ~100% of our userbase.
Next steps (if any)
- gitlab-org/ux-research#295 (closed)
- Is it possible to start with groups of users? CE, Starter?
Note: We should also consider public sector customers as a separate problem to solve here as they will have different needs to the rest of our customer base. We will always need to provide a way for them to opt-out of any data sharing.