Common Fate collects anonymous telemetry data to help improve our product. Participation is optional and users have the ability to opt-out at any point. Telemetry has been implemented through our community RFD process and we encourage feedback via discussion comments on RFD#8.
Why Collect Telemetry?
As developers of Common Fate we have very little insight into how the product is used beyond our own team. Typically we find out about product deployments because a community member joins our community Slack (usually when they have challenges getting started). Community members with successful deployments tend to be quieter because everything is working well. In the latter use case we have no visibility over product usage. Visibility into such usage is helps us to prioritize new product features in accordance with the purposes listed below.
We collect anonymous product analytics for Common Fate.
What is Collected?
General usage information is tracked, such as product versioning and plugins in use.
|Access Providers in use.||Helps us to understand the impact of changes to providers; for widely-used alpha-version providers we will provide scripts to automatically update Access Rules when changes are made to Access Providers. Helps inform the direction of the project with the kinds of new Access Providers that are developed.|
|Percentage of Access Rules requiring manual approval.||Helps us prioritize manual approval policy improvements (such as 2-person approval for access) versus automated approval policy improvements (such as associating Linear/Jira tickets with access requests, or integrating with PagerDuty and other on-call platforms)|
|Access Request time to approval.||One of the core values of Common Fate is that the access request workflow must be extremely fast. This includes the approval aspect. Our goal is that the median approval time is less than 10 minutes but we have no way to measure this. Helps drive improvements around the request workflow, such as our notifications to approvers.|
|Common Fate version number.||Helps us prioritise backporting patches to previous versions.|
The above list undergoes frequent audit to ensure accuracy.
To view exactly what telemetry data is being collected, add the following parameter to your
AnalyticsLogLevel parameter is set, analytics events will be printed to your deployment’s CloudWatch log groups when data is collected.
Below is an example of a telemetry event:
The full list of events, along with example data for each, can be found at the open source analytics-go repository.
To opt out of product analytics, add the following entry to your
deployment.yml file and update your deployment:
To re-enable the collection of telemetry data, simply remove the
Handling of Sensitive Data
Sharing of Data
Collected data is completely anonymous, untraceable, and personally unidentifiable. The data holds meaning only in its aggregate form.
To better understand collected telemetry data, we have adopted the following third party sub-processors:
We plan to publish key metrics back to the community and share insights to openly discuss our roadmap. These metrics will be published in aggregate form only across all deployments.