Google Analytics 替代工具怎麼選？四款工具與遷移檢查

先寫下需要回答的問題

開啟統計後臺，面對一屏圖表，仍然不知道該改哪篇文章、停哪個廣告、修哪個頁面。換工具的目標應該是解決這些問題。

給網站列出三條需要的答案：

• 哪篇文章帶來訂閱？
• 哪個推廣渠道帶來付款？
• 註冊流程的哪個步驟流失最多？

三條問題對應三種統計任務：內容效果、來源轉化、流程分析。

“今天來了多少人”只能回答訪問規模。它無法解釋訂閱和付款。

四款工具，按任務選擇

工具	值得試用的需求	試用重點
Plausible	頁面、來源、訂閱或下載目標	能否查出帶來目標轉化的頁面和來源
Umami	流量、事件、步驟轉化；需要雲服務或自建選擇	漏斗步驟、時間視窗、部署版本
Matomo	需要遷入 GA 歷史報告	匯入範圍，舊報表能否回答原來的問題
PostHog	註冊後的使用、流失與留存	事件定義、身份關聯、計費事件量

這張表表達的是試用方向。功能存在重疊，套餐和部署版本也會影響可用範圍。

Plausible：從頁面和來源追到目標

部落格可以設定訂閱目標，資料網站可以設定下載目標。

需要檢視的報表是：

哪個來源帶來的訪問完成了訂閱？哪篇頁面參與了轉化？

Plausible 支援頁面目標、自定義事件和收入追蹤。按鈕點選、表單提交、付款成功需要對應的記錄設定；安裝統計指令碼不會替網站定義業務結果。目標追蹤檔案

**試用任務：**選一篇文章，設定一個訂閱成功目標，檢查報表能否把來源、頁面和訂閱聯絡起來。

Umami：把步驟串成漏斗

漏斗就是一串必須完成的步驟：

開啟商品頁 → 開始結賬 → 付款成功

Umami 支援頁面和事件組成的漏斗。步驟順序和時間視窗影響結果。例如，時間視窗設為十分鐘，間隔超過十分鐘的步驟可能無法計入同一次完成。Umami 漏斗檔案

漏斗出現下降，原因需要檢查。可選步驟、缺失事件、錯誤時間視窗都可能製造“流失”。

**試用任務：**建立一條三步漏斗，完成一次測試流程，確認三個步驟都有記錄。

Umami 提供雲服務和自建方式。自建需要承擔升級、備份和故障處理。維護能力應進入選擇條件。Umami 官網

Matomo：先檢查歷史報告的用途

歷史資料有價值，前提是它能回答需要的問題。

Matomo 的 GA 匯入器讀取彙總報告。匯入資料無法還原原始訪問日誌，也不支援全部細分和報告功能。Matomo 匯入限制

“能匯入”不等於“舊後臺能做的分析全部保留”。

**試用任務：**列出三張必須保留的舊報表，核對匯入支援範圍。需要逐次訪問記錄、原始事件或特定細分時，檢查匯入限制。

PostHog：檢查註冊後發生了什麼

會員網站可能需要追蹤：

註冊成功 → 完成第一次操作 → 下一週再次使用

PostHog 提供事件漏斗、路徑和留存分析。留存報告需要定義起始事件和返回事件。“回來開啟首頁”和“回來完成一次操作”代表不同結果。分析型別、留存定義

這些分析需要維護事件含義。功能增加，事件名稱、屬性和身份關聯也需要管理。

**試用任務：**定義一個首次完成事件和一個再次使用事件，確認報表回答的是業務問題。

轉化事件：點選不代表成功

“點選付款按鈕”記錄付款意圖。付款失敗也可能產生這個事件。

“開啟感謝頁面”也存在誤判：重新整理、收藏連結、付款後的跳轉失敗都會影響記錄。

先給目標寫一句定義：

目標	應該記錄的結果
訂閱	訂閱提交被接受
註冊	賬號建立成功
付款	訂單付款得到確認
下載	區分下載連結點選與檔案完成獲取

付款統計需要與訂單系統核對。瀏覽器事件可能遭到攔截，訂單系統承擔付款事實的記錄。

一次測試付款，應產生一個成功記錄。重新整理頁面不應把同一訂單變成兩筆收入。

遷移：做四項檢查

1. 頁面記錄

開啟首頁、文章頁和一個業務頁面，檢查記錄。

頁面切換也要測試。有些網站切換頁面不會重新載入整個網頁；首頁有記錄，後續頁面仍可能漏記。

2. 來源記錄

準備一條測試推廣連結：

https://example.com/?utm_source=test&utm_medium=email&utm_campaign=migration

用新瀏覽器會話開啟，檢查來源與活動名稱。網站跳轉需要保留引數。

UTM 用來區分推廣活動。日常分享連結應統一名稱，避免 newsletter、Newsletter、email-news 各佔一行。

3. 成功記錄

完成一次訂閱、註冊或測試訂單，核對事件名稱、次數和金額。

先確認目標事件沒有被內部訪問過濾規則排除。

4. 重複記錄

檢查統計指令碼的安裝位置。網站外掛、主題設定和標籤管理器可能各裝了一次。

重複指令碼、重複提交、感謝頁重新整理都值得檢查。訪問量翻倍不代表流量增長。

新舊數字不同，查什麼？

先統一比較範圍：

• 日期和時區。
• 域名、子域名與頁面範圍。
• 內部訪問過濾規則。
• 同意管理和指令碼攔截情況。
• 訪問、會話、轉化的定義。

記錄結果可以整理成一張表：

現象	排查方向
首頁有記錄，文章切換沒有	頁面切換追蹤
頁面正常，推廣來源丟失	UTM 引數、跳轉、來源判定
點選有記錄，成功沒有	成功事件是否接入
成功次數超過訂單數	重複觸發、測試訂單、取消或退款口徑
全部頁面出現接近固定倍數的差異	重複安裝、記錄範圍和指標定義

這些是排查方向，不能直接當成故障結論。

瀏覽量完全一致也不能證明遷移成功。來源丟失、付款重複、廣告轉化斷開，都會影響決策。

歷史資料和廣告連線，要單獨處理

Plausible 支援 GA 資料匯入，但不支援匯入 GA 電商收入；Matomo 匯入的是彙總報告。舊資料是否可用，需要逐項檢查。Plausible 匯入檔案、Matomo 匯入限制

記錄切換日期，保留舊報表。跨越切換日期的趨勢需要標註統計口徑變化。

Google Ads 也有一項檢查：帳戶是否使用 GA4 匯入的轉化進行出價最佳化？刪除 GA4 前，需要驗證替代的廣告轉化鏈路，並檢查重複計數。Google Ads 轉化檔案

費用：看計費單位

每月十萬次頁面訪問，不代表十萬個計費事件。

頁面訪問、按鈕點選、自定義事件和自動採集都可能進入事件量。PostHog 的產品分析使用事件計費，因此試用應包含事件量檢查。PostHog 計費說明

選購前核對：

• 計費單位與超額規則。
• 網站數量。
• 資料保留期。
• 需要的功能屬於哪個套餐。
• 自建的維護成本。

怎麼做決定？

部落格先測試“頁面 → 訂閱”。商店先測試“來源 → 付款”。會員網站先測試“註冊 → 使用 → 返回”。

候選工具能回答這條路徑，記錄經得起檢查，費用能夠承擔，才有遷移價值。