为什么我拒绝在开源项目中提供 Google Analytics

Source: Dev.to

背景

我构建开源应用，大多数都是自行托管的。和许多开发者一样，我需要度量——不是营销度量，而是基本信号：

• 这个应用真的在被使用吗？
• 有多少实例在运行？
• 哪些功能被使用了？

很长一段时间，默认答案显而易见：Google Analytics。但在某个时刻，我决定彻底停止使用它。

为什么 Google Analytics 不合适

Google Analytics 本身不是坏工具；它是为完全不同的目的而构建的。它假设：

• 集中的 SaaS 产品
• 被追踪的终端用户
• 营销漏斗
• Cookie、同意横幅以及外部依赖

这些都与自行托管的开源软件不太匹配。在开源应用中嵌入 GA 意味着：

• 将使用数据发送到用户基础设施之外
• 引入你无法控制的法律和隐私问题
• 在你只想要聚合使用情况时追踪个人

此时，成本（技术、伦理、认知）已经超过了价值。

我的需求

我查看了许多“隐私友好”或“自行托管”的分析工具（例如 Countly、PostHog）。它们大多数仍然假设：

• 网站，而非分布式实例
• 用户追踪（即使是匿名的）
• 为营销团队设计的仪表盘
• 为非常简单的问题提供繁重的部署

我需要的要简单得多。对于开源和自行托管的软件，我关心的问题虽然乏味，却至关重要：

• 这个实例还在运行吗？
• 有人在使用这个功能吗？
• 采用率在增长还是停滞？
• 这个版本是否破坏了使用模式？

我不需要：

• 页面浏览量
• 漏斗
• 会话重放
• 用户身份

我只需要信号，而不是监视。

引入 SHM（Self‑Hosted Metrics）

于是我构建了一个小型开源服务，叫 SHM（Self‑Hosted Metrics）。它刻意保持极简：

• 接受简单的 JSON 事件
• 不追踪用户
• 与应用无关
• 适用于自行托管的部署

目标不是做分析，而是提供使用情况的可观测性，同时不违背开源或自行托管的原则。

仓库：

结论

很多真实需求介于“完全没有度量”和“完整的 SaaS 分析堆栈”之间。大型工具并不关注这些需求，但对维护者、独立开发者和小团队来说，这些需求很重要。并不是所有东西都必须像增长漏斗那样被测量。有时候，仅仅知道你的软件在被使用就足够了。