Skip to content

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 是更好的选择。

对比UmamiGoogle Analytics
部署方式自托管,数据在你自己的服务器上云服务,数据在 Google 的服务器上
隐私不使用 Cookie,不追踪个人身份详细的用户追踪,需要 Cookie 同意弹窗
脚本大小< 1KB,几乎不影响页面加载~45KB,对性能有可感知的影响
界面简洁直观,打开就能看懂功能强大但复杂,学习曲线陡峭
数据所有权完全属于你归 Google 所有
费用自部署免费免费版有限制,高级版收费

Umami 的哲学是"够用就好"。它不会告诉你用户的年龄、性别、兴趣爱好(GA 可以),但它会告诉你最重要的东西:有多少人来了、从哪来的、看了什么、用什么设备。对于个人项目和小型产品,这些信息已经足够指导你的决策了。

而且,因为 Umami 不使用 Cookie,你不需要在网站上放那个烦人的"本站使用 Cookie,请同意"弹窗。这对用户体验是一个实实在在的加分。


快速上手

第十四章已经通过 1Panel 应用商店安装好了 Umami。如果你还没装,回到 14.5 实用应用 按步骤安装。

首次登录

Umami 的默认登录信息是:

  • 用户名:admin
  • 密码:umami

登录后第一件事:改密码。 这个默认密码全世界都知道,不改的话等于把你的统计面板公开了。

添加网站并集成追踪代码

登录后,在 Settings → Websites 中点击"Add website",填入你的网站名称和域名。保存后,Umami 会生成一段追踪代码:

html
<script defer src="https://你的umami地址/script.js" data-website-id="你的网站ID"></script>

把这段代码加到你网站的全局布局文件中。Next.js 项目加到 layout.tsx<head> 里,VitePress 项目加到配置文件的 head 数组里。重新部署后,Umami 就开始收集数据了。

小明加完追踪代码,重新部署,然后自己访问了几次网站。回到 Umami 面板一看——数据已经开始跳动了。虽然都是他自己的访问记录,但看到系统真的在工作,还是挺有成就感的。


老师傅教小明看指标

数据开始积累后,小明每天都会打开 Umami 面板看一眼。但他发现自己只是在"看数字",并不真正理解这些数字在说什么。

老师傅坐下来,一个一个给他讲。

image-20260226235803668

访问指标:最基础的四个数字

指标说明
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 流量突然增加,去看看是哪个网站链接了你——也许有人在博客里推荐了你的产品。

设备信息:用户用什么访问

指标说明
BrowserChrome、Safari、Firefox……哪个浏览器最多
OSWindows、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 即可。但老师傅提醒小明:不要追踪所有东西。只追踪那些能帮你做决策的事件——比如核心转化路径上的关键步骤。追踪太多反而会让你淹没在数据里,分不清主次。


数据驱动决策:看到数据后该做什么

收集数据只是第一步,更重要的是用数据来指导行动

小明积累了一个月的数据后,发现了几个有意思的现象:

  1. 移动端用户占 65%,但他之前一直在桌面端开发和测试,移动端的一些交互体验其实不太好
  2. "关于"页面的跳出率高达 90%——用户看完就走了,没有继续浏览其他页面
  3. 周三和周四的流量明显高于其他日子——可能和他在社交媒体发帖的时间有关

这些发现直接转化成了行动:

  • 优先修复移动端的交互问题
  • 在"关于"页面底部加上其他页面的链接,引导用户继续浏览
  • 把社交媒体发帖时间调整到周三周四,效果最好的时候加大力度

这就是数据驱动决策的意义。不是为了看数字,而是为了发现问题、验证假设、指导行动


隐私保护:Umami 的核心优势

在收集用户数据的同时,隐私保护是一个不能忽视的话题。

Umami 的设计从一开始就把隐私放在核心位置:

  • 不使用 Cookie——不需要那个烦人的 Cookie 同意弹窗
  • 不追踪个人用户身份——Umami 不知道"张三今天来了 3 次",它只知道"今天有 X 个独立访客"
  • 不收集可识别的个人数据——不记录 IP 地址(或只记录哈希后的版本)、不记录用户代理的完整字符串
  • 数据完全存储在你自己的服务器上——不会发送到任何第三方

这意味着 Umami 天然符合 GDPR(欧盟数据保护法)的大部分要求。你不需要在网站上放 Cookie 弹窗,不需要让用户"同意被追踪",因为你根本没有在追踪个人用户。

但这并不意味着你完全不需要关心隐私合规。如果你的网站还收集了其他用户数据——比如注册时的邮箱地址、用户提交的表单信息——你仍然需要一份隐私政策来说明这些数据的用途。这就是下一节要讲的内容。


常见问题

Q1: Umami 和 Google Analytics 可以同时用吗?

技术上可以,但对个人项目没必要。Umami 已经覆盖了核心需求,多加一个统计脚本会增加页面加载负担(GA 的脚本有 ~45KB),还需要处理 Cookie 同意弹窗。除非你有特定的需求是 Umami 满足不了的(比如电商转化漏斗分析),否则 Umami 一个就够了。


小明的数据习惯

小明现在养成了一个习惯:每周一早上打开 Umami 面板,花 10 分钟看看上周的数据。不是为了看数字涨没涨,而是带着问题去看:

  • 上周做的改动有没有影响用户行为?
  • 有没有异常的数据波动?
  • 流量来源的分布有没有变化?

数据不多,但每一条都在帮他理解自己的产品。他开始觉得,做产品不只是写代码——理解用户、用数据验证假设,这些同样重要。

不过,就在小明沉浸在数据的世界里时,老师傅突然严肃起来:"你收集了用户数据,有隐私政策吗?"