隐私友好网站统计工具替代方案：从部署到数据验证

Plausible 是目前很有代表性的轻量级网站统计工具，核心卖点是隐私友好、无 Cookie、脚本体积小，同时能满足大多数内容站和中小型产品的基础流量分析需求。最近经常能在技术社区看到“Show HN: Modern Alternative to Plausible”这类标题，说明已经有人用更现代的技术栈、更简洁的部署方式或更完善的事件模型，重新做一款同类工具。这篇文章不打算替某个具体项目背书名，而是把 Plausible 这类统计工具的替代方案拆开看：它到底替代了什么、部署和接入要准备哪些条件、怎么验证数据准确、问题出现时按什么顺序排查。

先给一个我自己的结论：隐私友好型统计工具用来做内容站、博客、产品落地页的日常流量分析，完全够用；但如果你要的是广告归因、用户级行为漏斗、精细化事件分析，那不管多“现代”的替代品，都要先确认事件模型和查询能力是否支持。很多人在这一步就已经选错了方向。

1. 替代方案要替代的不是“一个按钮”，而是一整套统计口径

1.1 Plausible 的核心能力，决定了替代品的及格线

Plausible 解决的问题非常具体：在不使用 Cookie、不采集个人标识信息的条件下，统计一个网站的页面浏览量、访客数、来源渠道、设备类型、热门页面等基础指标。它的脚本设计得尽量轻量，不需要用户弹窗同意，也不需要复杂的埋点体系，因此特别适合内容站、个人博客和产品官网。

所以，任何号称“现代替代方案”的项目，第一件要做的事不是界面更好看，而是先把这些基础能力补齐：

• 页面浏览数据能正常上报。
• 能区分独立访客，而不是把所有请求都当成 PV。
• 能保留来源 Referrer、落地页、设备、地区等维度。
• 能配置目标或转化事件。
• 提供的统计脚本不会引入 Cookie 或者跨站追踪。

这些是及格线。如果一套替代方案连 PV 和 UV 都分不清楚，界面再现代也没意义。我在评估这种项目时，会先找它的数据定义文档，看看“访客数”“会话数”这些名词到底怎么算的，而不是直接看截图。

1.2 “现代”到底现代在哪：存储、部署、事件模型

从技术角度看，这类替代方案通常会在下面几个方向做文章。

第一是存储引擎。有的实现基于 PostgreSQL，有的会引入 ClickHouse 做聚合存储，也有的直接用嵌入式数据库。存储引擎决定了查询实时性和大数据量下的表现。简单说，PostgreSQL 的部署简单、生态成熟；ClickHouse 更适合同一指标在大量数据上快速聚合；嵌入式数据库适合极低流量、单机部署。没有绝对好坏，只有适不适合你的流量规模和运维能力。

第二是部署方式。老一代工具常常要同时维护应用、数据库、缓存、反向代理好几套东西。新一代替代方案里，有很多项目强调“单容器启动”“单二进制文件”，或者干脆做成托管服务。部署方式是选择时最先能感知到的差异，新手往往在这里决定是否放弃。

第三是事件模型。Plausible 的默认统计以 Pageview 为主，配合目标做转化。现代替代品可能会提供自定义事件、属性过滤、用户路径分析等更多能力。注意，事件模型的复杂度越高，越容易遇到“数据采集了但分析不出来”的情况，因为前端 API、存储字段、后台查询都要配套。

1.3 先判断你是哪类用户

在继续往下读之前，先想清楚自己的身份，这决定了你要关注哪一部分。

如果是个人博客、产品官网、社区文档站，你需要的通常是：脚本放上去、PV/UV 能看到、来源能查、不用特别维护。此时选一个部署简单、升级方便的项目最省事。

如果是小型团队，需要和产品数据结合，比如统计按钮点击、表单提交、付费成功，那你需要自定义事件能力，并且要有 API 或导出功能，方便跟报表系统对接。

如果公司有严格的合规要求，还要考虑日志存储位置、数据是否可导出、是否支持自有域名统计、服务商是否提供数据处理协议。这些都属于“能不能长期用”的硬条件，比功能列表更重要。

2. 选型之前，先定好可验证的判断标准

很多人换统计工具，容易只盯着 Dashboard 截图看，忽略了部署、数据、接口这些根本差异。我建议用一个固定清单去评估，逐项打勾。

2.1 部署方式：单容器、多容器，还是托管服务

部署方式决定了你的运维成本。常见形态有三种。

很多人一上来就选“自托管”，理由是数据完全自主。但自托管不意味着没有成本：系统更新、数据库备份、磁盘扩容、日志轮转，每一样都要有人管。如果你只是维护一个博客，托管服务的免费额度大概率够用，没必要给自己加一台服务器。

2.2 数据存储和数据口径：它统计的是请求还是会话

这里有一个很多人忽略的问题：PV 可以靠前端请求数统计，但独立访客数怎么算？很多隐私友好工具使用会话标识或近似手段来识别独立访客。没有 Cookie 不代表没有识别逻辑，识别逻辑决定了 UV 的数字对不对。

评估时看一下文档里如何定义：

• 独立访客是不是按 IP 加 User-Agent 近似？
• 会话超时时间是多长？
• 同一用户清缓存后是否会被重复计数？
• 是否能过滤爬虫和健康检查请求？

如果文档没有写清楚，我建议直接用两个不同设备、同一网络访问测试，再用无痕窗口测试，看数字变化是否合理。

2.3 事件、转化和实时性的支持程度

基础统计之外，现代替代方案的差异化主要在事件能力。

需要确认几件事：

• 能否通过一行 JS 或 data 属性上报自定义事件，例如按钮点击、注册成功、滚动深度。
• 事件是否带属性，例如订阅来源、套餐类型。
• 能否把事件定义为目标并展示转化率。
• 实时面板是秒级还是分钟级延迟。

如果只是统计 Pageview，实时性影响不大；但如果你要监控一次投放活动，希望开跑后立刻看到点击和转化趋势，那实时性就是硬指标，不能只看后台截图，要实际压一下数据延迟。

2.4 隐私合规和可控性

隐私合规方面，核对这几个点：脚本是否需要用户同意、是否设置 Cookie、是否采集指纹、IP 是否脱敏、数据存储位置、是否能导出删除。不同地区合规要求不一样，但“无 Cookie、无指纹、IP 脱敏、数据可导出”是最稳妥的一组基本要求。

还要注意：工具本身不设 Cookie 不代表你不会因为接入其他脚本而触发弹窗。同一个页面如果同时有统计脚本、广告脚本、客服脚本，合规判定要看整站，而不能只看统计工具。

2.5 集成与导出能力

再好的统计工具，如果数据引不出去，后续接入报表平台就会很痛苦。重点看这些接口：

• 是否提供 REST API，能否按域名、时间范围、页面路径查询统计。
• 是否支持 CSV 导出。
• 是否提供 Webhook 或定时任务方式同步数据。
• 前端脚本是否支持自定义发送时机，比如在 SPA 路由变化时手动上报。

这块很容易被忽略，但真正长期使用时，导出和 API 的价值往往比 UI 功能更实在。我见过好几个项目因为拿不到历史数据，最后只能在两套统计服务之间手动对数字。

3. 本地试跑：先启动，再登录，最后才接脚本

评估工具不能光看文档，最可靠的方式是把它完整跑一遍。下面按自托管这类项目的通用流程拆开说。不同项目目录结构、环境变量名会有差异，但整体思路一致。

3.1 环境怎么准备

如果只是想看看界面，本地一台 Linux 或 macOS 机器就够了，Windows 可以用 Docker 环境或用 WSL2。建议先确认三件事：

• Docker 和 Docker Compose 已安装。
• 端口没有被占用，常见默认端口如 8000、8080。
• 磁盘有足够空间，至少预留 10GB 以上，后续数据库和日志会慢慢增长。

如果你的机器只有 2GB 内存，也可以跑，但尽量把数据库和应用放在同一台机器，不要额外开很多容器。低配置不代表不能跑，只是并发上来之后响应会慢，这一点要提前有预期。

3.2 用 Docker Compose 把服务拉起来

大多数自托管统计项目会提供一个docker-compose.yml示例。完整结构一般包括：

• 一个 Web 应用容器，负责提供后台和统计采集接口。
• 一个数据库容器，保存站点配置和统计数据。
• 一个可选缓存容器，用于提升接口并发能力。
• 一个可选反向代理，用来处理 HTTPS 和域名绑定。

一个比较典型的 compose 文件是这样的。这里用占位信息写给你看，具体镜像名和环境变量要以你选的项目文档为准：

version: "3" services: app: image: your-repo/your-analytics:latest restart: unless-stopped ports: - "8000:8000" environment: APP_URL: "http://localhost:8000" SECRET_KEY: "please-change-me" DATABASE_URL: "postgres://analytics:password@db:5432/analytics" depends_on: - db db: image: postgres:16-alpine restart: unless-stopped environment: POSTGRES_USER: analytics POSTGRES_PASSWORD: password POSTGRES_DB: analytics volumes: - analytics-db:/var/lib/postgresql/data volumes: analytics-db:

启动命令很简单：

docker compose up -d docker compose logs -f app

看到日志里出现启动成功、数据库迁移完成之类的输出，再继续下一步。如果日志不断报数据库连接失败，先检查DATABASE_URL里的主机名是不是写成了localhost。在容器之间通信，主机名应该写 compose 里的服务名db，而localhost指向的是当前容器本身。

另外，SECRET_KEY这类环境变量一定要换成随机值，不要用示例里的字符串。很多项目默认值公开，如果部署到公网，等于把后台会话加密和签名能力暴露了一部分。

3.3 初始化站点和拿到统计脚本

服务启动后，用浏览器访问http://localhost:8000。第一次打开通常会进入初始化页面：

1. 创建管理员账号。
2. 输入站点域名，例如example.com。
3. 保存后系统生成一段统计脚本。

这里最容易错的是域名带不带协议和路径。站点域名一般只填裸域名或子域名，不需要https://，也不需要结尾的/。填错了，导致后台看不到数据的情况非常常见。

生成的脚本通常长这样：

<script defer><!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>示例页面</title> <script defer>docker exec -t your-db-container pg_dump -U analytics analytics > backup_$(date +%F).sql

还要看这类工具是否有数据保留期或归档策略。如果统计服务长期不清理，数据库会越来越臃肿，查询速度下降。很多轻量工具默认没有自动删除逻辑，需要自己定期处理旧数据，或者干脆保留全量数据，但定期做索引维护和归档。

我个人的经验是：自托管统计服务的备份频率不要低于每天一次，尤其是流量上来之后。因为统计数据的价值具有时间累积性，一旦丢失，补录比生成困难得多。

6. 常见问题排查链路

这里把高频问题按“先看现象，再看输入，再看环境，最后看参数”的顺序整理一下，遇到问题可以直接对照。

6.1 后台无数据

这是接入后最常见的问题，排查顺序建议如下：

1. 刷新后台页面，确认不是缓存问题。
2. 检查 Network 面板，看统计脚本和采集请求是否都发出。
3. 如果脚本请求失败，检查访问路径和反向代理配置。
4. 如果采集请求失败，检查站点域名和脚本里的>docker compose logs --tail 200 app

   日志是英文也不要急，重点找error、panic、failed、connection refused这些关键词。如果是数据库连接失败，先检查数据库容器是否健康，再检查连接字符串里的主机名和密码。

   6.3 数据量对不上

   对比不同统计工具有出入时，先看看是不是以下原因：

   • 定义不同：PV 用页面加载次数，UV 用访客标识，会话有超时时间。
   • 漏统计：JS 未加载、SPA 路由切换、整页缓存。
   • 多统计：刷新页面、浏览器预加载、脚本重试。
   • 过滤设置：是否过滤了本机访问、爬虫、内网流量。

   建议用一个受控页面做基准测试：找一个稳定页面，手动刷新固定次数，观察后台数字是否同步。如果单页面数字稳定，再扩大到全站对比。

   6.4 页面或接口响应慢

   响应慢通常不是单点问题，按顺序排查：

   1. 看服务器负载，CPU 是否满负载。
   2. 看数据库慢查询日志。
   3. 看统计接口是否需要实时聚合大量数据。
   4. 看是否有缓存层，比如应用内缓存或反向代理缓存。
   5. 看是不是实时面板的查询权重太高，对普通页面造成干扰。

   流量不大但响应慢，多数是默认配置没有针对查询优化。比如实时面板频繁触发了大型聚合查询，而查询字段没有索引。这种情况下可以限制实时面板的默认时间范围，或者减少自动刷新频率。

   7. 什么情况不建议换，或者至少要谨慎

   最后聊几个容易让人冲动的场景。现代替代方案听起来都好，但不是所有情况都适合立刻切换。

   7.1 规模太小，托管反而省心

   如果你的博客一个月只有几千次访问，自托管统计工具的服务器成本、备份、更新维护成本，可能比托管方案的免费额度更高。这时更合理的选择是先看托管方案，数据导出功能有保障即可。自己把统计服务跑在云服务器上，听起来很酷，但每次系统升级、数据库故障都要处理，这个成本在小流量场景里不划算。

   7.2 业务需要复杂分析和广告回传

   隐私友好工具通常不会采集用户级别的行为详情，也不做广告平台归因。如果你需要知道某个用户访问了哪些页面、点击了什么按钮、最后是否转化，并且要按用户维度做分群，那这类轻量工具大概率满足不了。此时应该看更完整的行为分析平台，或者接受只有聚合指标的限制。

   广告回传也一样。很多轻量统计工具会把转化事件发给自己后台，但不提供和广告平台之间的自动回传。如果你需要把转化数据同步到投放平台，确认接口里有没有相关能力，没有就不要硬换。

   7.3 自托管的长期维护成本

   自托管统计不是“装完就结束”。长期来看，下面这些事都要有人负责：

   • 依赖版本升级和数据库迁移。
   • 安全补丁和访问控制。
   • 数据备份和恢复演练。
   • 磁盘扩容和日志轮转。
   • 新版本兼容性测试。

   如果团队里没有人愿意长期维护这套东西，我建议优先选托管服务。数据自主可控和安全稳定不是一回事，自托管只是把数据放在自己手里，不代表它一定更安全。

   7.4 如何安全地做一次切换

   如果决定换，不要直接关掉旧工具。建议并行运行一段时间：

   1. 新旧脚本同时放半个月。
   2. 每天对比核心指标。
   3. 确认新工具口径没问题后，再下线旧脚本。
   4. 保留旧工具至少一个完整数据导出周期，方便追溯。

   并行运行期间，注意新旧工具对页面 CSP 策略和性能的影响。如果页面有严格的 Content-Security-Policy，要先把统计脚本域名加入script-src和connect-src白名单，否则脚本会被浏览器拦截。

   一套统计工具的切换，真正风险不在于装不上，而在于“你以为统计的是 A，实际统计的是 B”。只要数据口径验证清楚、导出和备份有保障，换成什么都只是时间问题。