15.3 Umami 数据统计
文档摘要
title: "15.3 Umami 数据统计" description: "用数据理解你的用户" 15.3 Umami 数据统计 上线不是结束，而是理解的开始。数据告诉你"发生了什么"，用户反馈告诉你"为什么发生"。 小明看到了数据 小明打开第十四章装好的 Umami 面板，看到数据开始跳动——页面浏览量、独立访客、来源分布…… "原来真的有人在用我的网站！" 这种感觉和写代码完全不同。写代码的时候，你面对的是编辑器和终端；但看到真实的访问数据时，你突然意识到屏幕那头有真实的人在使用你做的东西。小明盯着面板看了半天，看着"当前在线"的数字从 0 跳到 1，又从 1 跳到 2，比任何 都让人兴奋。 但兴奋过后，他发现自己不知道这些数字意味着什么。"今天有 47 个页面浏览量，这算多还是少？
title: "15.3 Umami 数据统计" description: "用数据理解你的用户"
15.3 Umami 数据统计
上线不是结束，而是理解的开始。数据告诉你"发生了什么"，用户反馈告诉你"为什么发生"。
小明看到了数据
小明打开第十四章装好的 Umami 面板，看到数据开始跳动——页面浏览量、独立访客、来源分布……
"原来真的有人在用我的网站！"
这种感觉和写代码完全不同。写代码的时候，你面对的是编辑器和终端；但看到真实的访问数据时，你突然意识到屏幕那头有真实的人在使用你做的东西。小明盯着面板看了半天，看着"当前在线"的数字从 0 跳到 1，又从 1 跳到 2，比任何 console.log 都让人兴奋。
但兴奋过后，他发现自己不知道这些数字意味着什么。"今天有 47 个页面浏览量，这算多还是少？""跳出率 68%，这是好还是坏？""来源里 Social 占了 80%，这说明什么？"
老师傅说："数据本身没有意义，要看你怎么解读它。"
为什么需要网站统计
在没有数据之前，你对用户的了解全靠猜测。你觉得首页设计得不错，但不知道用户是不是真的在首页停留了；你觉得某个功能很有用，但不知道有没有人真的在用它。
网站统计回答的是产品运营最基本的问题：
| 问题 | 统计数据 |
|---|---|
| 有多少人访问？ | 页面浏览量（PV）、独立访客（UV） |
| 他们从哪里来？ | 来源网站、搜索关键词、社交平台 |
| 用什么设备？ | 设备类型、操作系统、浏览器 |
| 哪些页面受欢迎？ | 页面浏览排行 |
| 用户停留多久？ | 会话时长、跳出率 |
这些数据不是用来"炫耀"的（"我的网站今天有 1000 PV！"），而是用来做决策的。比如：
- 如果 80% 的用户用手机访问，但你的移动端体验很差——你知道该优先优化什么了
- 如果某个页面的跳出率特别高——说明用户来了就走，页面内容可能没有满足他们的期望
- 如果大部分流量来自社交分享而不是搜索引擎——说明 SEO 还需要时间，但 OG 配置（15.1）确实有效
没有数据，你只能靠猜。有了数据，你能做出有依据的决策。
为什么选 Umami
市面上的网站统计工具很多，最知名的是 Google Analytics（GA）。但对个人开发者来说，Umami 是更好的选择。
| 对比 | Umami | Google Analytics |
|---|---|---|
| 部署方式 | 自托管，数据在你自己的服务器上 | 云服务，数据在 Google 的服务器上 |
| 隐私 | 不使用 Cookie，不追踪个人身份 | 详细的用户追踪，需要 Cookie 同意弹窗 |
| 脚本大小 | < 1KB，几乎不影响页面加载 | ~45KB，对性能有可感知的影响 |
| 界面 | 简洁直观，打开就能看懂 | 功能强大但复杂，学习曲线陡峭 |
| 数据所有权 | 完全属于你 | 归 Google 所有 |
| 费用 | 自部署免费 | 免费版有限制，高级版收费 |
Umami 的哲学是"够用就好"。它不会告诉你用户的年龄、性别、兴趣爱好（GA 可以），但它会告诉你最重要的东西：有多少人来了、从哪来的、看了什么、用什么设备。对于个人项目和小型产品，这些信息已经足够指导你的决策了。
而且，因为 Umami 不使用 Cookie，你不需要在网站上放那个烦人的"本站使用 Cookie，请同意"弹窗。这对用户体验是一个实实在在的加分。
快速上手
第十四章已经通过 1Panel 应用商店安装好了 Umami。如果你还没装，回到 14.5 实用应用 按步骤安装。
首次登录
Umami 的默认登录信息是：
- 用户名：
admin - 密码：
umami
登录后第一件事：改密码。 这个默认密码全世界都知道，不改的话等于把你的统计面板公开了。
添加网站并集成追踪代码
登录后，在 Settings → Websites 中点击"Add website"，填入你的网站名称和域名。保存后，Umami 会生成一段追踪代码：
<script defer src="https://你的umami地址/script.js" data-website-id="你的网站ID"></script>
把这段代码加到你网站的全局布局文件中。Next.js 项目加到 layout.tsx 的 <head> 里，VitePress 项目加到配置文件的 head 数组里。重新部署后，Umami 就开始收集数据了。
小明加完追踪代码，重新部署，然后自己访问了几次网站。回到 Umami 面板一看——数据已经开始跳动了。虽然都是他自己的访问记录，但看到系统真的在工作，还是挺有成就感的。
老师傅教小明看指标
数据开始积累后，小明每天都会打开 Umami 面板看一眼。但他发现自己只是在"看数字"，并不真正理解这些数字在说什么。
老师傅坐下来，一个一个给他讲。
访问指标：最基础的四个数字
| 指标 | 说明 |
|---|---|
| Pageviews（浏览量） | 所有页面被浏览的总次数。一个用户看了 3 个页面，就是 3 次 PV |
| Unique Visitors（访客） | 有多少不同的人访问了你的网站。同一个人刷新 10 次还是算 1 个 UV |
| Visits（访问次数） | 会话数。一个用户上午来一次、下午来一次，算 2 次 Visit |
| Bounce Rate（跳出率） | 只看了一个页面就离开的访客比例 |
这四个数字组合起来能告诉你很多事情。比如：
- PV 高但 UV 低：说明少数用户在反复访问，你有一批忠实用户
- UV 高但 PV/UV 比低：说明很多人来了只看一个页面就走了，内容可能没有吸引力
- 跳出率高：不一定是坏事——如果你的网站是单页应用或者博客，用户看完一篇文章就走是正常的。但如果是电商网站，高跳出率就需要关注了
流量来源：用户从哪来
| 来源 | 说明 |
|---|---|
| Search | 通过搜索引擎来的——这是 15.2 SEO 的成果 |
| Social | 通过社交媒体来的——这是 15.1 OG 分享的成果 |
| Direct | 直接访问——用户手动输入 URL 或从收藏夹点击 |
| Referral | 从其他网站的链接点过来的 |
流量来源的分布能帮你判断哪个渠道最有效。小明看了自己的数据，发现大部分流量来自 Social（社交分享）——看来 15.1 配的 OG 卡片确实有效，朋友们分享的链接带来了不少点击。但 Search（搜索引擎）的流量还很少，这很正常——SEO 需要几个月才能见效。
如果你发现 Direct 流量占比很高，说明有一批用户已经记住了你的网站地址，这是好事。如果 Referral 流量突然增加，去看看是哪个网站链接了你——也许有人在博客里推荐了你的产品。
设备信息：用户用什么访问
| 指标 | 说明 |
|---|---|
| Browser | Chrome、Safari、Firefox……哪个浏览器最多 |
| OS | Windows、macOS、iOS、Android…… |
| Device | 桌面、移动、平板 |
设备信息直接影响你的开发优先级。如果 70% 的用户用手机访问，你就应该优先优化移动端体验。如果大部分用户用 Chrome，你可以放心使用一些较新的 Web API。
主要指标 vs 虚荣指标
数据积累了一段时间后，小明兴奋地跟老师傅说："我的网站这个月有 5000 PV 了！"
老师傅没有表现出预期的惊喜，反而问了一句："所以呢？你打算做什么？"
小明愣住了。
"这就是虚荣指标的问题，"老师傅说。"数字看起来很好看，但它不能指导你的下一步行动。"
| 主要指标（可行动） | 虚荣指标（好看但没用） |
|---|---|
| 留存率——用户会不会回来 | 总浏览量——大不代表好 |
| 转化率——用户会不会注册/购买 | 访客总数——来了不代表留下 |
| 活跃用户——真正在用的有多少 | 页面停留时长——可能只是忘了关标签页 |
判断标准很简单：看到一个数据后，你知道下一步该做什么吗？
- "总浏览量涨了 20%" → 所以呢？不知道该做什么。（虚荣指标）
- "注册转化率从 5% 降到 2%" → 检查注册流程是不是出了问题，最近改了什么？（可行动指标）
- "首页跳出率从 30% 升到 60%" → 首页内容可能需要调整，或者新来的流量质量不高。（可行动指标）
小明开始理解了：数据的价值不在于数字本身，而在于它能不能帮你做出更好的决策。
事件追踪：超越页面浏览
除了自动收集的页面浏览数据，Umami 还支持自定义事件追踪。比如你想知道有多少人点击了"注册"按钮、有多少人下载了你的 PDF、有多少人点击了分享按钮。
实现方式有两种：
- 在 HTML 元素上加
data-umami-event="事件名"属性——最简单，不需要写 JS - 用
window.umami.track('事件名', { 属性: '值' })API——更灵活，可以附带额外信息
需要追踪什么事件，告诉 Claude Code 即可。但老师傅提醒小明：不要追踪所有东西。只追踪那些能帮你做决策的事件——比如核心转化路径上的关键步骤。追踪太多反而会让你淹没在数据里，分不清主次。
数据驱动决策：看到数据后该做什么
收集数据只是第一步，更重要的是用数据来指导行动。
小明积累了一个月的数据后，发现了几个有意思的现象：
- 移动端用户占 65%，但他之前一直在桌面端开发和测试，移动端的一些交互体验其实不太好
- "关于"页面的跳出率高达 90%——用户看完就走了，没有继续浏览其他页面
- 周三和周四的流量明显高于其他日子——可能和他在社交媒体发帖的时间有关
这些发现直接转化成了行动：
- 优先修复移动端的交互问题
- 在"关于"页面底部加上其他页面的链接，引导用户继续浏览
- 把社交媒体发帖时间调整到周三周四，效果最好的时候加大力度
这就是数据驱动决策的意义。不是为了看数字，而是为了发现问题、验证假设、指导行动。
隐私保护：Umami 的核心优势
在收集用户数据的同时，隐私保护是一个不能忽视的话题。
Umami 的设计从一开始就把隐私放在核心位置：
- 不使用 Cookie——不需要那个烦人的 Cookie 同意弹窗
- 不追踪个人用户身份——Umami 不知道"张三今天来了 3 次"，它只知道"今天有 X 个独立访客"
- 不收集可识别的个人数据——不记录 IP 地址（或只记录哈希后的版本）、不记录用户代理的完整字符串
- 数据完全存储在你自己的服务器上——不会发送到任何第三方
这意味着 Umami 天然符合 GDPR（欧盟数据保护法）的大部分要求。你不需要在网站上放 Cookie 弹窗，不需要让用户"同意被追踪"，因为你根本没有在追踪个人用户。
但这并不意味着你完全不需要关心隐私合规。如果你的网站还收集了其他用户数据——比如注册时的邮箱地址、用户提交的表单信息——你仍然需要一份隐私政策来说明这些数据的用途。这就是下一节要讲的内容。
常见问题
Q1: Umami 和 Google Analytics 可以同时用吗？
技术上可以，但对个人项目没必要。Umami 已经覆盖了核心需求，多加一个统计脚本会增加页面加载负担（GA 的脚本有 ~45KB），还需要处理 Cookie 同意弹窗。除非你有特定的需求是 Umami 满足不了的（比如电商转化漏斗分析），否则 Umami 一个就够了。
小明的数据习惯
小明现在养成了一个习惯：每周一早上打开 Umami 面板，花 10 分钟看看上周的数据。不是为了看数字涨没涨，而是带着问题去看：
- 上周做的改动有没有影响用户行为？
- 有没有异常的数据波动？
- 流量来源的分布有没有变化？
数据不多，但每一条都在帮他理解自己的产品。他开始觉得，做产品不只是写代码——理解用户、用数据验证假设，这些同样重要。
不过，就在小明沉浸在数据的世界里时，老师傅突然严肃起来："你收集了用户数据，有隐私政策吗？"