Umami v3：從簡潔分析工具到現代數據平台的關鍵進化

故事的開端：從 v2 出發的開源分析旅程

在 Umami v3 釋出後，開源網站分析的世界悄然發生了巨大改變。這一次，升級不只是介面的煥然一新，更是架構與分析能力的全新突破。若要理解 v3 的價值，就得先回到 v2 的時代，看看這套工具是如何一步步擁有今天的樣子。

Umami v2 一直是許多開發者心中的簡潔優雅選擇。在 Google Analytics 之外，它提供了一條自主管理且重視隱私的流量分析道路。安裝方便、介面乾淨、功能專注——對許多個人網站與小型專案來說，這樣的能力其實已經足夠。誰不想要即裝即用、又不綁定第三方雲服務的純淨工具？

當時的架構設計，重心放在事件追蹤與基本流量報告：

• 事件與頁面瀏覽的記錄：滿足日常「有沒有人來看？」的追蹤需求
• 基礎報表：流量來源、熱門頁面、跳出率等關鍵指標一應俱全

對於只想知道「文章有沒有被看」、「哪個入口帶來最多訪客」的網站管理者而言，Umami v2 已經很好用。但隨著前端框架與產品規模的成長，這一切開始顯得有點不夠用了。

單頁應用時代的壓力：v2 的邊界

React.js Folder Structure (Rahul Mishra)

隨著 React、Vue、Next.js 等框架普及，「單頁應用（SPA）」逐漸成為主流。路由不再只是 URL 變化，而是前端狀態切換；使用者行為也從單純的頁面瀏覽，演化為多步驟操作與複雜漏斗。此時，Umami v2 的限制漸漸浮現。

實務上，團隊開始提出這些問題：

• hash-based routing 可以被正確追蹤嗎？
• 能不能針對不同用戶分群，觀察各自的流量與轉換行為？
• 單純的總流量與跳出率，已經不足以支持行銷與產品決策了。

v2 的介面與資料模型，在小規模網站上依然順手，但在多網站、多產品線與多行銷活動並行的情境下，就顯得吃力：

• 多個網站堆疊在同一個列表中，缺乏清晰的分組與管理維度
• 雖然可以追蹤事件，但缺少更進一步的切片與分段分析能力
• 對於 SPA 而言，頁面切換不一定代表完整載入，事件追蹤與路由行為之間存在縫隙

許多使用者心中浮現同一個疑問：

「如果我想追蹤特定地區、某一組行銷活動，或特定漏斗步驟的轉換呢？」

Umami v2 多半只能回答：「再等一下吧。」

意外的突破：v3 新世界的開始

Yellow Volkswagen van on road photo (Calpa Liu)

Umami v3 帶來的變化幾乎是翻天覆地。當你完成升級或安裝新版本後，首先映入眼簾的，是一個完全重新設計的管理介面。

首頁不再只是單純的網站清單，而是具備深度自定義與分組管理能力的控制台：

• 支援大量網站管理：數十個專案也不再顯得凌亂
• 提供網站分組、搜尋與排序，一鍵縮小範圍找到目標站點
• 介面層級設計更貼近真實團隊結構（產品線、國家站、客戶專案…）

這種「管理體驗」的提升，對每天打開後台的營運團隊來說，是非常有感的質變。但真正讓 v3 與 v2 拉開世代差距的，是分析能力本身的升級。

Segment 與 Cohort：從「看整體」到「看群體」

在 v3 中，Umami 正式引入了 Segment（分段分析） 與 Cohort（分群） 等高階分析能力。這讓它從一個「乾淨好用的簡潔分析工具」，進化成可以滿足行銷人員與產品經理需求的現代數據平台。

實際上，你可以做的事情包括：

• 僅觀察特定地區來訪使用者的轉換率
• 切出來自特定流量來源或行銷渠道的訪客行為
• 比較不同 Cohort 之間的留存、跳出率與瀏覽深度

過去需要匯出原始資料、丟進 BI 工具甚至手動處理的分析流程，如今可以直接在 Umami v3 裡完成。對於追求自架設、重視隱私與數據主權的團隊來說，這幾乎是夢寐以求的升級。

技術棧的重構：更貼近現代部署與微服務

Umami v3 不只是把功能疊得更高，它在技術棧與架構設計上也做了徹底重構，明顯對齊了現代 Web 與微服務的實務需求。

更成熟的 API 設計

在 API 層面，v3 帶來了更進一步的改進：

• 支援 batch send，可一次送出多筆事件，減少請求數量
• 更彈性的 payload override，方便在邊界層增加自訂欄位
• 與現代 CI/CD 流程與 microservice 拓樸更容易整合

這對於前端框架與邊緣運算環境（例如 Cloudflare Workers、Vercel Functions 等）特別友善，讓你可以在不犧牲效能的前提下，完成更複雜的事件追蹤設計。

Docker 與雲端部署的優化

Docker (docker.com)

Umami v3 在部署體驗上也下了不少功夫：

• 官方 Docker 映像更穩定，升級流程明確
• 部署設定與環境變數配置更貼近實務場景
• 適合放入 CI/CD Pipeline 中做自動化部署與滾動更新

多語系介面、自定義報表匯出等功能，也在新版本中變得更加順手。從整體來看，v3 已經不再只是「幾個 API + 一個儀表板」，而是一個可以融入團隊日常開發與營運流程的分析服務。

資料庫選擇的轉捩點：Postgres 成為唯一主角

Umami v3 在資料庫層的決策也非常關鍵：

Postgres 成為唯一官方支援的資料庫，MySQL 使用者需要額外進行遷移。

從維護角度來看，這讓核心發展路線變得更單純：

• 推薦、測試與優化可以集中在一條路線上
• 長期性能調校與 Query 最佳化更容易達到一致性
• 可以充分利用 Postgres 在 JSON、索引與分析查詢方面的優勢

對現有 MySQL 使用者而言，這當然意味著必須安排一次資料遷移計畫。好消息是，官方提供了相對明確的 migration 流程：

1. 拉下最新版 Docker 映像
2. 執行官方 migration scripts
3. 驗證資料完整性與報表結果

過程中仍然需要測試與驗證，但整體步驟比想像中單純許多。也正因為如此，Umami v3 能在資料層上站上更穩固的基礎，為接下來的功能迭代留出空間。

舊時代的限制：v2 的最後告白

回頭看 v2，它其實在自己的時代完成了使命：

• 讓更多人第一次接觸到「自架設的隱私友善網站分析」
• 提供一個足夠簡潔的介面，讓技術與非技術人員都能快速上手

但若從現在線上產品與行銷場景來看，v2 的不足也變得非常明顯：

• 多網站管理：網站一多，列表就變成無盡長卷
• 進階事件分析：缺少 Segment 與 Cohort 概念，難以回答「特定族群」的問題
• SPA 支援不足：對現代前端架構來說，行為追蹤存在灰色地帶
• 高流量時的體驗：當儀表板累積大量數據後，操作卡頓的情況時有耳聞

對於想要進一步評估不同渠道的營收貢獻、特定活動的轉換成效、或是不同使用者群的留存表現的團隊來說，v2 更像是一個起點，而不是終點。

Umami v3 則是在這些痛點上，給出了相當完整的回應。

v3 解方：從流量到價值的躍遷

在 v3 的資料模型中，每一個事件都不再只是「被點了一下」的紀錄，而是可以被放入更完整的分析脈絡中：

• 你可以把事件與行銷活動、使用者屬性、甚至營收數據做關聯
• 你可以從「造訪次數」進一步走向「實際帶來多少價值」

當你在思考流量背後的真實價值時，v3 的報表工具更像是一個輕量版的財務與行銷分析平台。

• 你不再只看 PV、UV，而是可以討論「哪個 Cohort 帶來的營收最好」
• 你不再只看跳出率，而是可以追蹤「哪個入口的使用者最願意完成下一步」

對於自架站點與內容創作者來說，這樣的改變非常實際。Umami 不再只是回答「有沒有人來」，而是幫你看清楚「這些人在這裡做了什麼、為什麼會留下或離開」。

西方技術社群的回饋：專業化、合規與協作性

Umami v3 推出後，西方技術社群與媒體普遍給出相當高的評價。對他們來說，這不只是一個版本號的更新，而是朝向「專業級網站分析平台」邁出的一大步。新的介面不只是長得比較好看，導航速度更快、資訊層級更清楚，瀏覽與匯出數據的流程也變得直覺許多。搭配進階的 Cohort 與 Segment 分析能力，以及新加入的 Pixel、短鏈追蹤等元件，Umami 開始能夠在不同平台之間串起一條更完整的追蹤路徑。背後以 Postgres 為核心的架構，也讓穩定性、效能與 GDPR 合規有了更紮實的基礎。

技術媒體眼中的 v3 亮點

在西方開源媒體與技術部落格中，Umami v3 的幾個關鍵亮點也被反覆提及。最常被拿出來談的，是那個完全重新設計過的介面：導航變得更快，整體操作流程明顯更順手，從篩選到匯出數據都少了很多阻力。Cohort 分析讓團隊可以依照時間與行為分群，觀察不同族群的留存與回訪；Segments 則把常用的篩選條件變成可以儲存的報表視圖，切換起來更有效率。Pixel 與短鏈追蹤（Link）支援跨平台的點擊與轉換追蹤，而報表視圖可以直接以 URL 分享給團隊成員，對需要協作檢視數據的產品與行銷團隊來說非常實用。

更重要的是，Umami v3 仍然堅持資料自託管、不綁雲、不加入多餘追蹤程式與 cookie。在高度重視隱私法規的歐洲與德語系社群中，這一點尤其被放大肯定。官方一路強調 GDPR 合規與資料主權，系統運作方式也相對透明，不會在你不知情的情況下悄悄多裝幾段第三方追蹤程式。對許多已經對 Google Analytics 心存疑慮的團隊來說，Umami 逐漸成為一個真正可被信任的開源替代方案。

Reddit 與自架社群的討論：遷移陣痛與長期紅利

在 Reddit「self-hosted」等社群裡，Umami 也一直是自架分析工具的常客。v3 上線之後，討論大多圍繞在兩個主題上。第一個是安裝與升級體驗：不少使用者分享，v3 的部署流程比想像中順利，文件清楚，升級後的數據完整度與報表呈現也獲得正面回饋。第二個則是 MySQL 走向 Postgres 的遷移問題。很多既有使用者都需要規劃一次性的資料搬遷，中大型網站更是被廣泛建議直接改用 Postgres，以換取更好的效能與維護性。

在這些討論裡，「短期有陣痛、長期更穩定」幾乎成了共通結論。對多數自架用戶來說，Postgres-only 的策略雖然提高了切換門檻，但被視為一種專業化與長期維護成本降低的必要投資。也有不少人提到，v3 新增的 Cohort、Segments 與 Pixel / Link 工具，讓自架追蹤能力在很多情境下已經能與 Plausible、Matomo 等商用或半商用方案分庭抗禮，甚至在某些特別重視隱私或需要高度客製化的場景中，Umami 的靈活度反而更高。

與競品的實務比較：Plausible、Matomo 與 Umami v3

如果把 Umami v3 放在更大的開源網站分析生態裡來看，常被拿來比較的對象主要有兩個：Plausible 與 Matomo。

以 Plausible 為例，它的介面設計精緻、品牌感強，商用功能也相當豐富，對希望「直接訂閱一個漂亮好用的 SaaS」的團隊來說非常有吸引力。不過，它的典型使用方式仍偏向雲端託管，自架反而不是主流選項。在完全自訂部署與隱私自主這一塊，Umami 依然更受到自架派開發者青睞。

Matomo 則走的是另一條極致路線：功能龐大且偏企業級，從 session 錄製、熱區圖到更複雜的使用者旅程分析都一應俱全。如果你需要的是「一套什麼都有的 analytics suite」，Matomo 很有說服力；代價是系統相對沉重，部署與維護門檻也高出一級，對中小型團隊來說不一定友善。

相比之下，Umami v3 維持一貫的輕量哲學，強調報表明快、安裝簡單，讓技術團隊可以在短時間內完成佈署並開始收集資料。對重視隱私、偏好自架的團隊而言，這樣的取捨非常實際。加上 v3 在用戶管理與地區／城市層級資料上的優化，中小型團隊也能擁有貼合內部自用分析的完整方案，而不必背負過重的系統負擔。

如果從歐美開源技術社群的角度來看，大家對 Umami v3 的共識大致可以濃縮成幾個關鍵字：

• 專業化：從工具走向平台，具備 Cohort / Segment 等高階能力
• 合規與隱私：以自託管與 GDPR 友善為核心設計
• 協作性：報表分享、Segment 儲存等設計，貼近團隊日常溝通情境
• 轉型痛但長遠有利：Postgres-only 帶來短期遷移成本，但換來長期維護與效能的穩定基礎

也因此，Umami v3 已經不只是個人網站的玩具，而是中小型網站與重視隱私產品，在 analytics 領域的重要主流選擇之一。

微妙而巨大的差距：為誰而升級？

最終，Umami v3 展現的不僅是界面上的革新，也重新調整了資料結構、部署流程與管理效率的平衡。對很多團隊來說，這比較像是一場跟上現代前端、多國語言生態與大流量需求的重新對齊。

• 對前端團隊來說，v3 提供了更友好的追蹤 API 與 SPA 支援
• 對後端與 DevOps 而言，Postgres + Docker + 明確的 migration 流程，讓部署與維運更加可控
• 對行銷與產品團隊，Segment 與 Cohort 帶來真正可行的洞察，而不是一堆孤立的指標

每一位在意隱私、願意自己維護服務的使用者，大多都能在 Umami v3 身上找到被理解的感覺。

這種差距很難只從 changelog 或文件看出來，需要你親手部署、完成遷移，再用真實專案跑上一段時間，感受才會慢慢浮現。

結語：一場關於技術信仰的升級

Person Using MacBook Pro (Glenn Carstens-Peters)

對我來說，Umami v3 不只是把版本號往上加一，而是一次重新確認「我到底想怎麼看網站數據」的過程。

在這個「雲服務訂閱」幾乎成為預設選項的時代，Umami 一直在告訴我們：

• 你可以擁有自己的數據
• 你可以擁有隱私與掌控權
• 你可以在不依賴封閉平台的情況下，做到高品質的網站分析

v3 讓這種信念站上了新的高度。從架構重構、資料庫策略，到高階分析功能與部署體驗，它用實際改版說明了一件事：

開源工具不只是「免費替代品」，而是有機會真正引領網站分析實務往前走。

如果你還停留在 Umami v2，或者仍在觀望是否要導入自架分析平台，也許現在是個好時機。試著在你的 side-project、部落格或產品網站上部署一次 v3，用真實流量與真實決策去感受它的改變。

也許，你會像我一樣，重新審視「誰應該掌握網站數據」這個問題，並在這場看似微妙、實則巨大的差距裡，找到屬於自己的答案。