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

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

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

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

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

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

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

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

React.js Folder Structure

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

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

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

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

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

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

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

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

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

Yellow Volkswagen van on road photo

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

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

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

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

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

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

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

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

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

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

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

過程中仍然需要測試與驗證，但整體步驟比想像中單純許多。也正因為如此，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 的共識大致可以濃縮成幾個關鍵字：