常見問題

帳戶設定

Ads/FL/LIA/MHLSF/Analytics

  • 如何透過本地動態饋給合作夥伴 (LFP) 導入商家代管的本地店面 (MHLSF)？
    • 商家代管的本地店面只能代表單一商家的本地店面資訊。消費者點選您的店面商品目錄廣告和免費區域產品資訊時，系統會將他們導向您的網站。不過，他們會將客戶帶往您的網站，而非 Google 代管的本地店面，因此您可以自行管理及追蹤他們的整體購物體驗。

地圖項目類型

使用者體驗

已顯示購物註解

「查看店內商品」中的購物行為

完整

使用者點擊店面商品目錄廣告或免費區域產品資訊之後，系統會將他們重新導向至產品到達網頁，藉此顯示商品在特定商店的供應情形。

系統會向使用者顯示距離註解 (例如「3.5 英里」)，藉此顯示前往可購買商品的商店距離。

消費者點選「查看店內商品」中的店面產品後，系統會將消費者帶往 Google 代管的本地店面。

基本

消費者點選店面商品目錄廣告或免費區域產品資訊時，系統會將他們重新導向至產品到達網頁，方便消費者查看商品在附近商店的供應情形。

使用者會看到「店內有售」註解，表示其可在附近的商店購買。

消費者點選「查看店內商品」中的店面產品後，系統會將他們帶往 Google 代管的本地店面。
  • 如果商家有意自行管理帳戶，是否必須授予 LFP 帳戶存取權？
    • 不用，如果您不會代您管理他們的 AdWords 帳戶，商家也不需要授予您 AdWords 的存取權。如要連結 AdWords 和 Merchant Center，請按照這篇文章操作
  • 如果商家有意自行管理帳戶，是否需要授予 LFP 存取商家檔案帳戶？
    • 如果您打算使用 pos.inventory，則需要傳遞正確的商店 ID。這個商店 ID 是在該特定商店的「商家檔案」部分指定。如要識別這些商店 ID，您可能需要存取該「商家檔案」帳戶的部分權限，除非商家直接將該資訊提供給 LFP 供應商。連結商家檔案相關規範文章
  • 如何使用 Google Analytics (分析) 評估 Google 代管本地店面的成效？

資料設定和結構

  • 我可以使用動態饋給檔案與 API 嗎？
    • 使用 Content API for Shopping 的主要優點在於，它能透過自動化功能，有效率地管理大量庫存、複雜的帳戶設定和運送設定。以下列舉幾項優點：
      • 用於管理已上傳至 Google 以供 Google 資源 (例如購物廣告和 Google 搜尋) 使用的結構化資料。
      • 由於 API 只會傳送漸進式更新，而會每天完全重新整理資料，因此資源耗用較少。
      • API 具有更即時的即時性，可更快更新資料，進而減少庫存狀態不正確。
      • API 可以處理許多設定子帳戶的程序，而動態饋給必須手動設定。

  • 如何將資料提交給 Google？

    • 建立 Merchant Center 帳戶 (最好在 MCA 下建立子帳戶)，並將 Merchant Center ID 提供給 Google。隨後 Google 團隊就會為該帳戶啟用 POS 功能。這樣會啟用 POS 商品目錄動態饋給

    • 如要提交資料，您必須使用兩種動態饋給 (或 API) 的其中一種。商品目錄或銷售動態饋給。API 對應項目：商品目錄和銷售動態饋給

    • 銷售動態饋給會在我們這端加入一些模型，藉此提升準確性，但可能會導致系統將更多庫存設為缺貨中。

  • 我可以將哪些產品上傳至 Google？

    • 允許可立即購買的實際商品。 但必須符合相關規範才能發布內容。詳情請參閱本文。

  • 如果全球交易品項識別碼不相符，就必須提供哪些屬性？

    • 如果想使用沒有任何全球交易品項識別碼資料的產品，則必須提交主要動態饋給，或直接在零售商帳戶中使用這個 Content API。

    請注意，服飾必須具備下列屬性：

    • ID
    • title
    • description
    • image_link
    • 條件
    • 全球交易品項識別碼
    • brand

  • 我是否需要為每間商店傳送實際數量的每件商品？

    • 是，必須加入數量屬性 (特定商品提供的單位數)，才能向使用者顯示準確資訊

  • 如何透過產品 API 提交 link_template 屬性？

    • 您可以在 CustomAttributes 清單欄位內，將 link_template 新增為 CustomAttribute 物件，做為產品端點的一部分。

  • 我應傳送哪些資料？應該多久傳送一次產品資料、庫存和定價資料？

    • 產品資料應至少每 30 天傳送一次。
    • 商品目錄和價格資料每 14 天都會過期，建議每天根據優惠變更差異更新。如要最佳化重新整理更新作業，請針對會讓商品從 in_stock 變更至 out_of_stock 的交易，同時調整價格與數量的變化。
    • 如果您使用銷售動態饋給，建議至少每天更新一次這類動態饋給。 首次上傳時，至少須提供 60 天的銷售資料。
    • 商店動態饋給會將商店代碼對應至商店地址。這是選用動態饋給，只有在無法將商家連結至 Merchant Center 中的 Google 商家檔案時，才能使用此動態饋給。在計畫中新增零售商或商店時，您也必須更新和上傳這類動態饋給。

  • 此動態饋給的全球交易品項識別碼比對功能是否也會在放送時，為這些語言提供自動翻譯？

    • 沒錯，由於現在指定國家/地區 (例如加拿大) 有兩種相關語言時，您必須設定個別的 API 呼叫。

  • targetCountry 和 contentLanguage 是否需要比對？這是否屬於「查看店內商品」模組？

    • 沒錯，例如將瀏覽器語言設為加拿大法語時，使用者介面以及優惠標題和說明會以法文顯示 (與使用者介面不同，系統不會自動翻譯標題和說明；也就是說，如果對應的語言是相關國家/地區的官方語言，且商家是以該語言提交產品，則系統看似以該語言顯示產品)。
    • 無論瀏覽器語言為何，「查看商店中的內容」(SWIS) 都應可隨時存取。如果這是商家為 Google 提交產品資料的其中一種語言，但該語言無法使用 ig defaultx，請選擇英文。不過，「Google 代管的本地店面」使用者介面元素會隨著瀏覽器語言而變更。因此，如果在加拿大查看 SWIS，並將德文設為英文瀏覽器的語言，但使用者介面仍以德文顯示。

  • 我上傳了第 1 個動態饋給，所有內容都顯示為已拒登，該怎麼辦？

    • 第一次呼叫 pos.inventory 時，全球交易品項識別碼必須與 Google 的產品目錄相符。這可能會導致產品延遲 24 到 48 小時後，直到商品在 Merchant Center 上看到「待處理」狀態為止。如果您是值得信賴的合作夥伴，優惠之後會自動獲準。

  • 我的廣告何時會獲得核准？

    • 優惠會保持待處理狀態，直到該商家通過商品目錄檢查。如果你是受信任的合作夥伴，則直到管道處理完優惠為止 (通常在 24/48 小時內)

  • 我可以使用哪一個 API 擷取產品狀態？

  • 我可以使用哪個 API 連結商家檔案？

  • pos.inventory API 的頻率限制為何？單一要求中可以加入多少個 SKU？在哪個時間範圍內可以加入？

    • Content API 限制
    • 對於 CustomBatch，一種可讓您在單一要求中傳送多個項目的方法，系統會根據該批次的項目來耗用配額。如果批次有 100 個項目的 pos.sale 和 300 pos.inventory，該 API 就會使用 pos.sale 配額的 100 以及 pos.inventory 配額。

  • pos.inventory API 回應時間通常為何？

    • 與 HTTP POST 和 POST 回應之間可以即時同步。

  • 權杖的到期時間為何？建議的重新產生權杖的頻率為何？

    • 您需要使用取得的更新權杖來重新整理 OAuth 存取權杖 1 小時。詳情請參閱這裡

  • 「item_id」欄位的用途為何？它與「gtin」值有何不同？「item_id」是否對應於子項 SKU 或上層 SKU？

    • Item_id 是商家的內部 ID。可對應到任何內部產品代碼或 ID。項目 ID 僅供商家使用，方便商家識別與全球交易品項識別碼相關的商品。有些零售商會使用全球交易品項識別碼做為項目 ID，有些則不會。這個欄位應為零售商知道要檢查哪些項目，或有客戶詢問時要求提供的內容。
    • 全球交易品項識別碼是通用產品代碼或 EAN 代碼，以及製造商指派的全球交易品項識別碼。提供全球交易品項識別碼時，請務必確認資訊正確無誤。如有疑慮，請勿提供全球交易品項識別碼。

  • google_product_category 是必填欄位嗎？

    • Google 產品類別為選用項目，通常輸入用於覆寫系統自動指定的值

廣告空間檢查

  • 商品目錄檢查的執行方式
    • 動態饋給上傳且帳戶也準備就緒後，LFP 合作夥伴就會向 BD 合作夥伴提出檢查要求。Google 代表會要求支援團隊發起檢查，並在供應商指定已準備好進行檢查時，與 MC 中的商品目錄驗證聯絡人聯絡。
    • Google 支援團隊會安排時間與商店經理 (或商品目錄專家) 進行這些檢查。
    • 每個商家最多 3 間商店會進行檢查，檢查次數則視到達網頁體驗而定。瞭解詳情。
    • 在這類要求中，每間商店最多會檢查 100 項產品。我們的團隊希望在動態饋給回報有現貨時，確認商品是否有現貨，並在動態饋給標記為缺貨時確認缺貨中。
    • 商店代表也需要拍攝部分產品，清楚呈現產品標籤和書架價格或價格標籤。
    • 每間商店大約需要 2 小時才能完成整個商品目錄驗證程序。問卷調查表單必須在同個工作天內填妥。完成商品目錄驗證後，請提交問卷調查，以便轉移結果。
  • 如何取得「推薦合作夥伴資格」
  • 我的廣告何時獲得核准？
    • 在商家通過商品目錄檢查前，優惠會一直維持在待處理狀態。
  • 我的零售商有高流量商品，這會影響商品目錄檢查嗎？
    • 大家都知道如果店內有許多高流量商品，而且店內備有高量商品，而且要針對熱食等物品保持準確的溫度並不容易。 Google 會嘗試判斷動態饋給是否顯示商品是否有現貨，而非確切的存貨數量。
    • 對於難以提供數量的食品商品，我們通常會建議將數量設為「1」。如果是易腐壞的產品，且會每天更新，理想情況下，只要產品有所變更，就能立即更新。
  • 商家代管的本地店面 (MHLSF) 商店是否需要接受商品目錄檢查？
    • MHLSF 儲存庫不需要檢查商品目錄。而是會進行網站檢查，確認網站符合完整或基本的 MHLSF 的要求。開始上傳 MHLSF 後，需要 3 至 4 天才能完成進一步的人工審查。不需要進一步檢查，因為 MHLSF 會確認店內供應情形。
上一頁
Google Ads 廣告活動
下一頁
Merchant API 遷移