2026 年如何衡量 AI 購物可見性

AI 購物可見性已經從概念討論，變成電商團隊每星期都要管理的經營問題。商品可能出現在 Google AI Mode、AI Overviews、Gemini、ChatGPT Search、Copilot、市集助手或零售媒體的 AI 體驗裏，但每個渠道給出的數據粒度都不一樣。有些平台開始提供官方報表，有些仍然只能從 referrer、品牌詞搜尋、商品頁行為和購買後問卷裏看到間接線索。

比較成熟的做法，不是把很弱的信號包裝成精準歸因，而是建立分層衡量模型：有官方報表就用官方報表；沒有報表就清楚標記盲區；每一次可見性覆盤都要連到商品資料或內容實驗，而不是停留在「感覺有沒有被 AI 看見」。

衡量地圖

AI 購物可見性至少要拆成七層。

第一層是資格條件：頁面需要允許抓取、可以索引、可生成摘要、有內部連結，而且重要商品資訊必須以用戶可見的文字出現。Google Search Central 已說明，AI Overviews 和 AI Mode 仍然沿用基礎 SEO 原則，不需要為 AI 另外建立某種特殊檔案或特殊 schema。

第二層是 Search Console。Google 在 2026 年 6 月推出 Search Generative AI performance reports，Search 報表會逐步開放給部分站點，用來查看 Google Search 生成式 AI 功能裏的展示數據，包括 AI Overviews 和 AI Mode。幫助文檔顯示，報表可以按頁面、國家、裝置和日期分組。這是重要進展，但它主要解決「展示可見性」，不等於完整 prompt、點擊、收入和份額歸因。

第三層是 Merchant Center。Google 在 2026 年 5 月 27 日宣布 Merchant Center AI performance insights，用來理解商品在 AI Mode、AI Overviews 和 Gemini app 等 AI 購物旅程中的發現方式。報表覆蓋 share of voice、購物漏斗、product term insights 和 product attribute insights，並先從美國、加拿大、澳洲、印度和紐西蘭逐步推出。

第四層是第一方分析。商家自己可以控制 referrer、UTM、落地頁、商品頁互動、加購、結帳啟動、訂單、復購和購買後問卷。AI 輔助發現可能被記錄為 direct、品牌搜尋、普通 referral 或之後的回訪，所以第一方分析更適合比較 cohort 和行為模式，而不是強行為每張訂單貼上一個精準 AI 來源標籤。

第五層是人工 AI 表面抽樣。團隊需要為重點商品建立固定 prompt 集：類目意圖、問題意圖、比較意圖、預算意圖、兼容性問題、配送問題和退貨政策問題。結果不是完美排名追蹤，但能發現缺失屬性、薄弱商品文案、政策內容缺口，以及 AI 回答和自有站商品事實之間的不一致。

第六層是結構化商品資料。Product JSON-LD、Merchant Center 屬性、PDP 可見文案、圖片、價格、庫存、配送和退貨資訊應該描述同一份商品事實。Google 的 Product structured data 文檔說明，結構化商品資訊能幫助商品詳情以更豐富形式出現在 Search 結果中；Merchant Center AI insights 的公告也把商品屬性完整度放在很重要的位置。

第七層是實驗日誌。沒有實驗日誌，可見性覆盤很容易變成觀點會議。每次都應該記錄商品範圍、日期、改動欄位、改動頁面、預期信號和觀察窗口。比如 6 月 12 日給 20 個商品補充材質和適配屬性，兩星期後同一組頁面的生成式 AI 展示、Merchant Center 屬性缺口、人工 prompt 描述準確性和商品頁互動是否同時改善。多層信號同向變化，比單個圖表更有判斷力。

用新的 Search Console 報表讀數

現在 Search Console 至少有兩層可用數據。標準 Performance report 仍然包含 AI 功能在整體 Web search 裏的數據。新的 Generative AI performance report 在帳戶有權限且有足夠展示時，會提供生成式 AI 功能的獨立展示視圖。

這會改變舊版判斷。團隊不應再籠統說 Google 完全沒有 AI 可見性報表。更準確的操作方式是：先檢查站點是否有 Generative AI report；如果有，用它看展示趨勢、頁面、國家、裝置和日期；如果沒有，就記錄原因，再用 Web search 趨勢做基線。

但這個報表仍然有邊界。它重點是 impressions，不是完整電商歸因；它不會把每次 AI 互動還原成已知 query、已知 session 和已知訂單；Search Labs 實驗數據也不包含在內。每星期要問的問題不是「這個報表能不能解釋所有訂單」，而是「關鍵頁面在支援的生成式 AI 功能裏是否更容易被展示，變化是否和商品資料或內容改動吻合」。

用 Merchant Center 看商品發現信號

Merchant Center 的價值在於商品層。AI 購物可見性很多時候不是文章層問題，而是商品事實是否足夠清晰、完整和一致。Google 描述的 Merchant Center AI insights 會覆蓋品牌 share of voice、購物漏斗表現、用戶 session 裏的 product terms，以及用戶常問但商品 feed 裏缺失的屬性。

這能幫助團隊做優先級排序。不要試圖一天內把所有欄位都補到同樣深度。先處理高收入商品、高毛利類目、已有搜尋需求的商品，以及屬性直接影響購買信心的商品。如果 Merchant Center 顯示某個商品族缺失顏色、材質、尺寸、風格或用途資訊，這個商品族就應該進入資料清理計劃。

如果帳戶暫時還沒有 AI insights，也不用停工。Merchant Center 診斷、feed 狀態、商品審核狀態、屬性覆蓋、標題和描述質量、配送與退貨設定、落地頁一致性，都是可用的代理信號。這些信號不如 share-of-voice 圖表吸引人，但它們是 AI 購物系統理解商品的基礎。

建立點擊後的第一方鏈路

外部報表很少能解釋消費者到站後的行為。第一方分析要記錄商家能控制的部分：source、medium、referrer、落地頁、商品頁、加購、結帳啟動、支付嘗試、訂單、貨幣、市場、裝置和回訪。

Foundax 已支援 storefront analytics、source 維度流量拆分、頁面與漏斗分析、商品分析，以及和訂單關聯的 analytics session 欄位。團隊可以比較 AI-adjacent referral、品牌詞回訪、內容頁訪問、商品頁訪問和 direct 回訪之間的行為差異。真正有價值的問題不是「AI 有沒有提到我們」，而是「消費者到站後是否看到足夠清楚的商品事實，並繼續進入購買漏斗」。

購買後問卷可以補一部分歸因缺口。一個簡單問題，例如「你最早在哪裏比較過這件商品」，能捕捉到瀏覽器 referrer 沒記錄的 AI 輔助發現。問卷數據只能作為抽樣證據，但經常能解釋 direct 或品牌搜尋背後的前序旅程。

把人工檢查當作研究方法

人工檢查必須結構化。選擇穩定的商品集和 prompt 集，覆蓋類目、問題、比較、預算、兼容性、配送和退貨。按固定周期執行，並盡量保持市場、語言和登入狀態一致。

記錄五件事：品牌是否出現、商品是否出現、提到了哪些屬性、展示了哪些來源連結、哪些事實錯誤或缺失。如果商品被描述成錯誤材質、尺寸資訊不清、退貨限制缺失或價格過舊，修復點通常在商品資料、PDP 文案、結構化資料、Merchant Center 欄位或政策內容裏。

人工測試不應被視為精準排名系統。樣本太小，AI 回答也會變化。它的角色是診斷：幫助團隊看到消費者可能聽到甚麼，以及自有站商品事實哪裏需要加強。

把衡量變成實驗

一個好實驗應該有一個商品族、一個買家問題、一組欄位和一個觀察窗口。例子包括：給高客單服飾補充材質和護理屬性；重寫 PDP FAQ 回答兼容性問題；給高決策成本商品補充配送和退貨說明；讓 Product JSON-LD 與頁面可見價格、庫存保持一致；為強調視覺屬性的商品優化圖片 alt 和圖注。

改動前記錄 Search Console 生成式 AI 展示、標準 Search Console 頁面趨勢、Merchant Center 診斷或 AI insights、第一方 PDP 行為和人工 prompt 結果。改動後看同一組指標。多個層面同向變化時，判斷更穩；只有單個圖表變化時，應標記為假設，而不是結論。

用 Foundax 管理自有站層

Foundax 的作用在於把可衡量輸入放在同一條營運線上：商品記錄、SEO 元數據、Product JSON-LD 預覽、sitemap 輸出、Search Console 驗證和 sitemap 提交流程、Merchant Center 預檢、多語言內容、Content Studio 發布，以及第一方 analytics。AI 購物可見性通常不是一個欄位能解決的問題，它依賴頁面、結構化資料、feed 与页面一致性、政策內容和到站行為的一致性。

實際流程可以很清晰：選擇商品集，清理商品事實，發布 PDP 和支持內容，驗證結構化資料與 Google 工作流，需要時提交 sitemap，觀察 Search Console 和 Merchant Center 信號，再比較第一方互動和訂單行為。這樣團隊得到的是可重複的營運閉環，而不是一次性可見性檢查。

覆盤節奏

每星期只看少量關鍵項：Search Console 生成式 AI 展示、標準 Search Console 頁面變化、Merchant Center 診斷或 AI insights、source 和落地頁趨勢、商品頁互動、加購、結帳啟動，以及小樣本 prompt 記錄。

每月擴大範圍：刷新 prompt 集，比較商品族，覆盤購買後問卷，整理缺失屬性，並按收入潛力決定下一輪實驗。每季度刪掉弱指標和虛榮大盤，判斷這套衡量系統是否真的讓團隊更快發布更清晰的商品事實。

常見問題

Search Console 能衡量 AI Mode 和 AI Overviews 嗎？

可以，但要看站點是否已經獲得 Google Generative AI performance report。該報表展示 Google Search 生成式 AI 功能的 impressions，包括 AI Overviews 和 AI Mode。沒有該報表時，應使用標準 Performance report 做整體 Web search 基線。

Merchant Center AI performance insights 每個商家都有嗎？

Google 說明該功能會先在部分國家逐步推出，包括美國、加拿大、澳洲、印度和紐西蘭。沒有權限的商家仍可用診斷、feed 健康度、商品審核狀態和屬性完整度做代理信號。

第一方分析能識別所有 AI 輔助訂單嗎？

第一方分析更適合比較 source cohort、落地頁、商品頁行為、漏斗變化、回訪和問卷結果，而不是把每張訂單都歸因到某個 AI 表面。

AI 購物可見性多久檢查一次？

活躍商品集每星期檢查即可。只有在新品發布、遷移、feed 異常或重大商品資料實驗期間，才需要更高頻監控。

優先測試哪些商品資料？

先看影響購買信心的欄位：材質、尺寸、兼容性、價格、庫存、配送、退貨、護理說明、使用場景和 PDP FAQ。高毛利和高需求商品優先於長尾商品。

2026 年如何衡量 AI 購物可見性