用 Claude 定期自動跑廣告報告：跨平台月報從吃掉兩週到自動排程產檔
每月初手動拉 Google、Meta、GA4 三個後台再拼成一張表，以我們協助品牌客戶的經驗，一份跨平台月報從撈數到交付常吃掉約兩週。用 Claude 接上 MCP 再加排程，人工搬運可以降到近乎零，機器在每月固定時間數分鐘內把報告產好。這篇拆解怎麼組、自然語言怎麼查、唯讀邊界與資料乾淨度這兩道前提，以及為什麼報告品質最後取決於你的第一方數據。
月初那兩週，行銷團隊都在做同一件事
每個月的第一週，很多台灣電商團隊的行銷人做著幾乎一模一樣的動作：打開 Google Ads 後台匯出一份 CSV，切到 Meta 廣告管理員再匯出一份，登入 GA4 拉轉換數據，最後把三份格式不一樣的檔案貼進同一張 Google 試算表，手動對齊欄位、補公式、調圖表。每一份檔案的時區設定、貨幣單位、轉換定義都不太一樣，光是把它們併到同一個口徑，就足以耗掉一個上午。
以我們實際協助品牌客戶的經驗，一份涵蓋 Google、Meta、GA4 的跨平台月報，從撈數到能交給老闆看，來回大概吃掉兩週。不是因為分析很難，而是因為光是把數據湊到同一張表上、確認每個平台的口徑一致，就耗掉大半時間。等報表終於做完，月份已經過了一半，能調整的預算所剩無幾。
更讓人惋惜的是，這兩週幾乎沒有一分鐘花在真正的判斷上。搬運、貼上、對欄位，這些動作機器最擅長，人卻被綁在上面。如果同樣一份月報，人工投入可以降到接近零、剩下的交給機器在每月固定時間自動跑完，行銷人省下來的時間會流向哪裡？這個問題，2024 年底出現的一項開放標準，加上 2025 到 2026 年各大廣告平台的動作，已經給出了答案。
團隊的聲音
我們在協助品牌客戶健檢廣告成效時，最常看到的畫面不是策略吵架，而是月初的會議室裡，行銷專員盯著三個開著的後台分頁，一格一格複製貼上。我們自己也走過這段路，所以特別想把話講清楚：自動化能省掉的是搬運，救不回來的是搬運時順手弄髒的數據。工具怎麼組是一回事，數據兜不兜得攏，是另一回事。
跨平台月報自動化，卡點其實在取數、下指令、排程
很多人以為「用 AI 跑報告」是一個動作，其實它是三段不同的工作被串在一起。把它們拆開看，才知道每一步各自卡在哪。
取數這一關。過去要人登入每個平台、手動匯出 CSV，Google Ads 一個帳號匯一次、Meta 一個商業管理帳號匯一次、GA4 一個資源再匯一次，格式全部對不齊。現在改由 Model Context Protocol（MCP）這個標準協定，讓 Claude 直接向廣告平台的資料來源發問並取回結構化結果。不用再開分頁、不用再下載檔案，也不用擔心哪一份 CSV 少匯了一個維度。取回來的資料已經是結構化的，能直接進到後面的彙整步驟。
下指令這一關。過去要記得每個平台報表工具的操作路徑，或是會寫 Google Ads 的查詢語法 GAQL，換到 Meta 又是另一套介面邏輯。現在改成用中文自然語言問：「上個月各檔活動花了多少、帶回多少轉換，依裝置拆開」，Claude 會自己把它翻成正確的查詢送出去。想追問「其中手機端的 ROAS 跟上個月比是升是降」，也只要接著問一句，不必回頭改任何設定。對不寫程式的行銷人來說，這一關把門檻從「會不會語法」降到「問得出對的問題」。
排程這一關。過去要靠人記得月初開工，一忙起來就拖到月中，遇到有人請假或離職，這份月報甚至會直接開天窗。現在改成用作業系統的排程機制（概念上就是 cron 或命令列腳本），讓機器在每月固定時間自動跑一次，把報告產好放到指定位置，人打開資料夾就看得到最新一份。這一步是把「快」變成「穩定地快」的關鍵：省下的不只是單次時間，而是每個月都不必再有人記得、催進度、留守，也不必擔心因為誰忙誰忘而漏掉一次。
三段工作對照起來，差異很清楚：
| 手動流程 | Claude 加 MCP 加排程 |
|---|---|
| 逐一登入平台、匯出 CSV | 一次對話同時查多個來源 |
| 記 GAQL 語法或後台路徑 | 用中文問問題 |
| 人記得月初手動跑 | 機器定時自動跑並產檔 |
真正的槓桿在於這三段工作被接成一條線之後，人只需要在最後讀報告、下判斷，前面的搬運全部交給機器。當投放端開始自動化，報告端的自動化需求往往隨之浮現，這也是許多團隊看完 Google AI Max 這類自動化投放工具的完整解析後，會接著把「報告」這一段一起處理掉的原因。
同一套 MCP 標準，各家廣告平台做出了不同的取捨
MCP 是一個開放標準，各家廣告平台都能自行實作，所以我們可以直接比較各家怎麼做，以及這些差異對品牌意味著什麼。
Google Ads 官方 MCP server。Google Ads API 團隊在官方開發者部落格宣布開源這套 Google Ads MCP server，它目前是唯讀設計，只提供三個工具：search（用 GAQL 跑報表）、get_resource_metadata（查資源結構）、list_accessible_customers（列出可存取的帳號）。實際用起來，你可以請它跑出「各檔活動近 30 天的花費、點擊、轉換與 ROAS」，或「哪些關鍵字的成本高於平均卻沒有轉換」，但它不會替你動任何設定。根據 Google 官方開發者文件，它能查詢分析，卻不能改預算、加關鍵字或開關檔案。值得注意的是，唯讀是刻意的產品選擇，不是技術做不到，Google Ads API 本身是支援寫入的。
Meta 與 TikTok 的後續動作。進入 2026 年，平台之間出現一波軍備競賽。根據 Digiday 的報導，TikTok 在 TikTok World 上宣布推出自家 Ads MCP server，讓第三方 AI agent 能操作活動；不過目前仍為宣布階段，正式規格與上線時程未定，尚未看到公開的開發文件與工具清單。也有第三方整理指出 Meta 版的 MCP 被設計為支援寫入、可直接建活動與調預算（此為媒體與代理商二手整理，Meta 官方規格與正式上線狀態仍需以官方公告為準，引用時請保守看待）。
把幾家放在一起看，取捨就浮出來了。Google 選擇先讓 agent「看得到但動不了」，把安全邊界放在最前面；其他平台則更早往「看得到也動得了」推進，功能更大，風險也更大。對品牌而言，這條可寫入的路要不要走，得先看內部的核准流程與監控能不能跟上：讓 AI 直接改預算，等於把一部分投放決策權交給機器，一旦邏輯判斷失準，燒掉的是真實的廣告費。對只想先把報告自動化、還不打算讓 AI 直接改帳戶的品牌來說，唯讀反而是個安心的起點：讀取數據出不了大錯，改動預算才是需要嚴格把關的地方。先用唯讀把報告這一段跑順、把數據口徑對齊，等內部流程成熟了再考慮開放寫入，是比較穩的順序。更現實的是，就算每一家都端出 MCP，跨平台歸因與口徑對齊的難題依舊在，這也正是 Meta 2026 歸因大改版這類變動一再提醒我們的：數據兜不兜得攏，比工具本身更關鍵。
表面是報告變快，背後是一整套協定與一個前提
從表面看，這件事就是「報告從吃掉兩週變成自動排程數分鐘產出」。往下一層看機制，再往下看，會碰到一個很多人跳過的前提。
先看機制。MCP 是 Anthropic 在 2024 年 11 月 25 日發表並開源的標準，它解決的是所謂 N×M 的整合問題：過去每接一個資料來源就要寫一套專屬串接，三個廣告平台就要寫三套，再加上 GA4、CRM、電子報工具，串接數量會像乘法一樣膨脹。MCP 把它變成「平台實作一次 server、AI 端實作一次 client，就能互通」，把 N×M 降成 N＋M。在廣告報告的場景裡，這代表 Claude 不需要為 Google、Meta、GA4 各寫一套整合，而是透過同一種協定跟它們對話，查回來的資料再由 Claude 彙整成人看得懂的報告。這也是 MCP 與 RAG 常被一起討論的原因，我們在拆解 CDP 的 AI 迷思時談過這兩者的分工：一個負責讓 AI 連得上工具，一個負責讓 AI 讀得懂你的資料。
再往下，是一個容易被跳過的前提：報告品質，取決於它背後那份第一方數據的品質。這件事在 2026 年變得更明顯。Google Marketing Live 2026（5 月 20 日主場舉行，21 日為 EMEA 場）整場的主軸，就是把 Gemini 變成 Google Ads 的作業系統、全面走向 agentic 化。其中跨產品的統一 agent「Ask Advisor」，能橫跨 Google Ads、GA4、Merchant Center 與 GMP，目前以英文 beta 先行。根據 Search Engine Land 的整理，Ask Advisor 看得到 Google 自家的產品，卻看不到 Meta、TikTok、你的 CRM，那些跨來源的問題仍需要另一套機制去接。同一場還發表了把開源行銷組合模型 Meridian 併進 Analytics 360、以及用 Gemini 預測未來價值的 Qualified Future Conversions（QFC，限量 pilot）。
這裡要特別分清楚：Ask Advisor、Meridian 進 Analytics 360、QFC 是 GML 2026 當場的新發或深化；而 AI Max、Smart Bidding Exploration 這些是 2025 年先發、2026 年延續強化的功能，不要張冠李戴。搞混了誰是新發、誰是延續，寫進報告的脈絡就會失準。
底下這件事才是重點：無論是 MCP 讓 agent 幫你查、還是 Google 讓 Gemini 幫你算，agent 讀到破碎的第一方數據，就只會給你破碎的答案。跨平台報告最難的從來不是把數字放到同一張表，而是確認這些數字講的是同一群人。同一位顧客在 Google 被記成一個裝置、在 Meta 被記成另一個帳號、在 GA4 又是第三個 ID，報告上的加總看起來完整，實際上是把三個影子加在一起。這一點，也是廣告微轉換這類衡量指標之所以重要的原因：衡量的顆粒度與乾淨度，決定了報告值不值得信。
報告對得起來的前提：OMO 歸戶與乾淨的第一方數據
把上面那個前提翻成品牌的實際場景，就會碰到 91APP 團隊天天在處理的問題。
一個顧客在官網下單、在門市刷卡、又在 App 逛過，如果這三筆行為在你的系統裡是三個不同的人，那麼任何跨平台廣告報告都會算錯：線上廣告帶來的來客，可能其實在門市完成消費，卻被記成沒有轉換。這時候 agent 再聰明、MCP 接得再順、排程跑得再準，產出的報告仍然對不起來。你會在報表上看到某檔線上活動「成效不好」而砍掉預算，實際上它把人帶進了門市，只是系統沒把這兩端接起來。
顧客數據平台這類工具真正要解決的，是先把同一個人在不同通路的身分歸成一戶，讓每一筆廣告花費對應到真實的顧客與真實的成交。以 91APP 的 CDMP 為例，它的方法是先做 OMO 資料整合與會員歸戶，把線上線下的行為串成一個完整的顧客輪廓，再把這份乾淨的第一方數據餵給下游的廣告與衡量工具。順序不能顛倒：先歸戶、再自動化。歸戶做好了，MCP 加 Claude 產出的跨平台報告，數字才兜得攏；歸戶沒做，自動化只是把錯誤算得更快而已。
換句話說，自動化解決的是「快」，歸戶解決的是「準」。兩者缺一，月報都不能真正拿來做決策。一份跑得飛快卻把顧客算成三個人的報告，比慢慢做但算對的報告更危險，因為它讓你更有信心地做錯決定。這也是為什麼我們在協助品牌客戶時，會先確認顧客身分有沒有歸戶，再談要接哪幾個平台：平台接得再多，底層的人算不準，上面疊多少自動化都只是把偏差放大。把歸戶當成整條自動化流程的地基，後面每一層才站得穩。
先把數據整乾淨，再讓機器每月自動把報告跑出來
想真正落地，不需要一次到位。以下四個動作由淺入深，任何規模的團隊都能照著走。
- 先跑通一個平台的唯讀查詢。從 Google Ads 官方 MCP server 開始，它唯讀、風險低，自架在本地或用 Cloud Run 都行，但仍需要 developer token 加 OAuth 授權。先讓 Claude 能用中文問出一份基本報表，確認數字跟後台一致，建立信心之後再往外擴。
- 把最耗時的固定問題寫成模板。月報裡真正每次都要問的問題其實不多，例如各檔活動花費、依裝置拆分的轉換、週對週趨勢、成本過高卻沒轉換的關鍵字。把這幾題連同想要的表格格式固定下來，交給 Claude 每次照跑，產出的結構每個月都一致，主管也讀得順。
- 加上排程，讓它每月自動跑一次。用作業系統的排程機制（cron 或命令列腳本的概念）設定每月固定時間執行，產出的報告自動存到指定資料夾，人只需要在月初打開來讀。若某個月數字有異常，人只需要在讀的階段介入處理，省去每個月從頭撈起的功夫。
- 在動自動化之前，先把顧客歸戶與第一方數據整乾淨。這一步用得上顧客數據平台把 OMO 會員歸成一戶，確保報告裡的每一筆數字對應到真實的人；這也是 91APP CDMP 這類平台在整條流程裡的位置。數據乾淨了，前面三步產出的報告才有決策價值。
四個動作裡，前三個決定你跑得多快，第四個決定你的報告能不能信。順序上，建議把第四件事當成長期的基礎工程並行推進，不要等到報告都自動化了才發現數字對不起來。實務上最好的節奏，是一邊讓工程團隊把歸戶做扎實，一邊讓行銷團隊先在唯讀查詢上練手，兩條線在報告自動化的那一刻剛好會合。
機器省下的兩週，該還給判斷
回到月初那間會議室。當搬運、貼上、對欄位這些動作被機器接手，行銷人手上多出來的不是空白，而是本來就該屬於他們的那件事：看著一份對得起來的報告，決定下個月的錢要往哪裡放。
工具會一直變，今天是 MCP，明天可能是更聰明的 agent。但有一件事不會變：機器只能把你餵給它的數據算得更快，算不出你沒有整理過的真相。把數據整乾淨、把身分歸成一戶，是這條路上唯一不會過時的功課。省下的兩週還給判斷，這才是自動化真正的意義。
FAQ
Q1: 用 Claude 加 MCP 跑廣告報告，和直接用平台內建的報表工具差在哪？ 差別在跨平台整合與自然語言。平台內建工具只看得到自家數據，你仍要手動把 Google、Meta、GA4 拼在一起；透過 MCP，Claude 可以在一次對話裡向多個來源取數再彙整，而且你用中文問問題，不必記各平台的操作路徑或查詢語法。
Q2: Google Ads 官方 MCP server 能不能自動調整預算或暫停活動？ 不能。根據 Google 官方文件，它目前是唯讀設計，只能查詢分析，提供 search、get_resource_metadata、list_accessible_customers 三個工具，無法改預算、加關鍵字或開關檔案。唯讀是刻意的產品選擇，對只想先自動化報告的團隊反而更安心。
Q3: 設定這套自動化需要會寫程式嗎？ 基本的查詢與對話不需要寫程式，用中文問即可。但要把 MCP server 架起來（自架在本地或 Cloud Run）、設定 developer token 與 OAuth 授權、以及用排程機制定期執行，會需要一點技術協助。建議先跑通單一平台的唯讀查詢，再逐步加排程。
Q4: 為什麼說報告品質取決於數據品質？ 因為 AI agent 只是把你的數據算得更快，不會自動修正錯誤。如果同一個顧客在官網、門市、App 的行為在系統裡是三個不同的人，跨平台報告就會把成效算錯，把該留的預算砍掉、把該砍的預算留下。數據沒歸戶，自動化只是把這些錯誤更快地印在報表上。
Q5: 跨通路的顧客身分要怎麼歸成一戶？ 這正是顧客數據平台要解決的問題。它先把同一個人在線上線下不同通路的行為串成一個完整輪廓（OMO 歸戶），再把這份乾淨的第一方數據餵給下游的廣告與衡量工具，讓每一筆廣告花費對應到真實的顧客與成交。
Q6: 除了 Google，Meta 和 TikTok 也有官方 MCP 嗎？ 2026 年上半年各大平台陸續有動作，但成熟度不一。TikTok 在 TikTok World 上宣布自家 Ads MCP server，目前仍屬宣布階段、正式規格與上線時程未定；也有二手整理指出 Meta 版支援寫入。各平台的正式規格與上線狀態變動快，建議以官方公告為準，不要只憑媒體或代理商的整理就下判斷。