Project: Botkube (Observability and Analysis / Observability)
File: analytics-collection.md

This document contains a summary of a short research around collecting anonymous analytics (a.k.a. telemetry) for Botkube. The main goal is learning how Botkube is used, in the most private and least invasive way for users. All data must be anonymized to prevent identifying users. All analytics will be used only as aggregated collection of data (in forms of some statistics), to further improve Botkube and adjust its roadmap. The change must be widely communicated to all users, and there must be an ability to opt out from collecting such analytics. I tried to look for some software from CNCF landscape which has telemetry built-in. Unfortunately, I couldn't find many examples when it comes to this field. It was much easier to find something in JavaScript world (e.g. NextJS). Anyway, here are a few examples I found: - Twilio Segment (), - Google Analytics (), - PostHog (), - Google Analytics 4 (), Rancher backed off from this idea when it comes to k3s: . All of the software I found that collect anonymous analytics (not only from Go/Kubernetes space) have opt-out based configuration. This list contains initial data which we will collect. Running installations: Botkube Version, Kubernetes version (it might be helpful to know which K8s we should support), Enabled notifiers (names), Enabled bots (names). Executed commands: For `kubectl` commands: exclude namespace (it could potentially identify user), exclude resource name (it could potentially identify user), collect just command verbs. Received events: See how many events are handled by Botkube and sent to any communication channel, We should batch the events to avoid high resource consumption during heavy load. This could be a built-in feature, like in . Errors: Application crashes (from inside the app), Configuration errors (syntax, missing fields etc.), Notification errors (when e.g. there was an error to post Slack or Discord message). The data collection would be enabled by default. By using two different identifiers at the same time, we will aggregate the data: per cluster (by using `uid` of the `kube-system` Namespace), and per Botkube installation (generating and storing UUID during Botkube installation e.g. in a ConfigMap). Enabled filters (as they will be probably reworked in

Based on run commands we will be still able to tell which filters are toggled on/off. After doing a little research, we could use the following solutions: Application: Twilio Segment a single API for analytics events, which can be forwarded to multiple destinations, multiple integrations with external APIs, ability to correlate events from different sources (e.g. website and appplication), automatic detection of the PII data, paid solution. While Google Analytics 4 could be also used for sending the events from the app (for free), Segment has some advantages. For example, see the on Reddit. Website: Google Analytics 4 completely free solution, powerful, we can use the to poll the data into Segment. Alternatively, we could use Segment integration directly on the website, but it would be more expensive, and I think it is not worth it for now. Piwik Pro - more privacy-friendly alternative to Google Analytics; however, the free plan is not as generous as GA. No Go API, but it is not a problem as it exposes HTTP API. Self-hosted solutions (e.g. ) - too big effort vs little benefit to set it up. (web only) - for websites set up behind Cloudflare; cookie banner not required; requires a paid plan. Once agreed, the following to do list will be pasted into the : [ ] Set up Google Analytics and Twilio Segment accounts Ensure proper access rights [ ] Implement collecting analytics in Botkube Collect analytics listed in section Use Enabled by default Make sure users can opt out: a dedicated env variable supported by app a dedicated Helm chart property Document changes on botkube.io: Update and describe data we collect Describe configuration - how to opt-out Consider describing it also for each installation document [ ] Implement analytics on the website Use Google Analytics 4 If needed: Add cookie banner (some reports say Google Analytics 4 are cookieless, but I also read on official website that `gtag.js` library uses first-party cookies, so a user consent might be also needed) Document changes: Update and describe data we collect [ ] Communicate changes Write announcement on Slack to gather feedback before/during implementation (before 0.13 release) Explain the reason of introducing the analytics Point to the for further discussion If necessary, schedule a public meeting to discuss the changes Mention analytics in Botkube 0.13 GitHub release description