导读：建了站，访客数据从哪来？大多数人的答案是Google Analytics（GA），但GA这两年越来越不香：欧盟隐私法规下被多个国家封杀过，各种广告拦截插件默认屏蔽GA脚本导致统计严重失真，而且你的每一个访客行为都在给Google的数据帝国打工。本站自托管系列已经把密码、订阅、书签收回来了，这篇把最后一块也拿回来——用Umami自建网站统计：一段JS接入、界面清爽、不写Cookie、不采集个人身份信息，资源占用低到1G小鸡毫无压力。部署、接入、数据解读、和GA对不上数的真相，一次讲清。
一、先想清楚：你到底想从统计里看什么
动工具之前先明确需求，免得过度工程。个人站长看统计，核心就五个问题：今天多少人来了（UV/PV）；他们从哪来（来源：搜索引擎、直接访问、外链）；看了哪些页（热门页面）；用什么设备（移动占比、浏览器）；什么时候来（时段分布）。
GA能回答这些，但它顺便还干了别的：跨站追踪用户画像、广告归因、深度行为分析。这些能力对个人博客是屠龙刀砍蚊子，代价却是重型脚本（GA4的脚本加载体积可观）、Cookie合规横幅的义务、以及访客被拦截器挡掉导致的统计缺口。
Umami的哲学完全相反：只回答上面五个问题，其他一概不采。它不用Cookie、不存个人身份信息、采集的维度刻意做粗，因此天生规避了大多数隐私合规负担——你甚至不用挂那个烦人的Cookie同意横幅。脚本体积只有几KB，对网站速度的影响几乎为零，呼应本站之前讲的性能优化：统计工具本身不该成为拖慢网站的那块短板。
二、技术形态：一套Node应用加一个数据库
Umami是Node.js写的单应用，依赖一个数据库，官方推荐PostgreSQL（也支持MySQL）。整套东西跑在Docker里就是两个容器：应用加数据库，用Compose编排。
资源画像：应用本身常驻内存150M上下，加一个轻量PostgreSQL约50M，合计200M出头。1G内存的小鸡跑它绰绰有余，还能跟本站讲过的其他自托管应用合租。
数据模型上Umami只存聚合事件：每次页面访问记一条（时间、路径、来源、设备特征哈希、会话标识），没有用户体系、没有跨站ID。这既是隐私优势，也决定了它的边界：它做不了漏斗分析、做不了用户回访轨迹回放。个人站完全够用，电商级需求请绕道GA或Matomo。
三、部署：Compose一把梭
老规矩，规划目录 /opt/selfhosted/umami，写docker-compose.yml：
services:
umami:
image: ghcr.io/umami-software/umami:postgresql-latest
container_name: umami
restart: unless-stopped
environment:
DATABASE_URL: postgresql://umami:换成强密码@umami-db:5432/umami
DATABASE_TYPE: postgresql
APP_SECRET: 换成随机字符串
depends_on:
- umami-db
ports:
- '127.0.0.1:3000:3000'
umami-db:
image: postgres:16-alpine
container_name: umami-db
restart: unless-stopped
environment:
POSTGRES_DB: umami
POSTGRES_USER: umami
POSTGRES_PASSWORD: 换成强密码
volumes:
- ./data:/var/lib/postgresql/data
四个要点。其一，APP_SECRET是会话加密盐值，用 openssl rand -hex 32 生成一个填进去。其二，数据库密码两处要一致。其三，只绑127.0.0.1，对外统一走本站反代教程的Nginx入口，配个 analytics.example.com 之类的域名。其四，数据库版本建议跟示例一致选16-alpine，别追新大版本，PostgreSQL大版本升级要迁移数据。
启动：
docker compose up -d
看日志确认初始化完成：docker compose logs -f umami，出现监听字样即就绪。浏览器经反代访问，默认账号admin、密码umami，登录后立刻改掉。
四、接入你的网站：一段脚本的事
登录后台，添加网站，填域名和时区，保存后会给你一段跟踪代码，形如：
<script defer src='https://analytics.example.com/script.js' data-website-id='你的站点ID'></script>
把这段代码贴进你网站的head或body末尾，接入就完成了。
各平台贴法。WordPress：主题设置里一般有“统计代码”或“页脚脚本”输入框，或装个Head/Footer插件统一管理。Hugo：layouts目录的base模板里加一行，重新构建。Typecho：后台外观设置里的自定义头部输出。
贴完回到Umami后台，实时页面打开，自己访问一下网站，几秒内能看到访问事件弹出，链路即通。
有个细节值得知道：Umami的脚本路径可以自定义（设置里改），不少人把默认的script.js改名，能进一步降低被拦截器按特征屏蔽的概率。实测目前主流拦截规则集对Umami的屏蔽率远低于GA，这也是自建统计在实际意义上“数据更准”的原因之一。
五、数据怎么读：五个视图的含义
后台首页切换到你添加的网站，核心视图逐个说。
访客（Visitors）与会话（Sessions）：访客近似UV，会话近似访问次数。一个访客上午来一次下午来一次，算1个访客2个会话。Umami的UV判定不靠Cookie，靠IP加浏览器指纹加UserAgent的哈希组合，粒度足够个人站使用。
页面浏览（Pageviews）：就是PV。图表里访客和浏览量两条线叠着看，两条线的间距反映“人均浏览深度”——间距大说明单访客翻了好几页，内容粘性好。
来源（Referrers）：访客从哪个网页链过来。注意这里的口径是“上一个网页”，直接输入网址或从书签进来会归到Direct。搜索来源方面，Google自2021年起对未登录用户隐藏关键词，你看到的会只是google.com域名而无具体词，这不是Umami的锅，是全行业现状。
页面（Pages）：热门内容排行。个人博客看这个最快乐：哪篇文章被翻牌最多一目了然，直接指导下一篇写什么。
设备与地区（Devices/Browsers/Locations）：移动占比决定要不要为移动端优化多花力气，地区分布帮你判断CDN节点选哪里。
六、经典疑问：为什么和GA对不上数
接入双统计过渡期的人都会发现两边数字打架，先说结论：别指望一致，差异本身就是信息。常见原因按影响排序。
拦截器屏蔽：GA被拦截的比例显著高于Umami，所以GA数字通常偏低。
口径不同：GA的会话超时是30分钟，Umami默认也是30分钟但可配置；跨日界的会话两边切法不同，日数据永远有小幅出入。
自有域名脚本：GA的脚本域众所周知，你的analytics.example.com不在默认规则里。
爬虫过滤：两边对爬虫的识别策略不同。
一般规律：Umami的数字比GA高10%到30%都属正常，且更接近真实人类访问。判断标准不是“哪个准”，而是“趋势是否一致”——两边曲线形状同涨同跌，就都在正常工作。
七、运维与边界：让它安分跑下去
更新：跟随本站Compose教程的三连命令。Umami的数据库结构会在新版本启动时自动迁移，升级前把data目录备份一下即可（也就是打包整个compose目录，跟站内备份方案合流）。
多站点：一个Umami面板可以添加无限个网站，每个站一段不同data-website-id的脚本。给朋友的项目也挂上，一个面板管所有站。
共享只读链接：Umami支持给单个网站生成一个公开只读的分享链接，周报月报时甩给合作方看，不用开账号，很体面的功能。
事件跟踪：链接上埋 data-umami-event 属性就能统计按钮点击、外链跳出等自定义事件，做下载量统计、友链点击榜都行，这是个人站最实用的进阶技巧。
边界也要说清：Umami没有留存单个用户级数据，所以做不了“某个访客的完整访问路径回放”；没有电商平台需要的转化归因。它的定位就是轻量、隐私、够用。
结语
数据是自己的网站产生的，理应存在自己的服务器上。Umami用200M内存的成本，把访客统计从“给巨头打工”变成“自家的仪表盘”：无Cookie、无合规负担、几乎零性能开销。至此，配合本站自托管系列，你的网站从内容、密码、订阅到数据已全部回归自有。一个完全自持的个人站点，技术上不再是难事，只差你动手。
