Ask Advisor 這類 agent 再強，也救不了破碎的第一方數據（2026）

季度檢討會開到第三十分鐘，一位行銷主管把問題丟給螢幕上的 AI 助理：上週的轉換率為什麼掉了兩成。助理三秒內回了一段流暢、自信、條理分明的答覆，把矛頭指向某一檔廣告活動的出價設定。會議室裡的人點頭如儀，直到有人翻開後台，發現那檔活動上週根本沒有人動過。答案講得漂亮，卻對錯了對象。

問題不在 AI 不夠聰明。根據 MuleSoft 2025 年 Connectivity Benchmark Report，一家企業平均使用 897 個應用程式，其中只有 29% 彼此串接。另一份由 Salesforce 於 2025 年 11 月發布的 State of Data and Analytics 調查 則指出，資料與分析主管估算公司裡有 19% 的資料被鎖在孤島、無法存取或難以使用，而其中七成的主管相信，公司最有價值的洞察，就藏在那個碰不到的 19% 裡面。這兩個數字分屬不同機構的調查，前者談應用程式的串接率、後者談資料的可用率，細項比例以各自完整報告為準。

當一個 agent 只讀得到片段的資料，它給的答案再流暢，也只是把片段講得好聽。這不是模型的能力問題，是它腳下那塊地基的問題。而 2026 年這一整年，行銷圈最熱鬧的新聞，恰好全部押在 agent 身上。那麼問題就變成：這些愈來愈強的 agent，到底能不能救得回一份破碎的資料？

我們在實測畫面裡看到的分岔

我們 91APP 團隊今年陪不少品牌一起看過 Ask Advisor、AI Max 這類新工具的實際操作畫面。一個反覆出現的場景是：同一個問題，在資料乾淨的品牌後台問，agent 答得又快又準，讓人眼睛一亮；換到資料四散、線上線下各記各帳的品牌，同一個 agent 就開始給似是而非的建議，看得人有點尷尬。

工具沒有變，變的是它讀到的東西。這件事一旦看多了，就很難再把注意力只放在模型本身。

agent 好不好用，是三件事疊起來的結果

一個 agent 最後好不好用，其實是三件事疊起來的結果，由上往下分別是能力、連接、地基。

能力是大家最愛談的一件事，也就是模型本身。Ask Advisor 用 Gemini 驅動，能跨產品、能對話、能主動給下一步建議，這一塊在 2026 年進步神速。AI Max 這類 2025 年先發、2026 年延續強化的投放工具，本質上都在幫品牌把能力這一塊補到滿，而且補得又快又便宜。

連接是 agent 讀得到哪些資料源。這一塊決定了 agent 的視野邊界：它看得到 Google Ads、看得到 GA4，卻看不到你的門市 POS、看不到你的會員系統，也看不到 Meta 或 LINE 上的互動。視野有缺口，跨通路的問題它就答不完整。

地基是那些資料本身乾不乾淨、有沒有歸戶。同一個人在官網、App、實體門市留下的足跡，到底被串成一個人，還是散落成幾筆彼此對不上的紀錄。這一塊最不性感，卻決定了前兩塊的成敗。

這三件事的關係是乘法，不是加法。可以用一張簡單的對照表看清楚各自管什麼：

能力這一塊，Google、Meta 這些平台會幫你補到滿；連接有一部分你能自己決定；地基則幾乎全在你自己手上。偏偏乘法算式裡只要地基趨近於零，前面兩項再高，乘出來的結果都趨近於零。這也是為什麼「換一個更聰明的 agent」很少解決得了「答案不準」這件事。要說明的是，把能力、連接、地基寫成相乘，只是一個幫助理解的框架，用來凸顯地基的決定性；它不必然是嚴格的數學關係，實務上三者仍可能各自部分貢獻，例如連接雖窄、只要單一平台內的資料乾淨，agent 在那個平台內還是給得出堪用的答案。這個框架真正想提醒的是：地基一旦崩了，能力再高也拉不回來。

很多品牌會在這裡卡住，因為市場上所有的行銷資源、所有的產品發表會、所有的話題聲量，幾乎都堆在能力那一塊。新模型、新版位、新格式，每一季都有更亮眼的東西可以追，追起來也最有成就感。地基那一塊剛好相反：它埋在看不見的地方，做好了沒人拍手，做不好卻拖垮全部。於是資源自然往聲量大的地方流，往看得見成果的地方流，久而久之，能力愈補愈滿，地基卻一直懸在半空。等到 agent 真的上線、開始給出對不上號的答案，大家才回頭發現，問題早就埋在當初沒人想碰的那一塊。

三個 2026 年的具名事件，把乘法算式攤開來

把鏡頭拉到 2026 年三個具名的事件，這條乘法算式就一目了然。

Ask Advisor 是 Google 在 2026 年 5 月的 Google Marketing Live 2026 上發表的統一 agent，用 Gemini 打通 Google Ads、GA4、Merchant Center 與 Google Marketing Platform，目前英文 beta 先行、其餘語言與版位年內陸續開放。它的能力確實驚人，你可以直接問「為什麼上週轉換率掉了」，它會跨產品把資料調出來回答。但 Search Engine Land 對 GML 2026 的完整整理 也點明一個邊界：它的視野止於 Google 自家生態，看不到 Meta、看不到 LINE、看不到你的門市會員資料（此為產業媒體整理，功能範圍與上線時程以 Google 官方公告為準）。能力滿分，連接卻先天有牆。跨通路的行銷主管很快就會撞到這道牆。

在平台的另一端，連接這一塊在 2026 年上半年被各家平台以驚人的速度補齊。Amazon Ads 在 2 月率先推出官方 Ads MCP server 的 open beta，Google 於 4 月 28 日發表唯讀版的官方 Google Ads MCP server，Meta 隔天（4 月 29 日）跟上、推出官方的 Meta Ads AI Connectors（一套 MCP server 加 CLI），TikTok 則在 5 月 13 日的 TikTok World 上宣布自家 Ads MCP Server，成為第四家。Ad Age 對這一波大廠 Ads MCP server 的整理 把它形容為即將改寫媒體採買方式的訊號。這些 server 讓 AI 工具能直接接進廣告帳號查資料、下指令，其中 Meta 版本走的是可寫入路線（預設暫停、需人工放行），Google 版本則刻意維持唯讀（以上為 Ad Age 等產業媒體的整理，各平台的實際權限範圍與上線時程以官方文件為準，TikTok 版本截至 6 月初仍屬宣布階段）。這代表連接這一塊正在被各家平台快速補齊，agent 能碰到的資料源愈來愈多。連接補得愈快，地基不穩的代價反而愈大，因為一個看得更多、又能動手的 agent，若讀到的是錯的資料，闖的禍也更大。

這裡也順帶點出一個容易被忽略的落差。WordStream 對 Google Marketing Live 2026 的重點整理（產業媒體整理，細節以 Google 官方公告為準）把整場活動的主軸總結為 Gemini 全面接手 Google Ads 的運作，能力躍進是實打實的。但能力躍進的前提，是它有一份夠好的資料可以讀。這場活動絕大多數的鎂光燈都打在模型與版位上，很少有人停下來問一句：如果餵進去的資料本身就對不上號，這些能力要往哪裡使力。這道落差要靠每一個要用這些工具的品牌自己補起來，Google 幫不上忙。

把時間再往前拉的政策這件事，卻更能說明地基為什麼碰不得。跨平台的顧客識別本來就在重整，Meta 在 2026 年的歸因大改版就是最新的一例，各家平台對「這筆轉換算誰的」定義一直在變。更關鍵的是，2025 年 4 月 Google 正式放棄在 Chrome 棄用第三方 Cookie 的計畫，此後也逐步收斂 Privacy Sandbox 的相關 API。OneTrust 引述 Google 官方 Privacy Sandbox 聲明的整理 說得直白：Chrome 不會再跳出讓使用者選擇是否封鎖第三方 Cookie 的畫面（此為廠商部落格對 Google 聲明的轉述，實際政策與時程以 Google 官方公告為準）。這件事表面上像是「Cookie 不用擔心了」，實際的訊號正好相反：連 Google 這種規模的平台，都給不了你一套穩定、可長久依賴的外部識別，你能真正握在手裡、不會被政策一夕改寫的，只剩下自己的第一方數據。

答案不準只是表象，真正的問題卡在沒人願意做的歸戶

把這件事一層一層挖下去，會看到三件不同的東西。

表象是大家都感受得到的：agent 有時候給的答案很準，有時候一本正經地胡說八道。這是使用者唯一直接碰到的。

機制藏在 agent 怎麼拿到資料。以 Google 官方的 Google Ads MCP server 為例，根據 Google 官方開發者文件（文件於 2026 年 6 月更新）與 googleads/google-ads-mcp 官方 repo，它目前只提供三個工具：search（用 GAQL 查報表）、get_resource_metadata（查資料結構）、list_accessible_customers（列出可存取的帳號）。它是唯讀的，不能改預算、不能加關鍵字、不能開關廣告活動。值得注意的是，Google Ads 開發者部落格的說明 講得很清楚：唯讀是一個安全上的設計選擇，不是技術做不到，Ads API 本身是支援寫入的。MCP 本身則是 Anthropic 在 2024 年底提出的開放標準，作用就是把外部資料源接到模型面前。MCP、RAG 這些技術名詞常被講得像魔法，實際上它們只負責把資料搬到模型眼前，搬進去的東西不乾淨，出來的答案照樣不乾淨。

底層才是真正決定成敗、卻誰都不肯花力氣做的那件事：歸戶。一個 agent 就算連接打通了、就算哪天拿到寫入權限了，它送進模型的那份資料，如果本身就是線上一筆、App 一筆、門市一筆，三筆各記各帳、認不出是同一個人，模型能做的也只是把這份殘缺的資料整理得漂漂亮亮，然後在拼不齊的基礎上給你一個站不住腳的判斷。這正是這一整個系列反覆講的一件事：agent 讀到破碎的第一方數據，就會給你破碎的答案。它不會因為模型換成更新的版本而變好，因為那從來就不是模型的問題。

這件事之所以難，是因為它的成本落在一個很尷尬的位置。歸戶不是買一套工具、按一個開關就完成的，它牽涉到把官網、App、門市 POS、會員系統這些原本各自獨立的系統，用同一把識別的鑰匙重新對齊。這中間有技術工程，也有跨部門的協調：門市那邊願不願意在結帳時多問一句會員身分，官網這邊願不願意調整既有的資料欄位，行銷與資訊部門願不願意坐下來把「一個人」的定義講清楚。這些都不是模型能替你做的決定。也正因為它跨了這麼多人、這麼多系統，一旦拖著不做，愈往後補，資料裡累積的錯認就愈多，清理的代價也就愈高。agent 的能力每季都在變便宜，這塊地基的補救成本卻是隨時間變貴的。

這種協調的難，在會議室裡看得最清楚。我們陪品牌討論歸戶時，不只一次見到這樣的場景：行銷坐在一頭，說我要的是同一個人的完整輪廓；資訊坐在另一頭，說門市系統十年前就這樣寫，改一個欄位要排三個月的工；門市主管則擔心結帳時多問一句會員綁定，會拖慢正在排隊的隊伍。每個人講的都對，也都各有難處，於是歸戶這件事就一次又一次被推到下個季度再說。等到 agent 真的上線、開始給出對不上號的答案，大家才惋惜地發現，當初那場沒開完的會，才是真正的關卡。歸戶從頭到尾都不只是技術題，它更是一群人願不願意先坐下來、把「一個人」的定義講清楚的組織題。這也是它最難、卻最無法外包給任何工具的原因。

把 agent 站上去之前，先確認它腳下站得穩

講到這裡，該把 CDMP（顧客數據平台）放進這條算式的哪個位置，就很清楚了。它不搶能力這一塊的戲，Gemini、AI Max 那些工具已經把能力補得夠好；它處理的是地基。

91APP CDMP 的方法論，說穿了就是把地基先鋪平的那道工序。它先做 OMO 歸戶，把同一個人在官網、App、實體門市留下的足跡整合成同一位會員，是這塊地基最關鍵、也最難的一步，讓「上週來門市又在官網逛了兩次的那個人」被系統認得出來是同一個人，不再是三筆互不相識的紀錄。地基鋪平之後，agent 讀到的才是一份完整、乾淨、認得出人的第一方數據，它的能力才有東西可以發揮，它的連接才不會把錯的資料接得更快。

換句話說，agent 時代真正的分水嶺，落在誰先把自己的第一方數據整理成 agent 讀得懂的樣子。CDMP 做的就是這件不性感、卻決定上限的事：在 agent 站上場之前，先確認它腳下那塊地基是平的。這也是為什麼同樣一套 Ask Advisor，在不同品牌手上會給出天差地遠的表現，差別從頭到尾都在地基那一塊。

值得一提的是，資料四散在台灣品牌身上相當普遍，稱不上少數個案。根據 Salesforce State of the Connected Customer 第四版（2020 年） 這份跨 27 國、訪談逾一萬五千名消費者與企業買家的調查，有 54% 的顧客覺得，一家公司裡的業務、客服、行銷彼此並沒有共享資訊（此為 Salesforce 官方調查，數字以原報告為準）。顧客感受得到的斷裂，其實就是後台那份沒有歸戶的資料在前台的投影。CDMP 這道歸戶工序要修的，正是這種讓顧客覺得「你們好像不認得我」的斷裂，把散在各部門、各通路的紀錄重新對齊成一位完整的會員。當顧客在前台被當成同一個人對待，agent 在後台才可能把他當成同一個人分析。

先把地基補起來，再讓 agent 上場

台灣品牌現在最該做的，不是急著追下一個更強的 agent，而是先確認手上那份資料撐不撐得起它。以下五個動作，建議依序推進：

1. 先花一週盤點你所有的資料源，畫出一張清單：哪些是 agent 現在讀得到的（Google Ads、GA4），哪些是它讀不到的（門市 POS、會員系統、Meta 與 LINE 的互動）。看清楚視野的缺口在哪，比急著導入工具重要。這張清單同時會告訴你，哪些跨通路的問題，靠單一平台的 agent 永遠問不出正確答案。
2. 把線上與線下的顧客足跡歸到同一個人。這是最難、也最值得投資的一步，透過 CDMP（顧客數據平台）做 OMO 歸戶，讓同一位會員在四散通路的行為被串成一條完整軌跡，agent 才可能給出對得上號的判斷。歸戶做到什麼程度算夠，一個實用的檢驗是：隨手抽一位常客，看系統能不能把他在官網、App、門市的行為攤在同一張臉譜上，如果攤不出來，agent 也攤不出來。
3. 導入 agent 時先用唯讀模式做診斷，不要一開始就給寫入權限。Google 官方 Ads MCP 目前唯讀是刻意的安全設計，你自己導入時也該遵守同一個節奏：先讓它看、確認它看得準，再談讓它動手。唯讀階段其實是最好的資料體檢，agent 答不準的地方，往往就是你資料破洞的地方。
4. 評估與挑選 agent 時，先問它怎麼處理你的資料，再看它的模型多聰明。模型的聰明程度各家差距正在縮小，資料處理能力才是拉開結果的地方。可以直接問供應商三個問題：它怎麼把不同來源的顧客串成一個人、它讀不到的資料源要怎麼補、它給的判斷能不能回溯到原始資料。
5. 建立一套持續累積第一方數據的機制，把每一次官網瀏覽、每一筆門市消費、每一個微轉換都收進同一個人的檔案裡。地基不是一次鋪好就結束，它需要每天都有乾淨的新資料補進來。在第三方 Cookie 政策反覆搖擺的這幾年，這種握在自己手裡、不會被外部政策一夕改寫的資料，價值只會愈來愈高。

這五步走完，你再回頭看 Ask Advisor、看各家 Ads MCP，就不會再問「哪個 agent 比較強」，而會問「我的資料，撐得起哪一種 agent」。

工具換一代，地基只有一塊

回到那間季度檢討會的會議室。真正該擔心的，從來不是 AI 助理答得夠不夠快，而是沒有人知道它腳下那份資料到底乾不乾淨。agent 會愈來愈聰明，這件事幾乎不用懷疑；但它永遠只能誠實地反映你餵給它的東西。一份被串成一個人的資料，換來一個看得懂人的答案；三筆各記各帳的紀錄，換來一段講得漂亮的胡話。

工具會一代一代換，地基卻只有一塊。把地基鋪平的品牌，換任何一個 agent 都用得順；地基坑坑洞洞的品牌，換再新的 agent 也只是把坑講得更好聽而已。這門功課不新鮮，也不熱鬧，卻是 2026 年這場 agent 熱潮裡，唯一不會退流行的一件事。

常見問題 FAQ

Q1: Ask Advisor 能取代整個行銷團隊嗎？ 不能。根據 Google 在 Google Marketing Live 2026 的說明，Ask Advisor 是跨 Google Ads、GA4、Merchant Center 與 GMP 的統一 Gemini agent，強項是省時間、把資料調出來回答問題並給建議。但它給的建議品質，完全取決於它讀到的資料乾不乾淨。它能承擔大量查詢與分析的雜活，判斷方向與策略仍需要人。

Q2: Ask Advisor 看得到 Meta、LINE 或我的門市會員資料嗎？ 看不到。Ask Advisor 的視野目前止於 Google 自家生態（Ads、GA4、Merchant Center、GMP），不涵蓋 Meta、LINE、CRM 或門市 POS。跨這些來源的問題，需要另一層資料整合來補齊，通常是靠一套能歸戶的顧客數據平台把四散資料先串起來。

Q3: Google Ads MCP 可以直接幫我改預算或開關廣告嗎？ 不行。根據 Google 官方開發者文件，官方 Google Ads MCP server 目前是唯讀的，只提供 search、get_resource_metadata、list_accessible_customers 三個工具，能查報表與結構，但不能改預算、加關鍵字或開關活動。官方說明這是安全設計而非技術限制，Ads API 本身支援寫入。

Q4: 為什麼 AI agent 給的答案有時候看起來很準，有時候卻是錯的？ 關鍵多半在它讀到的資料，模型本身其實不是重點。當同一個顧客在官網、App、門市的行為沒有被歸成同一個人，agent 拿到的是破碎片段，它只能把片段整理得流暢，卻無法給出對得上號的判斷。資料愈完整、愈乾淨，答案自然愈穩。

Q5: 導入 AI agent 之前，我的資料要先準備到什麼程度？ 至少要做到跨通路歸戶：同一個人在不同接觸點的行為，能被系統認出是同一位會員。這通常需要一套顧客數據平台先完成 OMO 整合。建議先用唯讀模式讓 agent 做診斷，確認資料讀得準，再考慮開放寫入權限。

Q6: 線上線下資料還沒整合，先上 agent 會怎樣？ agent 會照樣運作，也會照樣給出流暢的答案，風險在於那些答案可能建立在錯認的顧客身上。當各通路各記各帳，agent 可能把同一個人當成三個人來分析，導致投放對象與成效判讀失準。先補好資料整合這塊地基，再讓 agent 上場，代價會小很多。

延伸閱讀

1. NAPLRS／DCIU／XGBoost：把乾淨的第一方數據變成可用的資料模型
2. 如何評估 CDP AI agent：先問這四個問題
3. CDP 在電商 OMO 零售的十大變現場景：資料整合之後能做什麼