All the steps required to bring usage ping to CE
We want to make good product decisions that are driven in part by quantitative data analysis. We have started this effort with a usage ping in our EE installs (https://gitlab.com/gitlab-org/gitlab-ee/issues/892). But we also want to do something similar / the same in CE. The install base of CE is much larger than EE. Many of our EE customers start out as CE and graduate up. CE users are thus at the top of the funnel. And of course CE features are a subset of EE. Therefore, we need to capture data from CE as well. Data-analysis wise, the quantity of data from CE will be much higher. So that is another reason to go for CE in addition. We will discover insights from a larger set of data that we may not necessarily discover in EE.
We want to move forward with bringing the usage ping to CE. Usage ping data will be completely anonymous. Moreover, we'll ask for permission before enabling this feature at the instance level.
- CE/EE: Load JSON payload into a separate page so it doesn't time out in some cases https://gitlab.com/gitlab-org/gitlab-ee/issues/1498
CE/EE: Periodically save
last activity datedata from Redis to the database
https://gitlab.com/gitlab-org/gitlab-ce/issues/27790moved to https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1597
- CE/EE: Provide user cohort insights as a benefit of keeping usage ping active https://gitlab.com/gitlab-org/gitlab-ce/issues/29551
- CE: Port usage ping from EE to CE https://gitlab.com/gitlab-org/gitlab-ce/issues/27750
CE: Add a message asking to enable usage ping feature to administrators https://gitlab.com/gitlab-org/gitlab-ce/issues/27757
Changes in version.gitlab.com:
- Update version.gitlab.com to gather CE usage ping https://dev.gitlab.org/gitlab/version-gitlab-com/issues/46
Out of scope
Adding any additional data to collect beyond what is already collected in EE is beyond the scope of this feature. This feature should collect at least something, and should be a subset or the same set of what is collected in EE now. It should not be a superset.
Before the feature is shipped, we will write a blog post to communicate further the context of this feature. We will mention this feature in the 9.1 release post.