网站统计这东西有个长期没解的矛盾：装了 Google Analytics，得弹一个同意条，后台几十个报表却很难一眼看出「上周改的那版落地页到底有没有变好」；换成极简的计数器，隐私问题是没了，可流量从哪来、在哪一步流失、哪些页面报错，又全得靠猜。Rybbit 想补的就是中间这一档——不用 Cookie、可以完全自己托管，但分析能力不缩水。
项目在 GitHub 上已有 1.3 万余星、770 余次 fork，采用 AGPL-3.0 协议，2025 年初建仓，目前版本 v2.9.2（2026 年 10 月发布）。它有两种形态：官方托管的 Cloud 版，以及把整套服务跑在自己 VPS 上的自托管版。官方还给了一个跑了真实生产站点的在线演示，可以直接进去点。
一、先把「无 Cookie」讲清楚
Rybbit 的隐私友好不是一句口号，而是落在指标定义上的。它不写 Cookie，也不存可识别个人身份的信息：用户 ID 由访客 IP 与浏览器 User-Agent 的哈希生成，用来区分「是不是同一个人」，但哈希本身不含姓名、账号或邮箱。会话以同一用户 ID 的 30 分钟无操作为界；跳出率定义为「只有一次页面浏览的会话占比」，注意点击按钮、触发自定义事件都不算互动，一次浏览后点了个按钮依然计为跳出。
采集的维度却不少：页面路径、标题、来源 referrer、UTM 五参数、渠道归类（直接访问、搜索、社交、邮件、引荐），浏览器与版本、系统与版本、语言、屏幕尺寸、设备类型，以及基于 IP 归属地的国家 → 地区 → 城市三级定位。官方说高级筛选支持 15 个以上维度，自定义事件还能带 JSON 属性。换句话说，它砍掉的是跨站追踪与持久标识，不是分析粒度。
需要提醒一句：无 Cookie 只是降低合规负担，不等于「随便埋」，会话回放这类功能尤其要在站内告知，后面会讲到遮罩配置。
二、界面：五个维度看同一批数据
Rybbit 的后台是一套深色工作台，左侧导航按网站分析 / 产品分析 / 行为 / 设置分组，顶部是全局筛选器和日期区间。主仪表盘把独立访客、会话数、浏览量、每会话页数、跳出率、会话时长六个指标并排摆开，每个都带环比；下面是按小时或天聚合的趋势曲线，再往下是浏览器、设备、系统、屏幕尺寸与页面、标题、入口页、退出页的明细表。
Globe 视图是它比较出彩的一块：地图上按位置聚合气泡，点开一个访客能看到来源、渠道、设备、会话时长与页面数，底部还有可播放的时间轴，能看访问量随时间在地理上的变化。地图支持 3D 展示，自托管时想启用需要自备 Mapbox 令牌。README 的对比表里也把「高级地图」列成了别家普遍没有的一项。
会话回放是三栏布局：左侧按时间列出可回放的会话（时长、页面、浏览器、操作系统、事件数），中间是页面重放窗口配播放进度条和倍速，右侧是按秒铺开的事件流——视口变化、滚动、点击、DOM 变更逐条记录。它的定位是排查「用户到底在哪卡住了」，而不是做监控录像。
三、从流量到转化：漏斗、旅程、留存
光看 PV 不够，Rybbit 把产品分析那条线也做齐了。目标定义一次转化（访问某页面或触发某个自定义事件），漏斗把多个步骤串起来算每一步转化率和流失人数，用户旅程看访客在站点内的实际路径，留存看回访，分群把常用筛选条件存成可复用的视图。
漏斗页把「整体转化」和「相对上一步转化」用两种颜色区分，每一步直接标出掉了多少人。官方示例里一个四步漏斗从 6607 人走到 182 人，首步到第二步就掉了 5442 人——这种呈现方式比让你自己去减两个数直观得多。
用户档案页也体现了它的隐私设计：列表里是「Pink Magpie」「Salmon Bison」这类匿名代号，配上国家、渠道、浏览器、系统、设备和浏览量，点进去才是这个 ID 的完整会话时间线。另有错误跟踪页收 JavaScript 异常与未处理的 Promise 拒绝，事件页列自定义事件，图表上还能打标注，把发版、故障钉在流量曲线上；组织内多站点可以用 Rollup 一页汇总。
四、README 之外：它已经不只是统计工具了
如果只看仓库首页会低估这个项目。翻官方文档会发现，v2.x 之后它往「产品实验平台」方向走了不短一段：
| 能力 | 说明 |
|---|---|
| 功能开关 | 布尔型、多变体、远程配置三类，可在浏览器、服务端或两端同时求值；开关结果会附到分析事件上，因此能直接按开关值筛选和对比行为 |
| A/B 实验 | 建在多变体开关之上：先给访客稳定分组，再以目标为转化，自动算各变体转化率、相对对照组的提升与置信度 |
| MCP 服务 | 让 AI 助手直接查询站点数据，自托管实例也能通过 run_query 工具跑自定义 SQL |
| 开放 API | 覆盖会话、事件、用户、漏斗、留存、错误、实时流、周报、Search Console 等；另有发送事件接口，可从服务端上报 |
| 数据导入 | 支持从 Umami、Simple Analytics、Plausible 迁移历史数据 |
| 其他 | 机器人识别、过滤自己的流量、公开仪表盘、键盘快捷键与命令面板、图表标注、自定义仪表盘 |
埋点本身是一段放在页面 head 里的脚本，站点 ID 走 URL 参数传递——官方特意说明这个写法比 data-* 属性可靠，因为某些 WordPress 优化插件会重建脚本标签并丢掉自定义属性。脚本加载时会自动拉取站点设置：SPA 路由、出站链接、按钮点击、表单交互、复制文本、错误捕获、会话回放、Web Vitals 都是可开关项，默认只开页面浏览、SPA 导航、查询串和出站链接。
隐私上还有几层控制值得单独提：data-skip-patterns 让匹配路径完全不上报，data-mask-patterns 把路径替换成模式串再上报，data-tag 给一批事件打标签做分组对比。但官方明确警告，跳过与遮罩规则只作用于事件，会话回放仍会记录完整 URL，要屏蔽回放里的页面内容得另配回放专用的 block 与 mask 属性。这段说明写在文档里，实操时别漏。
五、技术栈与自托管
自托管不是「一个容器跑完」，而是一套六容器的组合。按仓库里的 compose 文件核对：
| 组件 | 版本 / 作用 |
|---|---|
| ClickHouse 26.3 | 事件主存储，海量明细查询靠它 |
| PostgreSQL 17.4 | 站点、组织、账号、目标与配置等关系数据 |
| Redis 8.6 | 缓存与实时状态 |
| 后端 / 前端 | 官方预构建镜像，分别对应 Node 服务与 Web 界面 |
| Caddy 2.10 | 默认自带的 Web 服务器，自动申请证书 |
源码是 pnpm workspace 单体仓库，分 client、server、shared、react-native 几块，Node 要求 22.13 以上，包管理器锁定 pnpm 10.33；文档站另是一个 Next.js + Fumadocs 应用。这个配置决定了它对机器有点要求——官方建议 至少 2GB 内存的 VPS，一块已解析到服务器 IP 的域名，且必须走 HTTPS（浏览器会拦截不安全来源的统计脚本）。部署指引在 Ubuntu 24.04 x86_64 上验证过，ARM 机器需至少 ARMv8.2-A 才支持 ClickHouse。
标准路径很省事：装好 Docker，克隆仓库，把仓库里的脚本设为可执行，然后运行 setup 脚本并传入域名；脚本会生成环境变量（含随机密钥）、拉取预构建镜像并拉起容器，Caddy 随后自动签证书，最后访问域名的注册页建管理员账号即可。已有自己的 Web 服务器或需要自定义端口时，仓库提供手动 Compose 与进阶部署文档；setup 脚本也支持关闭内置 Web 服务器、指定后端与前端端口、传入 Mapbox 令牌。
六、Cloud 与自托管怎么选
官方自己列了一张对照表，两边差异比「一个收费一个免费」要具体得多：
| 项目 | Cloud 版 | 自托管版 |
|---|---|---|
| 上手时间 / 维护 | 几分钟，无需运维 | 约 30–120 分钟，需自己升级 |
| 核心分析能力 | 完整 | 完整（漏斗、目标、会话、旅程、用户、留存、错误跟踪、组织团队都有） |
| 会话回放 | Pro 套餐 | 直接包含 |
| Pages 视图、Web Vitals | 有 | 无 |
| 邮件报告、Search Console、Bots 页 | 有 | 无 |
| 自定义 SQL 与仪表盘 | 有 | 默认无，但可自建前端镜像开启；MCP 查询可用 |
| 第三方登录、邀请邮件、找回密码 | 有 | 无邮件能力，管理员在组织设置里直接建账号 |
所以取舍很直白：想零运维、要邮件周报和性能数据，选 Cloud；想让数据完全留在自己机器上、又要全量会话回放，选自托管。自托管的「无邮件」这点容易被忽略——忘记密码没有自助找回，得由管理员重置，团队人数多的话要提前想好账号流程。
七、适合谁，以及几个前提
它适合已经有稳定流量、想把「从哪来 → 看了什么 → 在哪流失」串起来看的站点，尤其适合不想碰 Cookie 同意条、又嫌极简计数器信息量太少的人。从别的开源统计工具迁过来也方便，历史数据能导入。
反过来，三种情况要慎重：一是只要一个 PV 数字，为了它养 ClickHouse、PostgreSQL、Redis 加两个应用容器并不划算；二是需要邮件通知或自助找回密码的自托管场景，官方目前不提供；三是商业二次分发——AGPL-3.0 的传染性比 MIT 强，修改后对外提供网络服务需注意开源义务。此外，会话回放与错误跟踪会采集页面交互，上线前应按业务配好回放遮罩和路径跳过规则，并在隐私说明里写清楚。
和同赛道的 Plausible、Umami 相比，Rybbit 更靠「产品分析」那一侧：地图、回放、漏斗、用户档案、实验与功能开关叠在一起，界面却维持在一套导航能走完的复杂度。对一个 2025 年才起步的项目来说，这个完成度挺少见。
本文整理自公开资料：项目仓库 README、官方文档（指标定义、埋点脚本、自托管指引、Cloud 与自托管对照、功能开关与实验）、docker-compose.yml 与 package.json，以及仓库内官方界面截图。数据截至 2026 年 11 月，功能与版本以官方更新为准。配图为项目自带截图，仅做格式统一与尺寸压缩。
本文整理自公开资料并做重写，原始出处：https://github.com/rybbit-io/rybbit。文中配图已去除站点叠加水印与推广信息；版权归原作者所有。