讓 AI 工作代理讀懂 GA4

先看懂這個轉折

數位行銷讓我們可以記錄來源、頁面瀏覽與轉換；GA4 則把這些互動整理成可查詢的事件與報表。問題是，資料變多之後，管理者仍常遇到三個困境：每次分析都要重新切報表、不同人對同一個指標有不同解讀，而且分析結果沒有留下查詢條件與限制，下一次只能重做。

AI Agent（AI 工作代理）帶來的改變，不是替你把數字寫得更漂亮，而是能在明確授權下，重複執行一套分析工作：確認資料範圍、呼叫查詢工具、檢查資料品質、比較期間、整理報告、標示不能下的結論，最後留下交接紀錄。

本單元使用一個真實的 GA4 分析專案，帶你完成下列工作：

• 看懂 Model Context Protocol（MCP）如何讓 Codex 連接 GA4。
• 分清楚 MCP 主機、client、server，以及 tools、resources、prompts 的角色。
• 依經營問題設計來源、入口頁、漏斗、事件與 UTM 查詢。
• 先檢查資料能不能信，再討論流量好不好。
• 把觀察、推論與管理決定分開，不把彙總資料說成個人完整路徑。
• 留下可開啟、可核對、可接續的分析檔案與交接紀錄。

先建立共同語言

GA4 property、使用者、工作階段與事件

GA4 property 是一組網站或 App 的量測與報表容器。你查詢資料前，必須先確認讀的是哪一個 property；如果同一個網站同時送資料到兩個 property，報表可能高度重疊，不能把兩邊直接相加。

GA4 常見的三個分析層次如下：

維度（dimension） 是分類欄位，例如來源／媒介、入口頁、裝置或事件名稱；指標（metric） 是可以計算的數值，例如工作階段、活躍使用者、事件數或互動率。不是所有維度與指標都能放在同一個查詢中，因此執行前要檢查相容性，必要時拆成多份報表。

入口頁、Direct、(not set)、UTM 與 key event

漏斗不是一張圖，而是一組可驗證的行為定義

行銷漏斗是你先定義的一連串行為，例如：

進入網站 -> 搜尋課程 -> 查看課程詳情 -> 點擊報名 -> 送出報名

每一步最好都有對應事件。若目前只有頁面瀏覽資料，仍可用入口頁、頁面路徑、referrer、互動率與下一頁轉移量做初步診斷，但這只是代理指標。代理指標可以幫你找到優先檢查的位置，不能被寫成「每一位使用者實際走過的完整路徑」。

MCP 如何把 Codex 與 GA4 接起來

MCP 是連接標準，不是另一個 AI 模型

Model Context Protocol（MCP）是一套讓 AI 應用程式用一致方式連接外部資料與工具的開放標準。它處理的是「如何發現能力、交換內容與呼叫工具」，不負責替你決定商業問題，也不會自動保證資料安全。

白話來說，MCP 像統一規格的服務窗口。Agent 不必為每個系統重新學一套叫號方式，就能先看見窗口提供哪些服務，再提出請求。但「有窗口」不等於「有通行證」：Google 帳號授權、GA4 property 權限、組織政策與人工核准仍然各自有效。

管理者在這一段先記三件事就夠：要回答哪個經營問題、Agent 能讀哪一份 GA4 資料、完成後如何核對數字與撤銷權限。host、client、server 與原始欄位名稱是實作者用來完成連線的細節，不必先背。

本案例的連接關係如下：

你提出經營問題
  -> Codex（MCP 主機應用程式）
    -> MCP client（Codex 為這個 server 建立的專用連線）
      -> analytics-mcp（MCP server）
        -> Google 授權與 GA4 property 權限
          -> GA4 Data API
            -> 彙總報表資料
              -> CSV、分析報告與交接紀錄

Host、client、server 各自負責什麼

一個 host 可以同時連接多個 server，但通常會為每個 server 建立各自的 client。這種分隔有助於管理連線與能力邊界，但是否真的安全，仍取決於主機、server、驗證方式、權限設定與使用者核准。

Tools、resources、prompts 有什麼不同

MCP server 可以提供三種核心能力；不是每一個 server 都一定同時提供三種。

本案例使用 analytics-mcp 提供的 GA4 報表查詢工具。不同 MCP server 提供的能力不一定相同；實際操作前，應先查看可用工具，不要假設它同時提供資源或提示模板。

為什麼不直接下載 CSV 就好

人工下載 CSV 適合一次性問題；MCP 適合把同一套資料能力交給 AI 工作代理重複使用。它的實務價值包括：

• 固定查詢方式：日期、維度、指標與篩選條件可以留下紀錄。
• 減少手動搬資料：不必每週打開多個報表、下載並重新命名。
• 先發現工具再呼叫：host 可以先知道 server 提供哪些能力，再決定是否使用。
• 分離工作責任：GA4 保管資料，MCP server 提供查詢能力，Codex 負責整理與檢查，管理者負責決定。
• 較容易交接：輸出檔、查詢條件、限制與下一步可以一起保存。

同時要看清楚它沒有解決的事：

• MCP 不會取代 GA4 Data API；server 最後仍要透過 Google 的 API 取得資料。
• MCP 不會自動取得權限；Google 帳號仍必須有對應 property 的合法存取權。
• MCP 不會自動判斷資料是否可用於某項決策。
• MCP 不會替你保證第三方 server 的程式碼、維護者或更新安全。
• MCP 不會把彙總報表變成逐人事件資料。

權限不是一個開關，而是四層控制

本案例使用 Google Application Default Credentials（ADC）讓本機工具代表已授權的 Google 使用者讀取 GA4。請把權限分成四層管理，不要只確認「現在查得到資料」。

Google 的官方快速入門範例使用下列方式建立 ADC：

gcloud auth application-default login --scopes="https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/analytics.readonly"

這是技術人員執行的設定步驟，不是把指令貼上就代表符合公司治理。cloud-platform scope 的實際能力仍受 Google Cloud IAM 限制，組織應確認使用的 Cloud 專案、身分與政策是否合適。若你只需要讀取 GA4，請把分析任務限制為讀取，不讓 Agent 修改 property、事件設定、廣告或正式網站。

撤銷由上述登入方式建立的本機 ADC 時，可使用：

gcloud auth application-default revoke

請勿把 ADC 檔案內容、存取權杖、OAuth refresh token、帳號密碼或任何憑證貼進提示詞、報告、交接檔或公開儲存庫。

真實案例：先發現量測問題，再談行銷成效

案例範圍

這個案例分析一個終身學習網站的兩個 GA4 property，以連續 28 天為主要觀察區間，並以前一個相同長度的 28 天作為比較基準。案例中的期間與數字用來示範分析方法，不代表網站目前的狀態。

為保護網站資料，以下以 Property A 與 Property B 表示。實際分析時，請由有權限的負責人確認正確的 GA4 property。

這個專案最後留下三層成果：

• 主漏斗與站內流轉分析。
• 事件、key events、SEO、UTM 與付費社群的治理檢查。
• 流量異常與網站健康度報告。

每一階段另有 CSV、摘要檔與交接紀錄，因此下一輪可以沿用同一組問題，而不必重新猜測分析方法。

先比較「量」與「品質」

第一個管理結論不是「活動成功」，而是「流量成長，但互動品質下降」。下一步要分辨是推廣帶來較低意圖流量、落地頁與素材不一致，還是量測本身出現問題。

Direct 是最大來源，但不是顧客意圖的答案

可以確定的是 Direct 佔比高，而且互動品質偏弱。合理的待查假設包括：LINE、EDM、簡訊、PDF、短網址、App 內瀏覽器或未標記貼文沒有帶入可用來源資訊；也可能有一部分是真正的直接造訪。

不能直接宣稱「四成以上都是漏標 UTM」。管理上應先盤點實際推廣連結與命名規則，再用修正後的新資料驗證 Direct 是否下降。

(not set) 先列為量測健康警訊

Property B 另有 220 個空白入口工作階段，跳出率為 100%。這些資料不應被當成一個表現很差的內容頁；更合理的處理順序是檢查重新導向、跨子網域、cookie 或同意設定、page_view 觸發時機、舊頁面與特殊路由。

這裡的原則是：先修量測，再評內容。 如果資料欄位本身不完整，後續漏斗與來源判讀都可能被污染。

同樣是付費社群，命名與品質卻分裂

Property B 的資料顯示：

這個差異值得優先回查，但不能只憑 GA4 報表判定廣告本身一定失敗。請把 fb / paid 對回實際活動、素材、受眾、裝置、落地頁與投放日期，再檢查是否有 URL 或量測異常。

同時要修正 UTM 命名。facebook / paid_social 與 fb / paid 可能代表不同活動，也可能只是同一平台被不同人用不同名稱標記。沒有共同命名規則，就無法穩定比較。

核心中段頁可能卡住，也可能只是量測沒有接上

兩個 property 都顯示課程查詢結果頁是高流量中段頁，最近 28 天分別有 3,204 與 3,526 次瀏覽。以 pageReferrer -> pagePath 建立的轉移代理指標，沒有觀察到足夠的下一頁資料。

這項結果支持兩個待查方向：

• 真實體驗問題：篩選、排序、課程卡片、手機操作或報名引導不清楚。
• 量測銜接問題：課程詳情、外部表單、重新導向或跨網域動作沒有被正確記錄。

因此報告應寫「核心中段頁需要優先檢查」，不能寫成「使用者全部在這裡離開」。

事件多，不代表已經能回答經營問題

Property A 主要只有 page_view、session_start、user_engagement、first_visit 等自動事件，沒有查到有效的 key event。Property B 另有 scroll、click、form_start、form_submit，並記錄 284 次名為 ads_conversion___1 的 key event。

Property B 的資料較完整，但 ads_conversion___1 沒有清楚的經營語意。管理者無法只看名稱判斷它是報名完成、表單送出、廣告轉換匯入，還是其他動作。

較可用的事件名稱可以包括：

事件名稱、觸發條件、必要參數與負責人要一起定義。若事件只是名稱好看，卻沒有實測何時觸發，仍不能作為決策依據。

把觀察、推論與決定分開

AI 工作代理可以協助完成觀察與提出待查假設；涉及預算、品牌、產品、網站改版與績效責任的決定，仍要由有權負責的人核准。

開始前先選擇你的操作路徑

路徑 A：使用組織授權的真實 GA4

請先準備：

• 一個經組織核准、可使用 GA4 的 Google 帳號。
• 目標 property 的 Viewer 或符合組織政策的讀取權限。
• 已啟用 Google Analytics Data API 的 Google Cloud 專案。
• 已由可信任來源安裝並登錄的 GA4 MCP server。
• 一個只用來存放本輪分析結果的資料夾。
• 明確的主要日期區間、比較區間與時區。
• 一位負責確認經營解讀與後續行動的人。

開始前不要提供：

• 客戶姓名、電話、Email 或其他可識別個人的資料。
• 帳號密碼、API 金鑰、ADC 檔案內容、存取權杖或 refresh token。
• 你無權使用的 property、廣告帳號或 CRM 資料。

路徑 B：沒有 GA4 權限也能完成練習

請直接使用本單元的 Property A／B 案例表格。你仍可完成：

• 找出量測健康問題。
• 分開流量量體與互動品質。
• 列出 Direct、(not set)、UTM 與事件治理的待查項目。
• 把觀察、推論、下一步與不能宣稱的結論寫清楚。

這條路徑不會產生新的 GA4 查詢結果，完成證據改為一份案例診斷表與管理建議。

先從模糊的經營困擾開始

真實情況常是：「最近流量很多，但我不知道問題在哪。」這句話還不能直接查報表，卻足以開始一次有效訪談。

我的 GA4 看起來有不少流量，但我不知道該先看什麼，也不確定目前的追蹤是否可信。

先不要查資料。請一次只問一題，最多問五題，幫我釐清要支援的經營決定、可使用的 GA4 property、日期範圍、主要轉換，以及目前最擔心的量測問題。訪談後請整理成一頁查詢規格，將未知與需要人工確認的地方分開列出。

AI 整理後，你至少要能用一句話回答「這次分析要協助哪個決定」。若連這句話都還不能確認，就先停在訪談階段，不要讓 Agent 大量查表。

本單元的五個成熟階段

第 2 階段：訪談後的查詢工作規格範例

用十個步驟完成一次 GA4 Agent 分析

寫出一個真正的經營問題

不要從「幫我分析 GA4」開始。請先選一個可以支持決策的問題，例如：

• 最近流量增加，是否帶來更高品質的互動？
• 哪一種推廣來源把人帶到正確的課程頁？
• 課程搜尋到報名之間，哪一個步驟最需要檢查？
• 哪些流量被歸到 Direct，導致活動來源看不清楚？
• 現有事件能不能回答報名與洽詢成效？

確認 property、日期與時區

請先列出你能存取的 property 名稱，不要把兩個看起來相近的 property 直接相加。固定主要區間與比較區間，並把「是否包含今天」寫清楚。接近即時的資料仍可能持續處理，同一份查詢在不同時間執行，可能出現小幅差異。

盤點 MCP 可用能力

請讓 Codex 先列出目前可用的 GA4 tools、必要參數與限制。不要假設每一版 MCP server 都有相同名稱，也不要把一般 MCP 規格中的 resources 或 prompts，當成這個 server 已提供的功能。

先做查詢相容性與資料範圍檢查

確認預計使用的維度與指標能否放在同一份報表。遇到不相容欄位時，拆成兩份查詢，再用共同欄位比較；不要為了讓 API 成功，悄悄刪掉重要指標。

查流量來源與品質

管理者先看四個問題：人從哪裡來、帶來多少工作階段、進站後有沒有實際互動、停留是否足以完成預期行動。

這一組回答「人從哪裡來，以及不同來源帶來的互動品質」。

查入口頁與量測健康

至少檢查入口頁、工作階段、互動率、跳出率、平均工作階段時間與每次工作階段瀏覽量。先找：

• (not set) 或空白值。
• 同一頁面因尾端等號、查詢參數或不同標題被拆開。
• 入口頁與活動承諾不一致。
• 兩個 property 是否出現高度相似的日期、來源與頁面結構。

拆開 Direct 與 UTM

先查 Direct 的入口頁與互動品質，再盤點所有外部推廣連結。UTM 建議使用可讀且固定的命名，例如：

utm_source=facebook
utm_medium=paid_social
utm_campaign=2026_esg_course
utm_content=video_15s_a
utm_term=manager_audience

不要同時混用 fb / paid、facebook / paid_social、純平台流水號與完全未標記的短網址。若公司已有命名規則，應優先遵守既有標準，再修正歷史差異。

用事件定義漏斗；事件不足時才用代理指標

若已有 search_course、view_course_detail、click_apply、submit_application 等事件，可用漏斗報表計算每一步的完成與流失。執行前要確認事件的觸發條件與日期範圍。

若事件不足，可先用入口頁、頁面路徑、referrer 與互動指標找出疑似斷點。報告必須標示「代理判讀」，不能宣稱已還原同一位使用者的完整旅程。

比較期間並標示資料異常

請至少比較最近一段固定期間與長度相同的前期。不要只看工作階段增減，也要同時比較互動率、跳出率、平均時間與 key events。若不同報表的總數不一致，先檢查維度是否排除了缺值、查詢時間是否不同、資料是否仍在處理，以及 API 與介面是否使用相同定義。

輸出報告、明細與交接紀錄

每次至少保留：

• 本輪執行規格。
• 原始彙總查詢的 CSV 或 JSON。
• 一份管理者可讀的診斷報告。
• 一份列出 property、日期、查詢、限制、已完成與下一步的 HANDOFF.md。

第 3 階段：讀取真實 GA4 的完整試跑指令

這份長指令是完成訪談、確認經營問題與資料權限後才使用的執行契約。請把中括號內的內容換成你的情境。第一次執行時，先使用只讀權限；不要讓 Agent 修改 GA4、Google Ads、網站標記或正式資料。

學員先掌握四類成果即可：執行規格、原始明細、管理報告、交接紀錄。下方的 GA4 欄位與檔名是交給實作者的精確規格，不必在課堂上逐一背誦。

你是我的 GA4 行銷分析工作代理。請依照本指令執行，只讀取資料，不得修改 GA4 property、事件、key events、Google Ads、網站標記或任何正式系統。

【經營問題】
[填入一個需要據以採取行動的問題，例如：最近 28 天增加的流量，是否帶來更高品質的課程查詢與報名意圖？]

【分析範圍】
- MCP server：[填入已核准的 GA4 MCP server 名稱]
- GA4 property：[填入 property 名稱或 ID；若有兩個候選，先列出差異並等我確認主 property]
- 主要區間：[例如最近一個完整的 28 天，請填入起訖日期]
- 比較區間：[例如前一個相同長度的 28 天，請填入起訖日期]
- 時區：[填入 GA4 property 使用的時區]
- 輸出資料夾：[填入本輪專用資料夾]

【權限與安全邊界】
1. 只使用目前已核准且可見的 GA4 讀取工具。
2. 不得要求我貼上帳號密碼、API 金鑰、ADC 檔案內容、access token、refresh token 或任何憑證。
3. 不得讀取、輸出或推測可識別個人的資料。
4. 不得自行擴大工作區、property、日期或外部系統範圍。
5. 不得把彙總資料寫成單一使用者的完整路徑。
6. 若權限不足、MCP 無法連線、property 不明、日期不完整或欄位不相容，請停止查詢並回報，不要假裝已有資料。

【開始前先回覆執行規格】
請先完成下列檢查，再等我確認：
1. 列出你實際看見的 GA4 相關 tools、每個 tool 的用途及本輪是否需要使用。
2. 確認可存取的 property 名稱與本輪主 property；不要把兩個可能重疊的 property 相加。
3. 列出主要區間、比較區間、是否包含今天及時區。
4. 列出預計查詢的維度、指標與相容性檢查方式。
5. 列出預計產生的檔案、權限邊界、停止條件與人工核准點。

【確認後執行的查詢】
請依工具實際支援情況執行；欄位不相容時拆成多份報表，並在報告中說明。

A. 流量來源與品質
- sessionDefaultChannelGroup
- sessionSourceMedium
- sessions、activeUsers、newUsers、engagedSessions、engagementRate、bounceRate、averageSessionDuration

B. 入口頁與量測健康
- landingPagePlusQueryString
- sessions、activeUsers、engagementRate、bounceRate、averageSessionDuration、screenPageViews
- 標示 (not set)、空白值、同頁異名、查詢參數切碎及可疑重新導向

C. Direct 與 UTM
- 篩出 Direct 的入口頁與互動品質
- 檢查 source、medium、campaign、content、term 的命名一致性
- 將「可確定的資料」與「可能的漏標 UTM」分開

D. 站內流轉與漏斗
- 若有具經營語意且已驗證的事件，建立事件漏斗並回報各步完成與流失
- 若事件不足，使用 pageReferrer、pagePathPlusQueryString 與互動指標做代理判讀
- 代理判讀必須標示限制，不得寫成個人完整路徑

E. 事件與 key events
- 列出主要 eventName、eventCount、key events
- 檢查事件名稱是否能對應搜尋、詳情、報名、表單與洽詢
- 對名稱不清楚的 key event，標示「需由設定負責人確認」，不要自行替它命名

F. 期間比較
- 比較主要區間與比較區間的 sessions、engagementRate、bounceRate、averageSessionDuration 與 key events
- 標示量增加但品質下降、資料缺值、異常尖峰與跨報表不一致

【輸出檔案】
請在輸出資料夾建立：
1. 00_run_spec.md：目標、property、日期、工具、查詢、權限、停止條件。
2. 01_acquisition.csv：來源與品質。
3. 02_landing_pages.csv：入口頁與量測健康。
4. 03_direct_and_utm.csv：Direct、campaign 與 UTM。
5. 04_funnel_or_transition_proxy.csv：事件漏斗或站內流轉代理指標。
6. 05_events_key_events.csv：事件與 key events。
7. 06_period_comparison.csv：主要區間與前期比較。
8. ga4_marketing_diagnosis.md：管理者可讀的完整報告。
9. HANDOFF.md：本輪完成、未完成、限制、主要發現、待確認事項與下一步。

【報告寫法】
ga4_marketing_diagnosis.md 必須包含：
1. 一頁摘要。
2. 經營問題與分析範圍。
3. 資料與量測健康檢查。
4. 流量來源與互動品質。
5. 入口頁、Direct、UTM 與事件治理。
6. 漏斗或代理判讀。
7. 「資料觀察／分析推論／管理建議」三欄對照。
8. 不能宣稱的結論與需要補查的資料。
9. 最多三項優先行動；每項寫出負責角色、驗證方式與人工核准點。

【停止與回報條件】
- 查不到資料時，不得用範例數字補齊。
- 發現兩個 property 可能重疊時，不得相加，先列出證據並要求確認主 property。
- 發現 (not set) 或空白入口頁時，先列為量測健康問題，不得直接判定內容頁失敗。
- 發現 Direct 偏高時，列出可能原因與 UTM 待查清單，不得宣稱全部都是漏標。
- 發現資料只到彙總層級時，明確寫出無法還原個人完整路徑；需要事件層級分析時，提出 GA4 BigQuery export 或其他經核准資料來源，不得自行擴大存取。
- 任一工具失敗時，保留已成功的查詢，記錄錯誤訊息、失敗步驟與建議處理方式，不要無限重試。

完成後請自行核對：property、日期、時區、檔名、資料列數、缺值、查詢限制、敏感資料、觀察與推論是否分開，以及 HANDOFF.md 是否能讓下一輪直接接續。

沒有 GA4 權限時，使用案例資料完成同一套判斷

你是我的行銷分析工作代理。請只使用我貼上的 Property A／B 案例表格，不得聲稱已連線 GA4，也不得補造表格中沒有的數字。

請回答這個經營問題：
在流量明顯增加、互動品質下降的情況下，管理團隊應先檢查量測、來源、頁面，還是廣告？

請完成：
1. 把資料分成「流量量體、互動品質、量測健康、來源歸因、漏斗與事件」五類。
2. 每一類各列出可確定的觀察、合理但尚未驗證的推論、不能宣稱的結論。
3. 說明 Direct 偏高與 (not set) 入口頁的不同管理意義。
4. 比較 facebook / paid_social 與 fb / paid，但不得只憑 GA4 數字判定廣告一定失敗。
5. 說明課程查詢結果頁為何需要同時檢查使用體驗與量測銜接。
6. 提出最多三項優先行動，每項寫出負責角色、所需證據、完成判準與人工核准點。
7. 最後列出若要進一步確認，還需要哪些 GA4 事件、廣告後台、網站技術或 BigQuery 資料。

請輸出：
A. 一頁管理摘要。
B. 觀察／推論／不能宣稱／下一步對照表。
C. 三項優先行動。
D. 資料限制與待查清單。

若案例表格不足以回答某個問題，請直接標示「資料不足」，不要自行補值。

第 4 階段：把一次查詢變成穩定 GA4 診斷

同一份指令成功跑一次，不代表下週仍會成功。定期執行前，至少完成下列測試：

哪一層真正負責控制

提示詞像分析工作單，MCP 與權限系統像資料窗口與門禁，外部監督像工作以外的計時器。三者缺一，都不能稱為穩定分析。

完成後你應該看到什麼

使用真實 GA4 路徑時，輸出資料夾至少要有九個約定檔案。打開管理報告後，你應該能在前兩段找到 property、日期區間、時區與經營問題；在報告結尾找到限制、三項優先行動與交接事項。

使用案例路徑時，你應該得到一份不新增數字的診斷文件，而且每一項建議都能回到本單元的案例表格，不會把推論冒充成事實。

一份合格的分析不只會說「哪個數字高」，還會回答：

• 這個數字來自哪個 property、日期與查詢。
• 資料是否有 (not set)、空白值、重複追蹤或命名分裂。
• 觀察到什麼，哪些只是待查假設。
• 這份彙總資料不能回答什麼。
• 下一步由誰處理，要用什麼證據驗收。

用可觀察的證據判定完成

請逐項核對：

• 我已保存本輪執行規格，內容包含 property、主要區間、比較區間、時區、可用工具與停止條件。
• 我已開啟各輸出檔，確認檔名與提示詞約定一致，沒有空白檔或無法解析的內容。
• 我已核對主要報表的資料列數、日期、缺值與總數差異，並把異常寫進管理報告。
• 我已把 Direct 與 (not set) 分開處理，沒有把前者當成顧客意圖，也沒有把後者當成內容頁。
• 我已在報告中分開「資料觀察」「分析推論」「管理建議」。
• 我已明確寫出 GA4 Data API 彙總資料不能還原單一使用者的完整路徑。
• 我已核對至少一個事件或 key event 的名稱、觸發意義與負責人；尚未確認者已標示待查。
• 我已打開 HANDOFF.md，確認下一輪可以看到已完成、未完成、主要發現、限制與下一步。
• 我已檢查報告、CSV 與交接檔，沒有帳號密碼、金鑰、憑證內容、存取權杖或可識別個人的資料。
• 我已找到停用 MCP、撤銷本機 ADC 及移除 GA4 property 權限的位置，並知道三者不是同一件事。

卡住時先檢查

把 GA4 分析放進治理架構

最小權限

日常報表分析以讀取權限為起點。若任務只需要 GA4，就不要同時開放 CRM、廣告修改、網站部署與檔案庫全部權限。每增加一個系統，都要重新確認資料用途、可用範圍與撤銷方式。

可追溯查詢

保留 property、日期、維度、指標、篩選、工具版本與輸出檔名。管理者看到結論時，應能回到原始彙總資料，而不是只能相信 Agent 的文字。

資料最小化

這個流程使用彙總報表即可完成多數網站健康檢查，不需要把可識別個人的資料交給 Agent。若進一步使用 BigQuery 事件資料，要另外處理資料存取、保留期限、去識別、查詢成本與責任分工。

人工把關

以下動作不能只靠報表自動決定：

• 調整或停止廣告預算。
• 修改事件、key events 與 attribution 設定。
• 更換正式 KPI property。
• 修改網站、表單或同意管理。
• 對外宣稱顧客意圖、個人行為或活動成效。

定期撤銷與複查

專案結束、角色異動或不再需要查詢時，請分別檢查 MCP 連線、ADC／OAuth、GA4 property 存取與本機輸出。只刪除報告不等於撤銷權限，只停用 MCP 也不等於 Google 憑證已失效。

下一步：把分析訊號接到企業流程

完成本單元後，你已經把 GA4 從「有人想到才打開的報表」轉成一套固定診斷流程。下一個問題不是再多做一張儀表板，而是決定哪些訊號應進入 CRM、行銷自動化或工作流程平台。

例如：

• 若某個 UTM 活動帶來高品質流量，誰負責擴大測試？
• 若課程詳情頁有大量 click_apply，但 submit_application 很低，誰檢查表單與跟進流程？
• 若 (not set) 持續升高，誰負責量測修復，完成標準是什麼？
• 若 Agent 每週發現異常，應由 n8n、CRM 還是人工任務系統負責通知、指派與追蹤？

下一個單元會把這些資料訊號放進 Salesforce、HubSpot、n8n 與 Agent 的分工中，討論企業級行銷自動化如何連接資料、旅程、權限與責任。