最近 Hacker News 上出现了一个很有意思的现象越来越多新项目以 Show HN: Modern Alternative to Plausible 的姿态亮相。Plausible 是什么它是过去几年隐私友好型 Web 分析领域最有代表性的开源项目无 Cookie、轻量、合规几乎是很多团队从 Google Analytics 迁移时的首选。既然 Plausible 已经是标杆为什么还有这么多人做它的现代替代品这通常不是否定 Plausible 本身而是因为它代表的那一代统计工具正在面临一个新的技术周期。这个技术周期的关键词是第一方数据、事件模型、边缘计算、Web Vitals 和可编程查询。以前用户关心的只是我的网站有多少人看、流量从哪来现在团队关心的是用户在哪个环节流失、页面交互体验到底怎么样、事件数据能不能和内部报表打通。需求变了工具形态自然要换代。这篇文章不针对某一个具体的 Show HN 项目下结论——这类项目成熟度差异很大而是帮你建立一套完整的判断和落地框架Plausible 的成与败分别在哪现代替代品里的现代具体指什么技术变化以及如果你决定部署或迁移完整的操作路径是什么。建议读者具备基本的 Linux 和 Docker 经验后半部分涉及部署、验证和排查如果暂时不想动手前几章的评估框架同样值得先读完。1. Plausible 为什么是这条赛道的基准又为什么会被替代1.1 Plausible 做对了什么Plausible 诞生于 2019 年前后抓住的时间窗口非常精准GDPR 正式落地欧盟对数据合规的处罚力度逐年加强浏览器对第三方 Cookie 的限制也越来越多。Google Analytics 那套基于 Cookie 的追踪体系在法律合规、页面性能和隐私观感上都变得沉重于是 Plausible、Fathom、Umami 这类轻量分析工具趁势而起。其中 Plausible 因为无 Cookie 开源 极轻量的组合成为很多独立开发者和小团队替换 Google Analytics 的第一站。从技术原理看Plausible 的核心设计可以概括为三点。第一统计脚本非常小官方宣称不到 1KB对页面性能影响几乎可以忽略第二不依赖 Cookie也不依赖 LocalStorage 之类持久化标识而是通过最小化处理 IP 等信息来做去重和地域判断且不保留可长期关联个人的标识第三默认就是 Privacy by Design仪表盘只展示 PV、UV、来源、跳出率、访问时长、设备、地区等聚合指标不追踪个体用户行为。加上它采用 AGPL-3.0 开源协议支持云服务和自己部署天然适合注重隐私的团队。这些设计在当年非常有前瞻性。它证明了一件事网站统计不一定非要牺牲用户隐私也可以用很小的脚本占用换来足够支撑运营决策的数据。这也是为什么后来的很多现代替代品都要拿它做对标物。1.2 简单模型的边界Plausible 的简单既是卖点也是天花板。它的报表模型是围绕页面浏览设计的这对内容型网站、博客、营销落地页完全够用但一旦业务进入产品化阶段需求就会很快超出这个模型。举几个真实场景。第一产品团队想知道用户是否点击了某个按钮、是否完成了注册流程、在某一步停留多久这需要自定义事件和漏斗能力Plausible 虽然有 Goals 和自定义事件但表达能力和灵活性跟 PostHog 这类产品分析工具相比有明显差距。第二数据团队希望分析结果能落到自己的数仓里和订单、CRM、广告数据做关联这就需要强大的导出、API 或直连数据仓库的能力而 Plausible 的开放接口相对克制。第三运营人员希望看到秒级实时数据或者在 Edge 节点上直接完成采集和去重这时候传统自托管架构在扩展性上也会遇到瓶颈。所以你会发现市场上出现Modern Alternative to Plausible并不是因为 Plausible 做错了什么而是因为有一部分用户已经从简单统计走向了数据驱动决策他们需要保留 Plausible 的隐私友好和轻量同时获得更现代的数据基础设施。这正是新一代工具的机会所在。2. 现代替代品的现代到底指什么四个技术变量很多人以为现代只是 UI 更好看、图表更多这是误解。真正支撑现代这个说法的是 Web 分析底层逻辑的四个变化。2.1 从 Cookie 追踪到第一方数据与事件模型传统 Web 分析依赖 Cookie 把匿名用户识别出来再通过跨页面请求拼接用户行为。第三方 Cookie 被浏览器逐步禁用之后这条路越来越难走。现代工具的做法是转向第一方数据把统计脚本部署在自有域名下通过反向代理同源上报用事件模型来描述用户在页面上的每一个动作。事件模型比页面浏览更通用一条事件可以带事件名、属性、时间戳、会话上下文天然支持漏斗、留存、路径分析。这相当于把分析工具从计数器升级为行为数据采集层。2.2 从单点上报到边缘采集与 Server-Side 上报传统统计脚本是浏览器 - 分析服务器的单点链路。现代工具开始把采集逻辑放到边缘节点借助边缘函数在离用户最近的地理位置完成请求接收、基础校验、匿名化和聚合再异步写入后端存储。这样有几个好处上报延迟更低主站服务器压力更小被广告拦截器误伤的概率也可以通过自定义域名降低。另一个重要变化是 Server-Side 上报——在电商、支付、App 内 WebView 等场景里浏览器端脚本可能加载失败或被禁用服务端直接上报事件往往更可靠。现代替代品如果同时支持前端采集和服务端采集它的适用面就比 Plausible 宽很多。2.3 从 PV/UV 到 Web Vitals 体验指标PV、UV、跳出率是流量视角的指标回答的是多少人来了。但用户留下来之后体验好不好传统统计工具回答不了。2024 年起Google 把 INPInteraction to Next Paint纳入了 Core Web Vitals与 LCP、CLS 一起成为衡量页面体验的核心指标。现代分析工具普遍把 Web Vitals 作为一等公民来采集可以直接在仪表盘看到一条页面路径的 LCP、CLS、INP 分布甚至能关联到具体的设备和浏览器。这类数据对前端性能优化非常关键也是 Plausible 这类早期工具没有重点覆盖的领域。2.4 从固定报表到可编程查询和自动化分析早期工具的仪表盘是开发好什么你只能看什么。现代工具开始提供可编程的查询能力要么是类 SQL 的查询接口要么是完整的 REST API要么支持把原始数据导出到 ClickHouse、DuckDB、S3、BigQuery 等外部存储。这意味着同一个数据源既能支撑日常仪表盘也能被数据团队拉去做自定义分析还能通过 Webhook 把异常波动推送到企业内部系统。从看报表到用数据这是现代替代品在架构思维上最大的变化。从这四个变量可以看出新一代工具不是在 Plausible 旁边多加几个图表而是把隐私友好的默认值保留下来再把采集层、计算层和开放接口整体往现代数据基础设施上迁移。评估一款现代替代品是否有价值本质上是看它在这四个维度上做得够不够扎实。3. 如何评估一款 Plausible 替代品七个关键维度如果你在 Hacker News 或 GitHub 上看到一个声称是 Plausible 现代替代品的项目不要只看 README 开头的截图建议按下面七个维度逐项打分。评估维度Plausible 的基线现代替代品应该具备的能力采集方式前端脚本页面浏览为主事件模型 自定义属性 服务端上报隐私设计无 Cookie最小化 IP 处理可配置脱敏、保留期、数据主权、不采集 PII查询能力预设聚合指标API、SQL 查询、原始数据导出实时性分钟级聚合秒级实时流式数据性能开销脚本 1KB更小的脚本体积支持延迟加载和代理部署模式云服务 Docker 自托管单二进制、多架构镜像、边缘部署开放程度AGPL 开源有限 APIWebhook、事件导入、插件机制、多框架 SDK3.1 采集方式决定你能回答什么问题这是第一个要问的问题它只能统计 pageview还是能采集自定义事件判断方法很简单看文档里Event相关的页面是否完善看有没有针对 React、Vue、Android、iOS 的 SDK。如果只有一段 script 标签说明它还是传统网页统计模型。对内容站没问题对产品团队大概率不够。3.2 隐私设计决定合规成本Plausible 已经把无 Cookie做成标配但现代替代品需要在更细的粒度上给用户控制权。比如是否支持 IP 匿名化级别的配置是否允许设置数据保留期是否支持把数据存储在欧洲、美国或企业自有的基础设施里是否默认不采集 form 输入内容和 URL 里的敏感参数。要注意隐私不是一个开关而是一组配置项的集合配置项越完整团队在对接不同国家和行业合规要求时的成本就越低。3.3 查询和导出能力决定数据能不能资产化很多项目上线一段时间后团队会希望把分析数据和应用业务数据做关联。这时候就看它能不能把明细数据通过 API 拉出来或者定时导出 Parquet/CSV 到对象存储。不要只看仪表盘漂不漂亮仪表盘只是数据输出的最表层底层能不能灵活查询才决定数据长期价值。3.4 实时性决定运营响应速度Plausible 的实时性和数据刷新频率对大多数内容站够了。但如果你运营活动页面、电商大促或者做异常告警秒级到分钟级的延迟差异会很直观。评估时可以看它的实时视图是否真的是流式更新还是定时轮询看它的上报链路是否经过消息队列和流处理框架。这类架构信息通常藏在文档的 Architecture 或 Blog 里。3.5 性能开销需要自己动手测不要只看仓库里写的Lightweight。拿到项目后第一件事是把压缩后的脚本下载下来看体积再看它初始化时创建了几个请求、用了哪些三方域名。更稳的判断是直接在自己网站上做一次 Lighthouse 对比插入脚本前后各跑一次对比 LCP 和 TBT。现代替代品如果体积控制不好说得再多都白搭。3.6 部署模式决定你的运维负担对中小团队来说部署模式直接影响长期使用意愿。最舒服的是单二进制拿一个文件就能跑其次是 Docker 镜像docker compose up 就能起来最复杂的是依赖多个组件的分布式架构虽然上限高但需要专门的维护。要特别注意镜像是否同时支持 amd64 和 arm64很多团队现在的服务器已经迁移到 ARM拿到手发现没有对应镜像会很麻烦。3.7 开放程度决定未来可扩展性最后看它还留了多少扩展位。Webhook 能不能通知异常事件API Key 有没有完整的权限管理能不能方便地导入历史数据有没有插件机制。开放程度高的工具未来接入内部系统的时候不需要重新选型。4. 部署实践自托管一个隐私友好的分析服务概念清楚了接下来动手。由于不同 Show HN 项目的具体配置项不同这一章以通用模板为主演示分析服务 数据库 反向代理的经典自托管架构。你选定具体项目后把镜像名、环境变量按官方文档替换即可骨架是一样的。4.1 前置条件准备一台 Linux 服务器建议 2 核 4GB 起步系统可以是 Ubuntu 22.04/24.04 或 Debian 12。需要在服务器上安装 Docker 和 Docker Compose 插件sudo apt update sudo apt install -y ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo tee /etc/apt/keyrings/docker.asc /dev/null sudo chmod ar /etc/apt/keyrings/docker.asc echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release echo $VERSION_CODENAME) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin安装完成后验证sudo docker --version sudo docker compose version在这一步容易踩的坑有两个。一个是 Docker 官方源在某些网络环境下访问慢可以改用你所在地区的镜像源但要确保来源可信另一个是当前用户没有加入 docker 组导致每次都要 sudo正式使用时建议把部署用户加入 docker 组并重新登录。4.2 Docker Compose 最小配置在服务器上新建一个部署目录并在目录里创建 docker-compose.yml 文件# 文件路径/opt/analytics/docker-compose.yml services: analytics: image: your-analytics-image:latest restart: unless-stopped environment: APP_DOMAIN: analytics.example.com DATABASE_URL: postgres://analytics:change-medb:5432/analytics SECRET_KEY_BASE: change-me-to-a-long-random-value depends_on: - db ports: - 127.0.0.1:8000:8000 db: image: postgres:16-alpine restart: unless-stopped environment: POSTGRES_USER: analytics POSTGRES_PASSWORD: change-me POSTGRES_DB: analytics volumes: - db-data:/var/lib/postgresql/data volumes: db-data:需要注意几个配置点。APP_DOMAIN必须配置成最终对外访问的域名很多工具会用这个字段校验请求来源配置错了会导致统计脚本被拒绝SECRET_KEY_BASE用于会话和签名必须改成足够长的随机字符串可以用下面的命令生成DATABASE_URL里的密码要和 Postgres 的环境变量保持一致否则应用能启动但连接不上数据库。openssl rand -hex 64生成后填入SECRET_KEY_BASE再把change-me替换成你自己的数据库密码。启动服务cd /opt/analytics sudo docker compose up -d sudo docker compose ps看到两个服务的状态都是 running 后用docker compose logs -f analytics跟踪应用日志。如果日志里出现数据库连接错误优先检查 DATABASE_URL 和 Postgres 容器是否健康。4.3 Nginx 反向代理与 HTTPS分析服务的 Web 界面和统计脚本默认通过 HTTP 端口提供访问生产环境必须用 Nginx 做反向代理并配置 HTTPS。先安装 Nginxsudo apt install -y nginx创建站点配置文件# 文件路径/etc/nginx/sites-available/analytics.conf server { listen 80; server_name analytics.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name analytics.example.com; ssl_certificate /etc/letsencrypt/live/analytics.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/analytics.example.com/privkey.pem; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }注意X-Real-IP和X-Forwarded-For这两个头很关键。分析工具依赖它识别访客的真实 IP 来做地域统计和去重如果漏掉所有访客都会显示成 Nginx 所在服务器的 IP统计数据会完全失真。先用 Certbot 申请证书再启用站点sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d analytics.example.com申请过程中如果失败最常见原因是域名还没有解析到这台服务器或者云厂商安全组没有放行 80 端口。解决后重新执行 certbot。最后启用配置并重载sudo ln -s /etc/nginx/sites-available/analytics.conf /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx到这里一个自托管的分析服务就跑起来了浏览器访问https://analytics.example.com应该能看到登录入口或初始化向导。5. 前端接入无 Cookie 统计脚本的最小实现部署完服务接下来的关键动作是把统计脚本接入你的网站。下面用一段简化示例解释无 Cookie 上报的原理方便你理解后续配置工具时遇到的各种参数。5.1 上报原理传统统计依赖 Cookie 在每次请求之间记住用户无 Cookie 方案则刻意避免持久化标识。它做的事情是页面加载时发送一条包含域名、路径、来源、屏幕宽度的数据后端拿到后用 IP、User-Agent 等信息做临时性去重完成聚合后丢弃敏感字段。整个过程不写 Cookie、不读取浏览器指纹库、不生成跨站追踪 ID。正因如此这类工具才可以宣称不需要弹 Cookie 同意框。5.2 最小脚本实现// 文件路径public/js/analytics.js (function () { var endpoint /api/event; var data { domain: location.hostname, path: location.pathname location.search, referrer: document.referrer, width: window.innerWidth }; if (navigator.sendBeacon) { navigator.sendBeacon( endpoint, new Blob([JSON.stringify(data)], { type: application/json }) ); } else { fetch(endpoint, { method: POST, body: JSON.stringify(data), headers: { Content-Type: application/json }, keepalive: true }); } })();上面的代码不是某个具体产品的实现而是无 Cookie 上报通用的骨架。注意两个技术点。一是首选navigator.sendBeacon它在页面卸载时也能尽量把请求发出去适合统计这种最后一步上报二是上报地址用同源路径/api/event实际项目中建议通过 Nginx 把analytics.example.com/api代理到和站点同源的路径浏览器就不会以为你在连接第三方域名也更容易通过 CSP 限制。在你的 HTML 中引入script>// 文件路径src/hooks/usePageView.js import { useEffect } from react; import { useLocation } from react-router-dom; export default function usePageView() { const location useLocation(); useEffect(() { if (window.analytics typeof window.analytics.track function) { window.analytics.track(location.pathname location.search); } }, [location]); }在路由配置的根组件里调用一次usePageView()即可。这里真正容易踩坑的地方是路由守卫、重定向和登录跳转可能导致事件重复上报或丢失调试时要把上报逻辑和路由变动日志放在一起看。6. 运行结果与效果验证部署和接入做完不能只看看起来在运行要按数据链路逐层验证。6.1 验证服务状态先确认容器和端口状态sudo docker compose ps curl -I http://127.0.0.1:8000预期输出里HTTP/1.1 200 OK说明应用本身正常。如果返回 502一般是应用没起来或端口映射不对如果返回 503先看数据库迁移是否完成多数工具会在首次启动时自动建表。6.2 验证脚本与数据链路用 curl 模拟一次脚本请求和事件上报curl -I https://analytics.example.com/js/analytics.js curl -X POST https://analytics.example.com/api/event \ -H Content-Type: application/json \ -d {domain:example.com,path:/test}脚本请求返回 200 且响应体是 JavaScript说明静态资源没问题。POST 返回后去仪表盘的实时视图刷新如果能看到example.com下多了一条访问记录说明从浏览器到分析服务的全链路是通的。如果没有数据先看 Nginx 的访问日志sudo tail -f /var/log/nginx/access.log如果 Nginx 收到了请求但应用没有写入数据再去查应用日志如果 Nginx 根本没收到问题在前端脚本或浏览器拦截。6.3 验证隐私表现这一步很多人会忽略。打开浏览器 DevTools 的 Application 面板查看 Cookies访问并刷新页面数次后应该看到站点域名下没有任何由统计脚本写入的 Cookie。再看 Network 面板刷新页面时统计脚本应该只产生一条上报请求而不是像传统统计那样有十几条并发请求。最后如果你开了隐私窗口统计数字应当仍然正常工作。这两点都通过说明工具在隐私承诺上是言行一致的。7. 常见问题与排查思路自托管分析工具的坑大部分集中在部署环境、反向代理和浏览器安全策略上。下面这张表覆盖了最常遇到的几类问题。问题现象可能原因排查方式解决方案页面访问后仪表盘没有数据脚本被广告拦截器拦截或 CSP 禁止了脚本加载DevTools Network 面板看脚本是否加载成功Console 看 CSP 警告将脚本改为同源代理路径并在 CSP 的 script-src 中放行自己访问不计数工具默认过滤了本机访问或无 referrer 的请求用手机 4G/5G 网络访问测试查看实时会话在配置中关闭本地过滤或调整 referrer 判定规则上报请求发出去了数据仍为空后端事件解析失败字段格式不匹配查看应用日志打印收到的原始请求体检查前端上报 payload 与文档要求的字段名是否一致Docker 容器反复重启数据库连接失败或端口冲突docker compose logs db查看数据库日志修正 DATABASE_URL 密码或修改宿主机端口映射Nginx 返回 502应用服务没有监听预期端口docker compose ps查看端口映射检查 compose 里的 ports 与 nginx proxy_pass 是否一致HTTPS 证书过期certbot 续期任务未配置sudo certbot renew --dry-run配置 cron 或 systemd timer 自动续期统计数字和 Google Analytics 差异大去重口径、过滤规则、JS 加载时机不同对比两个工具的 unique visitor 定义以一套工具为准关注趋势价值而非绝对值遇到问题不要一项项盲试按这条路径排查先看浏览器 Network 请求是否发出再看 Nginx 日志是否收到最后看应用日志是否处理链路中哪一层断了就修哪层。90% 的接入问题都落在浏览器拦截、反向代理配置和字段格式这三处。8. 最佳实践与工程建议把工具跑起来只是开始真正拉开使用效果差距的是接入和运维的规范程度。8.1 采集层建议统计脚本建议放在head里并使用defer避免影响 LCP不要用同步脚本阻塞渲染。对 SPA 项目要专门处理路由上报否则 PV 数据会严重偏低。事件命名统一用snake_case例如signup_submit、search_focus不要用带空格和中文的随机描述。如果你同时采集 Web Vitals建议把 LCP、CLS、INP 作为独立事件上报并带上device_type和connection_efftype属性方便后续定位性能问题。8.2 数据与合规层建议无论工具多隐私友好上线前都应该更新网站的隐私政策明确说明采集了哪些匿名数据、用途是什么、保留多久。不要为了省事在 URL 中透传用户邮箱、手机号等敏感参数统计工具会把它当作 path 的一部分原样接收。数据保留期按业务需要设置默认越短越好能关闭的地理细分功能尽量关闭除非运营真的需要按地区投放内容。8.3 运维与安全层建议生产环境务必用最小权限原则数据库不暴露公网端口只用 Docker 内部网络连接管理后台开启 HTTPS 和强密码有条件的话开启二步验证SECRET_KEY_BASE不要写死在仓库里放到.env文件或密钥管理服务中。升级工具前先把数据目录完整备份一次很多自托管工具不存在平滑迁移工具链升级失败时恢复数据比重新部署复杂得多。对上报接口要关注日志中是否有异常请求量如果某个路径出现远超正常水平的 POST要考虑是否被攻击者刷数据。8.4 从 Plausible 迁移的灰度路径如果团队已经在用 Plausible想换到现代替代品不建议直接关掉旧服务。更稳妥的做法是并行采集在新工具里接入同一批站点两边同时跑一到两个发布周期先对比指标口径确认新工具的数据可用后再切换。迁移前要重点确认两件事一是历史数据是否能导出归档二是新工具能否导入 Plausible 的导出数据。如果新工具没有导入能力历史数据就只能在旧系统里留档算力成本和数据割裂要提前评估。9. 总结与选型建议回到最初的问题面对 Show HN: Modern Alternative to Plausible 这类项目你应该怎么判断如果你只是一个内容站或博客Plausible 目前已经够用不建议为了追新去换。它的简单模型恰恰是优点维护成本低、隐私边界清晰、没有过度设计。但如果你是产品团队需要自定义事件、漏斗分析、Web Vitals、API 导出和服务端上报那么认真评估一款现代替代品是值得的。评估时不要看截图和 Star 数而是按采集方式、隐私设计、查询能力、实时性、性能开销、部署模式、开放程度这七个维度逐项打分最好能花一个下午把最小环境部署起来用真实页面流量跑两三天。对这类新项目还有一个额外的提醒Show HN 阶段的项目往往由小团队甚至个人维护License 是否对商用友好、Issue 响应速度、文档完善度、升级兼容性都要在选型时一并确认。可以先用小流量站点试用不要在核心业务上做第一批吃螃蟹的人。下一步建议很具体挑一个你感兴趣的替代品拿到它的 Docker 镜像用本文第四章的模板部署到一个测试服务器按第五章接入一个非核心页面然后用第七、八章的排查和规范清单做一次完整校验。数据工具的选择从来不是一步到位的先用起来再用真实需求验证最后再决定要不要长期依赖它。