Umami：开源自托管网站统计，无 Cookie 的 Google Analytics 替代
每个做独立站或小型项目的开发者迟早会遇到一个问题：用 Google Analytics 担心合规与性能，用 Plausible 之类的云服务又想把数据握在自己手里。Umami 是这个清单里反复出现的名字——一个以隐私优先为卖点的开源网站分析工具，MIT 协议，自托管，部署一个 Node 服务加一个数据库就能跑起来。
> “Umami is a simple, fast, privacy-focused alternative to Google Analytics.” —— 项目自述
它的核心定位是替代 GA 但不依赖 Cookie、不采集可识别个人身份的信息，因此大多数情况下无需在网站上挂 Cookie 横幅。
核心特性
- 不依赖 Cookie：访客标识不写入浏览器，符合 GDPR / CCPA 等隐私法规的常见要求
- 轻量脚本：跟踪脚本体积小，对页面加载速度影响有限
- 多站点管理：一个后台可以挂多个网站域名，分别查看数据
- 常规指标齐全：页面浏览（PV/UV）、来源、地理位置、设备/浏览器、会话时长等
- 实时数据：可以看到当前在线的访客和正在浏览的页面
- 自定义事件：除页面浏览外，可以追踪按钮点击、表单提交等
- 可分享看板：可以把单个站点的统计页面通过链接分享给非管理员
对于中小型网站、内容博客、独立开发者项目，Umami 提供的能力基本够用。
部署准备
根据官方 README，源码部署需要满足：
- Node.js 18.18+
- PostgreSQL 12.14+（需提前准备好数据库实例）
如果你不想自己维护 Node 环境和数据库，Docker 部署更省事，只需一台装了 Docker 与 Docker Compose 的服务器即可。
源码部署
先把代码拉下来并安装依赖：
git clone https://github.com/umami-software/umami.git
cd umami
pnpm install接着在项目根目录新建一个 .env 文件，填入数据库连接字符串：
DATABASE_URL=postgresql://username:mypassword@localhost:5432/mydb其中 username、mypassword、mydb 替换成你实际数据库的凭证和库名。如果想修改内部 UI API 调用的基础路径，可以加一个 API_URL 环境变量，比如 API_URL=/internal-api（走 BASE_PATH 下的相对路径），或者 API_URL=https://api.example.com/api（指向完全独立的域名）。
然后执行构建：
pnpm run build这一步会根据 .env 里的配置在数据库中创建必要的表。首次部署还会自动生成一个默认管理员账号：用户名 admin，密码 umami（首次登录后务必修改）。
最后启动服务：
pnpm run start默认监听 http://localhost:3000。生产环境通常用 Nginx 做反代对外提供服务，而不是直接暴露 3000 端口。
后续更新版本时按以下顺序操作即可：
git pull
pnpm install
pnpm buildDocker 部署
如果想跳过 Node 环境配置，Docker 是最省心的方式。官方维护的镜像可以直接拉取：
docker pull docker.umami.is/umami-software/umami:latest也可以用项目自带的 Compose 文件一键启动（Compose 会同时拉起 Umami 和一个 PostgreSQL）：
docker compose up -d启动后访问 http://:3000，用默认账号登录即可。Docker 部署的更新方式：
docker compose pull
docker compose up --force-recreate -d
> Docker Compose 方式默认配置里的数据库账号、密码都是公开示例值，正式上线前请务必修改；docker compose.yml 中端口、卷挂载路径也建议根据实际环境调整。
基础使用流程
部署完成后，常见的上手路径是：
- 用
admin / umami登录后台 - 进入「设置」修改默认密码
- 在「网站」页面点击 Add website，填入站点名称和域名
- 系统会生成一段跟踪脚本（含
data-website-id），复制粘贴到你要统计的网站 “ 里 - 等待几分钟，刷新后台即可看到访问数据
{{图：添加新站点的表单界面，填入名称和域名的输入框}}
跟踪脚本支持两种加载方式：直接同步加载，或者加上 async / defer 异步加载，后者对页面渲染的阻塞更小。如果你的站点启用了 CSP，记得在策略里把 script-src 放行 Umami 的域名。
进阶用法
- 自定义事件：在跟踪脚本之外，可以调用
umami.track('事件名', { key: 'value' })来记录任意事件，例如按钮点击、视频播放、表单提交等 - 实时面板：可以查看”此刻”在线的访客数、最近访问的页面、来源国家等
- 多用户与权限：可以邀请其他用户，按角色分配网站访问权限
- 数据导出：支持通过 API 把数据拉出来自行做长期归档
- 可分享看板：把单个站点的统计页面以只读链接分享给非管理员
{{图：Umami 仪表盘总览界面，展示访客趋势折线图和来源饼图}}
{{图：实时访问面板，列出当前在线访客的国家、设备与正在浏览的页面}}
Umami vs Plausible：怎么选
两个项目定位高度相似，都是隐私优先、开源、Cookieless 的网站统计，也都经常出现在”GA 替代品”清单上。差异主要在生态和部署模式上：
| 维度 | Umami | Plausible |
|---|---|---|
| 协议 | MIT | AGPL（云版另算） |
| 自托管 | 官方支持，文档完善 | 社区有自托管方案 |
| 云托管 | 官方提供 Umami Cloud | 官方主推 Plausible Cloud |
| 技术栈 | Next.js + Node + PostgreSQL | Elixir + ClickHouse（自托管） |
| 部署难度 | 中等，依赖 Node 和 PG | 偏简单（Plausible Cloud） |
| 自定义事件 | 支持 | 支持 |
| 收入化方向 | 商业云服务 + 自托管 | 商业云服务 |
如果你的服务器上已经有 Node 和 PostgreSQL，Umami 自托管的门槛相对可控，且 MIT 协议在二次分发和定制上限制更少。如果不想碰服务器、希望几秒钟就能用上，Plausible Cloud 体验更顺。
简单说：Umami 适合”我想自己掌握数据、愿意折腾”的场景；Plausible Cloud 适合”我只想看几个数字”的场景。
适合谁用
- 独立开发者和个人博客：不想被 GA 的弹窗和合规问题打扰
- 中小企业官网：数据量不大，需要基本的访问分析
- 注重隐私的站点：欧洲用户多、合规要求严格的行业
- 已经在用 Plausible 但希望自托管：可以作为迁移候选
- 多站点运营者：希望一个后台集中管理多个域名的数据
一些注意事项
- 官方文档写的是 PostgreSQL 12.14+；如果服务器系统较老，先确认下数据库版本
- 跟踪脚本需要正常联网才能上报数据，部署在内网或受限网络环境时注意连通性
- 默认账号
admin / umami是公开信息，首次登录后必须改密码，否则等于裸奔 - 涉及多服务器、多域名时，注意
BASE_PATH与反代配置，否则会出现资源 404 - 跨实例迁移、备份恢复的具体操作建议以官方文档为准
总的来说，Umami 是一个”够用、好用、不烦人”的选择。它没有 GA 那么花哨的漏斗、细分维度与机器学习洞察，但对于绝大多数中小型网站来说，PV/UV、来源、事件这几项已经能回答大部分”流量从哪来、用户在看什么”的问题。把数据放在自己手里的安心感，是它最值得被选中的理由。
评论(0)