常見問題

帳戶設定


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 會確認店內供應情形。