umami vs matomo：2026 年自托管网站分析工具深度对比

从一封律师函说起

2023 年初，一位在欧洲经营小型电商的站长收到了一封来自德国数据保护机构的问询函。起因很简单：他的网站在用 Google Analytics，而 GA 会把访客数据传输到美国服务器。在 Schrems II 判决之后，这件事在 GDPR 框架下变成了一个灰色地带，德国监管机构开始认真追究。

他不是什么大公司，站子月流量也就几万。但面对那封措辞严肃的问询函，他意识到一个令人不安的事实：自己对网站访客数据的流向毫无控制权。

这个故事在独立站长圈子里广为流传。很多人因此开始认真考虑迁移到自托管的分析工具。而当他们真正开始调研时，迟早会在两个名字之间停下来：umami 和 matomo。

这两款工具都是开源的，都支持自托管，都声称尊重用户隐私。但选哪个，答案并不像看上去那么简单。

—

两条不同的来路

理解一款工具，先要理解它是在什么背景下诞生的。

matomo 的历史可以追溯到 2007 年，那时它还叫 Piwik。彼时 Google Analytics 刚刚开始普及，一批开发者意识到「把数据全交给谷歌」这件事本身就值得警惕。Piwik 的设计思路是：做一个功能上与 GA 对标的替代品，让你把整套分析系统搬回自己的服务器。

这个出发点决定了 matomo 的产品气质：它要的是完整。漏斗分析、目标转化、热力图、会话录制、A/B 测试、电商追踪……只要 GA 有的，matomo 大多也要有，而且要做得不比 GA 差。

时间来到 2020 年，一个叫 Mike Cao 的开发者发布了 umami 的第一个版本。那时候自托管分析工具领域已经有了 matomo，也有了 Plausible，但 Mike 觉得它们都不够简单。matomo 太重，部署繁琐；Plausible 的理念不错，但它不开放数据库直接访问。umami 的答案是：砍掉一切非必要的功能，只留最核心的数据，用现代技术栈重新写一遍。

两款工具的设计哲学从一开始就走向了不同的方向。这种分歧，在实际使用中会持续放大。

—

装起来有多难

对于大多数独立站长来说，部署一款自托管工具的第一道门槛是：我能不能在一个下午把它跑起来？

umami 的部署体验相当现代。官方维护了一个 Docker Compose 配置，理论上只需要有一台装了 Docker 的 VPS、几行命令就能跑起来。数据库支持 MySQL 和 PostgreSQL，两者都有现成的 compose 配置。如果你用 Railway、Vercel 这类平台，umami 还提供一键部署模板，连服务器都不用准备。

2024 年发布的 umami v2 做了一次比较大的架构重写，从 Next.js Pages Router 迁移到了 App Router，同时把数据库查询层换成了 Prisma。这让 umami 在性能上有了明显改善，但也意味着从 v1 升级到 v2 需要做一次数据迁移。如果你是新用户，这不是问题；如果你是老用户，需要留意版本变更说明。

整体来说，有基础 Linux 和 Docker 使用经验的站长，把 umami 跑起来大概需要半小时到一小时。

matomo 的部署则是另一番景象。

matomo 的官方安装方式是传统的 LAMP 栈：把 PHP 文件解压到 web 服务器目录，创建数据库，跑安装向导。对于熟悉 WordPress 部署的人来说，流程是眼熟的。matomo 也提供了 Docker 镜像，但社区里关于 Docker 部署的踩坑记录明显比 umami 多，主要是因为 matomo 的配置项太多，很多需要在初始化时就设置好。

matomo 的依赖更重：需要 PHP 7.2 以上、MySQL/MariaDB、足够的服务器内存（官方建议生产环境至少 2GB RAM）。对于跑在 512MB 小鸡上的站长来说，matomo 的资源消耗会是个持续的烦恼。

同样的服务器配置，umami 通常能流畅运行，matomo 则可能开始出现响应迟缓的情况，尤其是在生成报告或处理历史数据的时候。

—

隐私合规这件事

对于那些因为 GDPR 合规问题而离开 Google Analytics 的站长来说，自托管分析工具的核心价值就是：数据不出自己的服务器。在这一点上，umami 和 matomo 都能做到，但它们在合规设计上的细节差异值得仔细看。

umami 的隐私设计是从零开始的，不依赖 Cookie，不收集 IP 地址，用哈希化的会话标识替代传统的用户追踪。这意味着在大多数情况下，umami 的追踪代码不需要 Cookie 同意弹窗。

这是一个重要的实际优势。GDPR 要求对非必要 Cookie 取得明确同意，而 Cookie 弹窗对转化率的影响有多大，做过独立站的人都有体感。umami 的无 Cookie 方案让你在合规的同时，不必为弹窗付出代价。

不过无 Cookie 追踪也有代价：跨会话的用户识别能力会削弱。如果你需要追踪一个用户在一周内多次访问的完整行为路径，umami 能给你的信息有限。

matomo 的隐私合规是另一种思路。matomo 功能强大到支持完整的用户级追踪，但这恰恰意味着它默认就是 GDPR 意义上的个人数据处理器。matomo 提供了一套完整的隐私合规工具：内置的 Cookie 同意管理器、数据主体请求处理（删除/导出特定用户数据）、IP 匿名化、数据保留策略设置。

换句话说，matomo 是「功能强大但需要你主动把隐私开关打开」，而 umami 是「默认就是隐私友好的，但功能上有所取舍」。

两种方案在合规上都是可以自圆其说的，但实施成本不同。用 matomo 做合规，你需要配置的东西更多；用 umami，你需要在数据粒度上接受一些妥协。

—

功能深度对比

这是两款工具差距最大的地方，也是选择时最需要想清楚的地方。

功能	umami	matomo
页面浏览量/访客/会话	✅	✅
实时数据	✅	✅
自定义事件追踪	✅	✅
目标/转化追踪	基础	完整
漏斗分析	❌	✅
热力图	❌	✅（付费插件）
会话录制	❌	✅（付费插件）
A/B 测试	❌	✅（付费插件）
电商追踪	❌	✅
搜索引擎关键词报告	有限	✅
多站点管理	✅	✅
API 访问	✅	✅
数据导出	✅	✅
团队协作/权限管理	基础	完整

这张表格说明不了一件事：你真正需要的是哪些功能。

对于一个博客站长，umami 提供的数据已经够用了。你能看到哪些文章最受欢迎、流量从哪里来、读者在哪个国家、用什么设备访问。这些信息足以帮你判断内容方向。

但如果你在运营一个有购物车的电商站，你需要知道用户从哪一步开始流失，这就需要漏斗分析。如果你在做落地页优化，你需要热力图告诉你用户的注意力落在哪里。这些场景下，umami 目前能给你的答案是：用其他工具。

matomo 的这些高级功能并不都是免费的。热力图、会话录制、A/B 测试这些模块在 matomo 云服务版本里是付费的，但在自托管版本里，这些插件是开源且免费的，只要你愿意自己维护。这是 matomo 自托管路线的一个重要优势，经常被人忽略。

—

数据可视化和日常体验

功能之外，每天打开工具看数据的那个体验，也很重要。

umami 的界面是那种一眼就觉得「干净」的设计。单页仪表盘，所有核心指标一屏展示，没有多余的菜单层级。颜色克制，加载快。如果你习惯了 Notion 那种简洁的现代设计语言，umami 会让你感到舒适。

切换时间范围、在不同网站之间切换，操作都很流畅。对于每天只需要快速扫一眼「今天流量怎么样」的站长，umami 的体验很好。

matomo 的界面是另一种风格：信息密度高，菜单深，每个功能模块都有自己的报告页面。第一次进去可能会觉得有点不知所措：左边一栏菜单，里面嵌套着访客、行为、获客、电商、目标……每个展开来都还有子菜单。

matomo 的界面是为分析师设计的，不是为「扫一眼」设计的。如果你需要深入分析数据、生成报告、设置定时邮件摘要，matomo 的深度是 umami 没法比的。但如果你每次进来只是想确认「今天有多少人来了」，matomo 的层级感会让你觉得有点绕。

—

维护成本和长期运营

自托管意味着你要负责更新和维护。这个成本不能忽略。

umami 的技术栈是 Node.js + Next.js，这是当下主流的 Web 开发栈。更新流程通常是拉取新镜像、重启容器，大多数版本升级没有破坏性变更。umami 的 GitHub 仓库活跃度高，issue 回应速度快，遇到问题社区里通常能找到答案。

matomo 有一个内置的更新系统，可以从管理界面一键更新，不需要手动操作服务器。这是一个不小的便利。但 matomo 的历史包袱更重，作为一个存在了将近 20 年的项目，它的代码库庞大，偶尔会遇到 PHP 版本升级导致的兼容性问题。matomo 的官方文档很完整，但正因为功能太多，找到特定问题的解答有时需要花时间。

两款工具在数据库层面都没有特别的锁定：你可以直接查询底层数据库，用 SQL 做任何分析。这是自托管相对于 SaaS 工具的根本优势之一。

—

适合哪类站长

走到这里，选择的轮廓已经相当清晰了。

如果你是内容创作者、博客站长、小型产品的独立运营者，主要关心流量来源和页面表现，对 GDPR 合规有需求但不想在分析工具上花太多精力，umami 是更合适的选择。部署简单、界面清爽、默认隐私友好、资源占用低。它能告诉你最重要的事情，不会让你淹没在数据里。

如果你是有一定流量的电商站、SaaS 产品、需要做转化优化的营销团队，需要漏斗、目标、电商追踪，或者需要给非技术的团队成员生成可理解的报告，matomo 更值得投入。学习曲线更陡，维护成本更高，但它能给你的分析深度是 umami 目前做不到的。

还有一种情况值得单独说：如果你的站点已经在用 matomo，没有特别的理由迁移到 umami。数据历史是有价值的，迁移工具总有摩擦成本，而 matomo 本身并没有什么根本性的缺陷。

—

两者不是非此即彼

最后一个有意思的观察：不少站长最终的选法是主站用 umami 满足日常需求，特定需要深度分析的场景用 matomo 做补充，或者反过来。两款工具的追踪脚本都很轻量，同时部署技术上完全可行。

这不是在回避选择，而是承认现实：没有一款工具能完美满足所有场景。umami 和 matomo 各有自己最擅长的地方，在你搞清楚自己真正需要什么之前，了解两者的边界比急着下结论更有价值。

那位收到德国监管问询函的站长，最终选择了 umami。他说原因很简单：「我只是想知道有多少人来了我的网站，从哪里来，看了什么。我不需要更多了。」

这是一个诚实的答案。

延伸阅读

• OpenObserve vs SigNoz：预算有限的团队，怎样自托管可观测性才不掉坑？
• Authentik 自托管身份认证替代方案对比：Authelia、Keycloak、Zitadel怎么选
• AI 产品分析工具怎么选：Mixpanel vs Amplitude vs PostHog vs Heap，2026 谁更适合你的团队？
• AI 自己造 AI：离奇点还有多远？

查看完整选型指南 →