[CMO行銷工具] 開發筆記 : Merchant Center 商品健檢（下篇）

CMO 行銷工具 · 開發筆記

Merchant Center 商品健檢（下篇）
AI購物時代，你的商品目錄準備好了嗎？
——CMO 行銷工具完整架構解析

UCP 離台灣還有多遠？

上篇講的是 Google Merchant Center 願意給你的資料——商品能不能被看到、目錄跟網頁說的是不是同一件事、價格在市場上算貴還是算便宜。這篇講的是 Google 還不願意給你的——AI 購物時代，你的商品目錄準備好了沒有。

2026 年 1 月，Google 推出了一個開放標準：UCP（Universal Commerce Protocol，通用商務通訊協定）。白話文講：把「看到商品」到「完成付款」壓縮成同一個畫面。消費者在 Google 搜尋或 Gemini 對話裡問「幫我找一台空氣清淨機」，AI 直接列出商品、建立購物車、完成結帳——不用跳到你的網站，不用打開另一個 App。

目前 UCP 的原生結帳僅在部分市場可用（初期以美國為主），且需要加入候補名單經 Google 審核批准才能上線。台灣尚未開放。

台灣商家看起來事不關己。但 UCP 的明文前提是：Merchant Center 的資料從商品目錄到品牌素材盡可能完整且符合現況。這句話翻譯成人話就是——你的商品目錄不夠完整，就算 UCP 來了台灣，你也接不上。

而「把商品目錄做完整」這件事，不管 UCP 什麼時候來台灣，現在做了就能改善購物廣告和免費產品資訊的成效。上篇講了 374 件商品只有 48% 能被看到——能見度低的主因就是目錄不完整。

在成熟的網路生態裡，已經很少有「早期紅利」的機會了。但 UCP 也許是其中一個：先做好準備的人，台灣一開放就是最早能上線的那一批。這不是賭博，是累積——每一項準備工作都有現在就能看到的收益。

跟前面幾篇的銜接是這樣的：第七、八篇講的 GEO 是「AI 搜尋引擎看不看得到你」。UCP 問的是更下一步：AI 看到了你之後，能不能直接幫消費者完成購買。從被看到，到被選擇，到被結帳——每一層都需要不同的準備。

UCP 準備度六項健檢

CMO 的 UCP 準備度檢查分成六項。系統不生分數，查的是「UCP 開放之後，你能不能接上」的訊號有無。

六項檢查

六項裡，三項已經通過：商品審核通過率 100%（374 件全部通過審核）、運送與退貨政策已設定、地區資格雖然台灣尚未開放但系統會持續追蹤 Google 公告。這三項你現在不需要動。

需要動的是另外三項：

示範代碼：兩種更新方式

系統提供了兩種目錄更新方式的示範代碼，給工程師參考。

第一種是 tsv 補充來源範本——用試算表補上缺的欄位，像是 GTIN 和商品類別。這種方式適合不常變動的欄位：填一次，每 24 小時自動同步。不需要寫程式，行銷人自己操作。

第二種是 Merchant API 的 productInputs.patch——用 API 做部分更新，只改價格和庫存。這種方式適合頻繁變動的欄位：每次價格調整或庫存變化，即時推送更新。需要工程師介入。

兩種方式不能同時管理同一個欄位。Google 的官方警告很明確：補充來源和 Merchant API 的 productInputs.patch 如果同時改同一個欄位，會出現「改了沒生效」的問題，而且查不出原因。後續如果要自動化，只能二選一。

台灣市場的立即解方——補充來源與自訂標籤

UCP 準備度告訴你「還缺什麼」。但知道缺什麼跟能補什麼之間，隔著一堵牆：台灣電商的結構性問題。

電商平台只給你基本欄位

台灣絕大部分的電商經營者，商品目錄是由電商平台自動產生的。平台從你的商品頁面抓資料，填進 Merchant Center 的必填欄位——商品名稱、價格、圖片、庫存狀態。其他更有效的欄位：GTIN、Google 商品類別、附加圖片、自訂標籤——全部空白。

不是你不想填，是平台不讓你填。要改這些欄位，得跟平台方提工程需求，排程開發，等三個月。或者自己寫程式接 Merchant API——但大部分電商經營者沒有工程團隊。

CMO 提供了一個繞過這條路的自救方案。

補充來源：疊一層不覆蓋

Merchant Center 有一個功能叫「補充來源」（supplemental feed）。它的邏輯是：不動你的主要來源（電商平台自動產生的那份目錄），在上面疊一層。疊上去的欄位會補進目錄，沒疊的欄位維持原樣。不覆蓋、不衝突、不需要改網站、不需要工程師。

系統直接給你一份可以複製貼上的範本：兩個欄位，id 和你要補的欄位。id 跟主要來源的商品編號對齊，另一欄填你要補的值。貼進 Google 試算表，設成「知道連結的人可檢視」，綁到 Merchant Center 的補充來源——完成。

六步驟操作流程

系統把整個流程拆成六步，第一次做大約 10 分鐘：

第一步——複製。系統產生一份範本，欄位之間用 Tab 分隔，直接複製到剪貼簿。也可以下載 CSV 帶走。

第二步——貼進試算表。新建一份 Google 試算表，貼進 A1 儲存格。注意：如果商品編號是純數字或以 0 開頭，先把整欄設成「純文字」格式再貼，否則試算表會自動改寫編號，後續配對全部失敗。

第三步——共用。把這份試算表的共用權限設成「知道連結的人可檢視」，讓 Merchant Center 讀得到。

第四步——綁定補充來源。進 Merchant Center 的「設定 → 資料來源 → 補充來源」，新增一份補充商品資料，綁這份試算表的網址。如果找不到「補充來源」分頁，先到「設定 → 外掛程式」啟用「進階資料來源管理」。

第五步——指定主要來源。告訴系統這份補充來源要疊在哪一份主要來源上面。你填的語言和商品標籤格式，必須跟主要來源完全一致——id 的大小寫、空白字元都要一字不差。這一步做錯，全部失效。

第六步——同步。補充來源預設每 24 小時自動同步。需要立刻看到結果，可以在資料來源頁面點「立即更新」手動觸發。同步完之後，回商品清單確認欄位確實更新了——避免 id 配對失敗的靜默失效。

自訂標籤：區分高低毛利 SKU

補充來源能填的不只是 GTIN 和商品類別。最有價值的是五個自訂標籤欄位：custom_label_0 到 custom_label_4，Google 給廣告主自己用的欄位——不影響商品審核，但影響廣告投放的精準度。

系統對這五個欄位的白話文解釋是這樣的：custom_label_1 是空欄位，需要你自己填毛利等級——高、中、低。Google 沒有任何毛利相關的欄位，系統算不出來，你填了就是你自己的判斷。custom_label_0 是「Google 根據你的成效數據自動標記的表現等級」——這件商品在廣告裡跑得好不好，Google 已經有數字，幫你標好了。兩個欄位配合，就能決定哪些商品要投廣告、哪些不要。另外三個（custom_label_2 到 4）目前系統沒有預設用途，留給你自由使用——比如標記季節性、庫存週轉率、通路專屬。

具體做法：用 custom_label_1 標記每件商品的毛利等級——「高毛利」「中毛利」「低毛利」。然後在 Google Ads 的廣告活動裡，用這個標籤分群——高毛利商品加大投放，低毛利商品降低出價或直接排除。

排除有兩種做法。第一種是用 custom_label_0 分群，到 Google Ads 的活動裡排除——優點是靈活，隨時可調。第二種是直接在商品目錄裡用 excluded_destination 欄位填上 Shopping_ads——商品根本不會出現在付費購物廣告裡，但仍然出現在免費產品資訊版位。優點是徹底。

這兩種做法的差別是：第一種是「暫時不投」，第二種是「根本不要出現」。看你的需求選。

對 SKU 超過上千件的電商經營者來說，這個功能非常立即有用。上千件商品裡，高毛利和低毛利混在一起，廣告預算平均分配等於浪費。用自訂標籤分群，把預算集中在高毛利商品上——這件事不需要工程師，10 分鐘做完，效果立刻反映在廣告帳號裡。

同一份目錄，三個平台——Google、META、O2O

你的商品目錄不是只有 Google 在用。同一份 feed，META 的廣告系統也在讀。如果你有實體店面，O2O（Online to Offline）的參數也在這份目錄裡。一份目錄，三個平台讀——但三個平台要的東西不完全一樣。

META 廣告系統：16 欄位對照

META 的廣告系統讀的商品目錄跟 Google 是同一份，但欄位要求有差異。系統整理了 16 個欄位的對照表，讓你一次看清楚：哪些欄位兩邊通用，哪些有差異。

16 個欄位裡，大多數是重疊的——id、title、price、link、brand、availability，兩邊都吃，格式差不多。差異恰好落在動態廣告最吃的地方——主要有兩個。

最關鍵的差異是附加圖片（additional_image_link）。META 的輪播廣告和精選集廣告直接用附加圖片組素材——沒有附加圖片，只能用同一張主圖重複出現，廣告效果大打折扣。這個案例的附加圖片覆蓋率只有 18%——305 件商品只有主圖，沒有任何附圖。對 Google 來說，缺附圖不影響商品審核；對 META 來說，缺附圖等於動態廣告做不出來。

第二個關鍵差異是 Google 商品類別（google_product_category）。META 也接受這個欄位，會自動對應到自己的分類。如果沒填，META 只能從商品標題猜你在賣什麼——猜錯了，廣告投放到錯誤的受眾。這個案例的 Google 商品類別覆蓋率只有 9%——342 件商品沒有告訴平台自己屬於哪個品類。

還有兩個 META 專屬欄位：fb_product_category 和 quantity_to_sell_on_facebook。前者不填的話 META 會從 google_product_category 推導，後者不填不影響投放。

結論是：同一份目錄丟給兩個平台，不是「填好 Google 就等於填好 META」。動態廣告最吃的附加圖片和商品類別，恰好是台灣電商平台最常忽略的欄位。

O2O 參數：實體店面的結構性優勢

如果你有實體店面，商品目錄裡還有一組 O2O 參數可以填。這些參數讓你的商品出現在「附近有貨」的搜尋結果裡——消費者搜尋某件商品，Google 顯示「你附近哪家店有現貨」。

「附近有貨」是實體店面重要的結構性優勢之一。純電商拿不到這個版位——因為純電商沒有實體庫存。這個版位是免費的，不需要投廣告。但前提是：你的商品目錄裡要有在地庫存資料。

O2O 的核心參數有幾個：

在地庫存——告訴 Google 你的哪家店有哪些商品有現貨。配置路徑是 Merchant Center 的「成長 → 管理方案」加入「免費在地商品資訊」，先建立門市檔案，再上傳對應商品的在地庫存。不需要改網站，不需要工程資源。

store_code——標識唯一實體門店的代碼。每家分店一個代碼，跟在地庫存對應。

到店取貨（pickup_method / pickup_sla）——告訴消費者這家店支不支援到店取貨、取貨需要多久。

instore_product_location——商品在店裡的哪個位置。這個欄位看起來不起眼，但有一個容易踩的陷阱。

instore_product_location 的 20 位元組陷阱

這個欄位告訴顧客商品在門市裡的具體區域，例如「B1 家電 4 排」。欄位的長度上限是 20 位元組（bytes），不是 20 個字。

這個差異在中文環境裡很要命。UTF-8 編碼下，1 個中文字佔 3 bytes，半形英數和空格各佔 1 byte。20 bytes 的上限，純中文只能塞 6 個字。「B1 家電 4 排」是 14 bytes，可以。但「B1 家電區 第 4 排」是 22 bytes，超了。

Google 官方沒有明確說明超限時是直接退回、截斷還是忽略——你需要自己在提交前算好長度。這個欄位只存在於 Merchant API 的在地庫存資源裡，Merchant Center 的店面商品目錄資料規格頁面沒有列出它。這個欄位只能透過 Merchant API 上傳（舊版 API 已公告退場時程）。

實際操作時，你需要先整理一份「商品 × 分店 → 店內位置」的對照表，訂立全店統一的簡寫規則，再交給工程側完成上傳。不同分店的位置描述格式不一致，是這個欄位最常見的失敗原因。

從搜尋到購物，七張地圖的最後一塊

這篇是 Merchant Center 商品健檢的下篇，也是帳號連結線五項 Google 服務裡目前走到的最後一項。

回頭看整個系列，每一篇交付的都是一張地圖——而每一張地圖解決的是上一張留下來的問題。

注意力熱圖讓你看到素材裡消費者的眼睛先看哪裡。受眾四維度讓你知道這些人在哪個購買階段卡住。行銷行事曆讓你選對時間點出手。導流頁讓落地頁接得住進來的流量。AI 焦點團體讓你上線前窮舉盲點。UTM 讓追蹤從第一條連結就對。Search Console 讓你看到搜尋端的盲區。Merchant Center 讓你看到購物端的盲區——你的商品「已核准」，但能被看到嗎？

七張地圖疊在一起，才看得到全貌。但地圖不會告訴你該往哪走——那是行銷人的工作。

帳號連結線把五項 Google 服務串起來：Search Console 看搜尋端、Google Ads 看廣告端、GA4 看網站端、Google 商家檔案看在地端、Merchant Center 看購物端。目前系列走到 Search Console 和 Merchant Center——Google Ads 成效和 GA4 成效的獨立文章還在後面。

這篇跟第七、八篇的關係是遞進的：GEO 是「AI 搜尋引擎看不看得到你」，UCP 是「AI 能不能直接幫消費者完成購買」。從被看到，到被選擇，到被結帳。每一層都有不同的準備工作，每一層都有現在就能做的第一步。