Web 分析工具长期面临一个结构性矛盾：既要获取足够的行为数据支撑业务决策，又必须遵守日益严格的隐私法规并尊重用户选择。Google Analytics 的免费模式建立在数据变现之上，而 GDPR、CCPA 等法规的落地让这种模式的合规成本急剧上升。Plausible Analytics 选择了一条不同的技术路径 —— 通过架构层面的隐私设计，在放弃个人身份追踪的同时，依然提供实时、高效的流量分析能力。
架构选择：为什么用 Elixir 与 ClickHouse
Plausible 的技术栈体现了对分析场景特定需求的精准判断。后端采用 Elixir 与 Phoenix 框架，这一选择并非偶然。Elixir 运行在 Erlang VM 之上，天生具备高并发连接处理能力和容错特性，非常适合处理大量短连接的 HTTP 请求 —— 这正是网页追踪脚本的典型负载模式。
数据存储采用分层架构：PostgreSQL 负责关系型数据（用户账户、站点配置、目标设定），而 ClickHouse 专门承载高吞吐量的分析事件流。这种分离源于 Plausible 团队在生产中的实际经验。早期版本曾将分析数据存放在 PostgreSQL 中，但随着数据量增长，聚合查询的性能急剧下降。ClickHouse 作为列式存储数据库，在计算 UV、PV 等去重指标和时序聚合方面具有数量级的性能优势。
这种架构决策的代价是运维复杂度。ClickHouse 对硬件有特定要求：CPU 必须支持 SSE 4.2 或 ARM NEON 指令集，内存建议不低于 2GB。对于自托管用户而言，这意味着无法在最便宜的 VPS 上运行，需要为分析引擎预留足够的资源预算。
隐私优先的工程实现
Plausible 的隐私设计不是事后补丁，而是贯穿数据流每个环节的架构原则。最核心的决策是完全放弃 Cookie 和持久化标识符。传统的分析工具依赖 Cookie 或指纹技术来识别回访用户，而 Plausible 仅基于单次会话的匿名数据计算指标。这意味着无法提供跨会话的用户留存分析，但换取了无需同意弹窗、无需隐私政策更新的合规优势。
追踪脚本的体积被压缩到不足 1KB，相比之下 Google Analytics 的 gtag.js 通常超过 100KB。这种轻量化不仅提升页面加载性能，也减少了被广告拦截器拦截的概率 —— 许多拦截规则基于脚本大小和域名特征进行过滤。
数据最小化原则体现在采集字段的严格限制：不存储 IP 地址、不记录用户代理字符串的完整内容、不追踪页面滚动深度等细粒度行为。Plausible 认为这些数据的业务价值不足以抵消隐私风险，因此主动将其排除在采集范围之外。
自托管部署的工程实践
Plausible 提供托管云服务，但社区版（Community Edition）允许完全自托管。标准的部署模式基于 Docker Compose，包含三个核心容器：
- Plausible 应用：Elixir/Phoenix 服务，暴露 HTTP 端口
- PostgreSQL：存储用户、站点配置等关系数据
- ClickHouse：存储事件流，支撑聚合查询
这种三容器架构是自托管的最小可行单元。生产环境通常需要在前端增加反向代理（Nginx 或 Caddy）处理 TLS 终止。环境变量配置遵循清晰的命名约定：DATABASE_URL 指向 PostgreSQL，CLICKHOUSE_DATABASE_URL 指向 ClickHouse。
备份策略需要分别处理两个数据库。PostgreSQL 的备份相对标准，而 ClickHouse 的数据备份更为关键 —— 它存储了所有历史事件数据。社区实践中，建议为 ClickHouse 配置自动化备份任务，使用 clickhouse-backup 工具或自定义脚本将数据快照到对象存储。
资源规划方面，2GB RAM 是运行 ClickHouse 的底线配置。对于中等流量的站点（日 PV 在数万级别），建议分配 4GB 内存以确保聚合查询的响应速度。CPU 核心数的需求相对较低，但单核性能会影响复杂查询的执行时间。
工程决策的取舍与启示
Plausible 的架构选择揭示了几个值得关注的工程权衡：
列式存储的适用边界：ClickHouse 的引入解决了 PostgreSQL 在分析场景下的性能瓶颈，但增加了技术栈复杂度。这一决策的前提是事件写入量足够大、聚合查询足够频繁，能够抵消多数据库运维的成本。对于日活用户低于千级的内部工具，单 PostgreSQL 可能仍是更简单的选择。
隐私与功能的平衡：放弃 Cookie 意味着放弃跨会话追踪能力，Plausible 用 "简单即功能" 的产品哲学化解这一限制。其仪表盘仅展示最核心的指标（访客数、页面浏览、流量来源、目标完成），避免陷入自定义报表的复杂度陷阱。
许可证策略的务实考量：Plausible 主体采用 AGPLv3 开源协议，但将 JavaScript 追踪脚本单独以 MIT 协议发布。这一安排的动机是避免 AGPL 的 "传染性" 影响用户网站 —— 如果追踪脚本也是 AGPL，理论上用户需要开源其整个网站代码。这种双许可证策略体现了开源项目在商业可持续性与社区友好度之间的平衡。
何时选择 Plausible
Plausible 并非 Google Analytics 的完全替代品。如果你的业务依赖漏斗分析、电子商务收入归因、跨设备用户追踪，Plausible 的社区版可能无法满足需求。但以下场景特别适合考虑 Plausible：
- 合规优先的站点：面向欧盟用户的 SaaS 产品、注重隐私的技术博客、政府或教育机构网站
- 性能敏感的场景：需要最小化第三方脚本对 Core Web Vitals 影响的电商站点
- 数据主权要求：必须将分析数据保留在特定司法管辖区（Plausible 云托管完全在欧盟基础设施上运行）
自托管的决策需要权衡运维成本与数据控制权。托管版提供全球 CDN、自动备份、高级机器人过滤等增值服务，而社区版要求自行处理容量规划、升级迁移和安全补丁。对于没有专职运维团队的小团队，托管版的时间成本可能低于自托管的隐性开销。
参考来源
- Plausible Analytics GitHub 仓库: https://github.com/plausible/analytics
- ClickHouse 官方博客 - Plausible 使用案例: https://clickhouse.com/blog/plausible-analytics-uses-click-house
- Plausible 社区版部署指南: https://github.com/plausible/community-edition/
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。