遇到其他問題或挑戰，或找不到這裡列出的問題？回報錯誤或要求功能，並加入 cloud-recommendations-users Google 群組或 Stack Overflow 討論。
一般
這些是常見問題的一般解答。
1. 是否有 Vertex AI Search for Commerce 的用戶端程式庫或更多範例程式碼？
可以。如需各程式庫的設定和參考資訊，請參閱用戶端程式庫指南。
您也可以使用 Google API Discovery Service，取代原始 REST 呼叫。
2. 所有推薦模型都是個人化模型嗎？
「為你推薦」、「你可能會喜歡的其他項目」和「再次購買」模型會根據使用者記錄提供個人化推薦內容。「經常同時購買的商品」和「類似商品」模型不會提供個人化建議。
請參閱「關於建議模型」。
3. 我會立即收到個人化建議，還是需要等待一段時間，系統才會提供更準確的建議？
收集的使用者記錄越多，推薦內容就越準確。「為你推薦」模型會顯示熱門產品，「你可能也喜歡」模型則會根據其他人的瀏覽記錄，顯示類似產品。這兩種模型都會立即將使用者行為納入考量，因此請務必傳送即時事件。請參閱「關於建議模型」。
使用者事件必須即時或近乎即時傳送，才能有效進行個人化。如果使用者事件只會在每天提交，或是在一天內分批提交，個人化模型的成效可能不如傳送即時事件時。
4. 您是否在模型中使用 Google 使用者的人口統計資料？
模型只會使用您提供的目錄和使用者事件資料。如要加入受眾特徵資料，可以加入其他文字或數字資訊，做為自訂屬性。模型重新調整後，就會開始使用這項資料。
請勿加入電子郵件地址或使用者名稱等個人識別資訊 (PII)。建議您將人口統計資料去識別化，例如將值雜湊處理或使用群組 ID。
5. 我可以根據一群使用者的事件記錄，而非單一使用者的記錄，提供建議嗎？
建議依據為單一訪客 ID 或使用者 ID。您必須個別提出要求，然後合併結果，才能根據群組的記錄提供建議。如果使用者有共同的中繼資料屬性，您可以將群組 ID 做為使用者 ID，提供群組層級的建議。
6. 我發現你可以提交產品的圖片網址。模型是否會考量產品圖片？
可以，產品圖片可做為產品目錄資料的一部分提交。商家適用的 Vertex AI Search 會使用產品網址和後方的 ID (URI) 充實產品說明。
Product 物件包含 images 欄位，這是圖片物件的清單。每個圖片物件都可以包含 URI、高度和寬度。每項產品最多可有 300 張圖片。
雖然這是選用屬性，但我們強烈建議提供產品圖片。(預測預覽) 也會使用圖片網址，在 Search for commerce 控制台中預覽模型預測結果時顯示圖片。
7. 我的公司不是零售電子商務網站，我還能使用建議來預測 x、y、z 嗎？
我們有客戶將建議用於內容建議、影片串流和遊戲等用途。不過，我們的內容和體驗是專為零售電子商務用途設計，可能還不適合其他用途。
8. 我可以在網站的任何頁面上放置推薦內容嗎？
可以，但這些模型是為特定用途設計，可能最適合用於特定網頁。請參閱「關於建議模型」。
「經常一起購買」和「你可能也會喜歡」需要商品 ID，因此應使用這些 ID 產生推薦內容，例如產品 ID 或購物車中的商品。「經常一起購買」通常最適合用於「加入購物車」或結帳頁面，而「你可能也會喜歡」和「類似商品」則最適合用於產品詳細資料頁面。「為你推薦」可放置在任何頁面，因為只需要訪客 ID 做為輸入內容，但設計上是做為首頁服務設定。「再次購買」功能可放置在任何頁面。
9. 我可以在電子郵件新聞通訊中使用建議功能嗎？
可以。只要使用訪客 ID 或使用者 ID 呼叫 API，然後將結果併入電子郵件範本即可。如要在讀取電子郵件時動態載入項目，您需要使用中介端點 (例如 Google Cloud Function) 傳送預測要求。API 只會提供排序後的產品 ID 清單和中繼資料，因此您也需要自行編寫程式碼，才能算繪圖片結果。
10. 我是否能將 Vertex AI Search for Commerce 用於其他非網頁用途 (行動應用程式、資訊亭)？
可以。您可以設定端點 (例如 Google Cloud Function) 來取得應用程式的結果。您也需要類似的機制來傳送即時事件。
11. 我沒有超過 3 個月的事件資料。我還能使用 Vertex AI Search for Commerce 嗎？之後可以新增更多資料嗎？
類似商品模型不會使用使用者事件資料或模型調整功能。如果沒有任何事件資料，只要有目錄資料，您還是可以建立及訓練類似商品模型。
如果可以記錄足夠的即時事件流量，就能使用近期資料訓練其他模型。如果之後有其他資料，可以在初始模型訓練完成後上傳。在每日重新訓練期間，模型會納入新回填的資料。不過，如果資料與用於初始訓練的事件有顯著差異，可能需要重新調整模型。
大多數模型需要至少三個月的產品頁面瀏覽次數、首頁瀏覽次數和所有模型的加入購物車事件，才能發揮最佳成效。理想情況下，你還需要一到兩年的購買記錄，才能讓「經常一起購買」模型發揮最佳成效。
詳細資料頁面瀏覽量一到兩週就足以開始訓練「你可能也喜歡」和「為你推薦」模型，而「經常一起購買」和「再次購買」通常需要更多資料，因為每天的購買次數通常比網頁瀏覽次數少。更多資料可大幅提升模型品質，但最低資料量可能無法產生最佳結果。舉例來說，如果模型有整年的購買資料，就能更充分地運用季節性變化和趨勢。
12. 我可以同時推薦類別和產品嗎？
Recommendations 只會傳回產品建議，但您可以取得每個產品的類別，做為結果的一部分。
13. 是否提供整合功能，可從 SQL 資料庫或其他系統 (例如 BigQuery) 上傳資料？
可以。如果是事件，則有可從 BigQuery 讀取的程式碼範例。請參閱 BigQuery 的 Google Analytics 範例資料集。
14. Vertex AI Search 電子商務套件是否會使用 Cookie？
不會，不會使用 Cookie。不過，傳送至 Vertex AI Search for commerce 的所有事件都必須指定訪客 ID，這通常是來自 Cookie 的工作階段 ID。
15. 我是否需要專屬 Google Cloud 專案？
您可以建立新的專屬專案，或在現有專案中啟用商家適用的 Vertex AI Search。
16. 使用 Cloud Shell 時，為什麼我的憑證無法運作？
請確認你已完成商家適用的 Vertex AI Search 的驗證設定步驟。您應使用在環境中可用的服務帳戶。否則，您可能會收到類似以下的錯誤訊息： 您的應用程式已使用 Google Cloud SDK 或 Shell 的使用者憑證進行驗證，但這類憑證不受支援。 Google Cloud
如要進一步瞭解服務帳戶，請參閱 Google Cloud說明文件的驗證一節。
17. 如何比較 Vertex AI Search for Commerce 與類似解決方案？
您可以進行 A/B 測試，比較 Vertex AI Search for Commerce 與其他產品的結果。
18. 我覺得 x、y、z 功能很棒，可以新增這個嗎？
歡迎與我們分享你的意見。您可以透過帳戶團隊、Google 支援或問題追蹤工具提交功能要求。
19. 我還能使用舊版建議 API 嗎？
推薦功能已從 Recommendations Engine API 遷移至商家適用的 Vertex AI Search。如果您在 Beta 版期間使用 Recommendations Engine API，建議將建議內容遷移至 Vertex AI Search for Commerce (服務端點 https://retail.googleapis.com)，該服務已正式發布。
舊版 API (服務端點
https://recommendationengine.googleapis.com) 和說明文件仍可使用，但不會再更新。
產品目錄和產品
以下是目錄和產品的常見問題。
1. 推薦內容如何處理新產品的冷啟動？
如果產品沒有任何購買記錄，我們會根據類似產品提供建議。在這些情況下，目錄中定義的產品名稱、類別和說明就顯得格外重要。
對於冷啟動使用者 (沒有記錄的訪客)，模型會先從最熱門的一般產品開始，並在收到更多使用者事件時，即時提供更個人化的推薦內容。
2. 我可以將 Merchant Center 目錄用於最佳化建議嗎？
可以，你可以使用 Merchant Center 資料移轉服務，將 Merchant Center 目錄匯出至 BigQuery。然後直接從 BigQuery 讀取目錄。請參閱「從 Merchant Center 匯入目錄資料」。
3. 還有哪些方法可以匯入目錄？
- Merchant Center：透過 Merchant Center 匯入。如果你使用搜尋功能，可以透過控制台連結 Merchant Center，讓目錄自動同步。
- BigQuery：直接從資料表或檢視畫面匯入。
- Cloud Storage：匯入文字檔，每行包含一個 JSON 目錄項目。
- 內嵌匯入：使用 API 呼叫匯入，並使用文字檔，每行一個 JSON 目錄項目。
- 建立產品項目：使用
Products建立方法。
4. 如何更新目錄？目錄多久需要更新一次？
請參閱「維持內容新鮮感」。
建議你每天更新目錄。您可以從 Cloud Storage 或 BigQuery 進行完整更新，也可以進行增量更新 (即僅更新新項目和變更的項目)。
盡可能即時更新價格和供應情形。這會影響新項目可供搜尋的速度。
如果您有接收目錄變更通知的方式 (例如使用 Pub/Sub、訊息佇列、事件等)，則可以使用 import 或 create API 方法即時更新目錄。
舉例來說，您可以使用 Cloud Scheduler 每天呼叫 BigQuery 匯入作業。
5. 目錄大小是否有下限和上限？
沒有最低限制，但如果目錄很小 (少於 100 個項目)，由於可推薦的產品種類很少，建議可能不會帶來太多好處。
目錄最多可包含 4,000 萬個項目。
如要瞭解預設配額和限制，以及如何申請變更配額，請參閱相關說明文件。
6. 我的公司在多個國家/地區經營網站，我應該為所有資料使用一個目錄嗎？
通常最好只使用一個包含所有項目的目錄。所有活動都必須以單一幣別提交。您無法在同一個專案中建立多個目錄，但如果使用實體，可以為特定國家/地區指定搜尋、建議和自動完成行為。
如果網站之間的目錄差異很大，建議為每個網站分別建立專案。此外，如果國家/地區使用不同語言，建議您為每種語言分別建立專案。
如果類似網站的流量比主要網站低，且事件數量不足以產生所有個別網站的高品質模型，建議使用單一目錄。
如要使用單一目錄，目錄商品 ID 必須一致，也就是說，所有網站上的相同產品都應使用單一商品 ID，這樣目錄中就不會有重複的產品。
如果只使用建議功能，除了實體之外，您也可以使用篩選器，篩選出特定網站。不過，篩選器最多可能需要 8 小時才會更新，因此如果存在特定國家/地區的供應情形 (缺貨) 規定，通常需要透過業務規則，在預測回應後篩除結果。這適用於第 1 版的filter_tag篩選功能，以及第 2 版的屬性篩選功能。
7. Vertex AI Search 電子商務套件是否支援每個目錄使用多種幣別？
不行，每個目錄只能使用一種貨幣類型。上傳活動時，必須使用單一幣別。
如果您打算使用「搜尋商業」控制台取得收益指標，請確保所有事件都使用單一幣別，或在上傳前將所有事件轉換為相同幣別。
8. 我有多個網站，目錄相同或項目相似。最佳化建議可以提供跨網站建議嗎？
如果網站之間有顯著的重疊，且應共用許多或所有相同的產品，我們通常建議只使用這類單一目錄。然後，與多區域網站一樣，您可以使用實體或篩選標記，只傳回特定預測呼叫的網站專屬項目。
如果網站共用的目錄項目不多或沒有，則應使用多個目錄。如要使用多個目錄，每個目錄都必須有各自的 Google Cloud 專案。
9. 納入更多中繼資料是否能提升模型成效？模型是否會考量 x、y、z 欄位？
如需必填欄位，請參閱「必要目錄項目資訊」。
其他中繼資料欄位為選用欄位 (例如圖片和 itemAttributes)。可用於預測預覽、結果分析、訓練和微調。建議加入顏色、尺寸、材質等實用屬性。指定 returnProduct:true 後，這些欄位會以 predict 結果的形式傳回，因此可用於算繪結果。圖片和商品屬性會用於商業搜尋控制台的預測預覽。
10. 目錄項目的哪些屬性會做為模型訓練的輸入內容？
系統會同時考量使用者行為和產品屬性。主要使用的欄位為 ID、標題、類別階層、價格和網址。您可以加入其他自訂鍵/值屬性，這些屬性在 Product.attributes[] 中可能很有用。
圖片網址是便利功能，您可以指定 returnProduct:true，將這項中繼資料做為預測結果的一部分傳回，這樣就能省下額外呼叫來擷取這項資訊。有了圖片網址，您在「Search for commerce」控制台中預覽模型預測結果時，預測預覽功能也會顯示圖片。
11. 我的產品支援哪些語言？
建議功能：支援大部分語言。模型會自動偵測文字語言。如需可自動偵測的所有語言清單，請參閱 Compact Language Detector GitHub README。
搜尋功能：支援這些世界語言。
上傳目錄時，系統會要求你設定語言。目錄只能使用一種語言，且查詢也必須以相同語言傳送。目錄中有多種語言會降低模型效能。舉例來說，如果目錄是西班牙文，但搜尋查詢是英文，系統不會將查詢翻譯成西班牙文。
12. 我的目錄有主要/變體或父項/子項 SKU。是否支援這些功能？
可以。這與 Merchant Center 中的 item_group_id 類似。您需要決定要如何取得建議 (上層或子層級)，以及事件是否位於上層或子層級。
如要進一步瞭解產品層級，請參閱產品層級。
傳送任何項目或事件前，請先判斷並設定正確的產品層級。 產品層級可以變更，但需要重新加入項目並重新調整模型。
13. 如果產品已停售，可以從目錄中刪除嗎？
如果項目已過時，建議您將狀態設為 OUT_OF_STOCK，而非刪除項目，以免參照該項目的先前使用者事件失效。
使用者事件
以下是使用者事件的常見問題。
1. 我需要收集哪些使用者事件？
如需使用者事件類型清單，以及使用者事件規定和最佳做法，請參閱「關於使用者事件」。
2. 如何排解模型建立時的資料品質問題？
在 Search for Commerce 控制台中，前往「資料品質」頁面，查看有關已匯入目錄和使用者事件的資料品質指標。
3. 我可以與 Google Analytics 360 整合嗎？
您可以運用 Google Analytics 360 (GA360) 的歷來資料。與 Merchant Center 資料類似，GA360 資料可以匯出至 BigQuery，然後 Vertex AI Search for commerce 就能直接從 BigQuery 讀取事件。
如果是即時事件，建議您透過 Google 代碼管理工具整合追蹤像素，因為事件會從 GA360 延遲。
4. 我想從 Google Analytics 360 匯入使用者事件。是否提供所有必要的使用者事件？
Google Analytics 360 原生支援 Vertex AI Search for commerce 使用的所有使用者事件，搜尋事件除外。您仍可從 Analytics 360 匯入搜尋使用者事件，但請注意，Vertex AI Search for commerce 會根據搜尋查詢和產品曝光 (如有) 建構搜尋使用者事件。
5. 如何將事件饋送至 Recommendations AI？
使用者通常會使用 Cloud Storage 或 API 匯入功能匯入歷來事件，然後在網站上使用 JavaScript 像素或代碼管理工具代碼，或在後端使用寫入方法，串流即時事件。
6. 如果我無法傳送模型所需的所有使用者事件類型，該怎麼辦？每個模型需要哪些最低限度的事件類型？
每個模型和最佳化目標的規定略有不同。請參閱使用者事件資料規定。
通常目錄項目事件越多，模型成效越好。如果網站流量龐大但目錄較小，您或許可以從較少量的歷來事件著手，但通常仍需要至少幾週的歷來資料，以及未來的即時事件。
7. 我的「加入購物車」和「完成購買」事件沒有收益或數量值。我需要提交哪些資料？
如果沒有數量值，可以傳遞預設值 1，不會影響模型結果。商品一律應設定 displayPrice (可為向使用者顯示的任何價格，例如折扣價)。originalPrice 和 cost 為選用屬性。
8. 我的資料只涵蓋少數幾種活動。我還能使用 Vertex AI Search for Commerce 嗎？
如要瞭解各模型類型的最低資料門檻，請參閱使用者事件資料規定。
搜尋結果
以下是搜尋結果的常見問題。
1. 搜尋結果是否會個人化？
可以。Google 搜尋可提供個人化搜尋結果。 系統會根據訪客 ID 提供個人化搜尋結果。 詳情請參閱「個人化」。
2. 如何將背景資訊 (例如使用者購物的商店) 納入搜尋要求？
以商店 ID 為準的供應情形和運送選項是產品目錄的屬性。出貨選項是「線上配送」、「線上購買」和「到店取貨」等屬性。
屬性可以做為搜尋要求中的參數傳送。因此，以這個範例來說，搜尋要求可以指定使用者的商店 ID。系統可根據要求中的商店 ID 篩選或提高結果排名。
3. 我可以隱藏搜尋結果中的產品嗎？
可以。filter 參數可根據標記篩除結果。
4. 可以根據多項條件 (例如供應情形和價格) 進行排序嗎？
可以，boostSpec 允許複雜的排名規則。
5. 是否可以將部分屬性分組，以便提供多個層面的結果？例如，將生產地為同一國家/地區的城市歸為一組。
產品屬性並非階層式。不過，您可以使用多個自訂屬性來達成此目的。在本例中，你可以使用自訂屬性，同時指定生產國家/地區和生產城市。
6. 建議的運作方式
建議內容包含使用者查詢、重新編寫的查詢、產品名稱等。如要產生高品質的自動完成建議，系統應擷取足夠數量的搜尋事件和目錄。
預測結果
以下是預測結果的常見問題。
1. 傳回的預測結果數量是否有限制？
根據預設，預測要求會在回應中傳回 20 個項目。如要增加或減少這個值，請提交 pageSize 的值。
如要退回超過 100 件商品，請與 Google 支援團隊聯絡，提高退貨上限。但請注意，傳回超過 100 個項目可能會增加回應延遲時間。
2. 我可以查看模型推薦特定產品的原因嗎？
不用
3. 我可以下載及快取預測結果嗎？
預測結果會根據使用者在您網站上的活動即時改善，因此不建議使用快取預測結果。模型每天都會重新訓練，以納入目錄變更，並因應使用者事件的新趨勢，因此結果也會隨之變更。
4. 我需要根據業務規則，重新排序傳回的建議。是否支援這項功能？
可以。不過，雖然您可以根據業務規則重新排序傳回的建議，但請注意，重新排序或篩選建議結果可能會降低模型達成所選最佳化目標的整體成效。
價格重新排序功能會將相關的高價商品優先排序在傳回的建議項目中，並可做為「你可能會喜歡的其他項目」和「為你推薦」模型的內建自訂功能。
請參閱價格重新排序。
5. 可建立及使用的篩選器標記數量是否有限制？
可建立或使用的不重複代碼數量沒有硬性限制。不過，系統並非設計用來處理每個項目多個篩選標記。建議盡可能將每個目錄項目的篩選標記數量限制在 10 個以內。整個目錄最多可使用 10 個以上的值，但每個項目都有上限。標記總數 (所有項目標記數量的總和) 上限為 100,000,000 個。
請參閱商家適用的 Vertex AI Search 配額與限制說明文件。
6. 我可以讓系統推薦更多元化的影片嗎？
可以。推薦結果多樣性可指定為服務設定的一部分，或在預測要求參數中指定。如果多樣性較低，預測結果可能會包含同一類別的類似項目。如果多元性較高，結果會包含其他類別的項目。
7. 我可以依價格優先顯示建議嗎？
可以。如果啟用價格重新排序，系統就會將推薦機率相近的推薦產品按照價格由高至低排序。系統仍會使用關聯性排序項目，因此啟用價格重新排序與依價格排序不同。價格重新排序可指定為放送設定的一部分，或在預測要求參數中指定。
對話功能
以下是商家適用的 Vertex AI Search 對話功能、產品篩選和商務的常見問題。
1. 如何維持對話工作階段，以及如何重新整理情境？
系統會使用 Conversational Commerce 代理程式回應中傳回的對話 ID，維護對話工作階段。在同一段對話中，您必須在所有後續要求中傳遞這個對話 ID。系統會保留與這個 ID 相關的所有脈絡。如要重新整理或發起新的對話，請不要使用對話 ID 發出新的 API 要求，這樣回應中就會發出新的對話 ID。
2. 串流 API 會如何影響我的實作和使用者體驗？
由於是串流性質，您可以立即收到查詢類型。這樣一來，您就能區分出有對話式文字回應的查詢 (可能會有較長延遲時間)，以及沒有這類回應的查詢 (例如 SIMPLE_PRODUCT_SEARCH)。對於 SIMPLE_PRODUCT_SEARCH，您可以立即觸發對核心搜尋 API 的呼叫，快速顯示產品。如果是 LLM 驅動的回覆，您可以在對話文字串流傳入時，顯示載入指標或平行擷取搜尋結果，為使用者提供最佳的感知回應速度。
3. 為什麼 searchParams 中的 ConversationalSearchRequest 必須反映我的核心搜尋 API 呼叫？
您希望在 ConversationalSearchRequest 和 SearchService.Search 呼叫之間，維持 searchParams 的一致性，例如篩選器、排序順序和提升規則。維持一致性有助於確保 API 提供的對話式回覆或精確查詢，與向使用者顯示的實際產品結果一致。避免出現差異，並提供一致的購物體驗。
4. 如果系統偵測到基本產品搜尋，對話會結束嗎？使用者可以返回其他對話模式嗎？
對話不會結束。對話 ID 仍有效。不過，從使用者體驗的角度來看，零售商通常會將使用者轉移至標準搜尋結果頁面。如果使用者沒有使用原始對話 ID 提交新查詢 (例如直接在標準搜尋列中輸入內容)，系統就會啟動新的對話工作階段。不過，零售商可以設計 UX，讓聊天視窗保持開啟狀態，並允許使用者繼續對話 (尤其是conversationalFilteringSpec.mode設為ENABLED以啟用後續問題時)。能否「還原」為豐富對話模式，取決於這項特定的 UX 實作選擇。
5. 對話式 API 會儲存哪些對話內容資料，以及儲存多久？
為維持對話流程，Conversational API 會儲存與對話 ID 連結的使用者查詢、對話文字回覆和後續問題。這類脈絡資訊會保留 7 天，確保您在後續要求中傳遞對話 ID 時，系統可以擷取並使用這項記錄。
6. 為什麼對話式 API 不像對話式產品篩選功能一樣，提供後續問題的建議答案？
目前不支援提供後續問題的建議答案，但我們已將這項功能納入發展藍圖。敬請持續鎖定！
7. 對話式 API 如何使用快取提升效能及提供背景資訊？
對話式 API 會為特定客戶和專案快取查詢類型和精確搜尋查詢，最多 10 天。也就是說，如果重複相同的查詢，系統就能快速擷取意圖和建議的修正內容。
模型
以下是模型相關常見問題。
1. 我已上傳目錄和事件，但呼叫預測 API 時，仍會收到以下回應：Recommendation model is not ready.
您可以將預測要求中的「dryRun」設為 true，以利整合，這會從目錄傳回任意目錄項目 (請勿將此用於正式版流量)。**
這通常表示模型尚未完成訓練。如果建立模型後已超過 10 天，但仍收到這類回覆，請與支援團隊聯絡。
2. 訓練模型需要多少時間？
初始模型訓練和調整作業需要 2 到 5 天才能完成，但如果是大型資料集，可能需要更長時間。之後，模型會每天自動重新訓練，除非您停用這項功能。請參閱「暫停及繼續訓練模型」。
3. 我可以下載或匯出模型嗎？
不用
4. 我可以在新專案中使用現有專案中建立的模型嗎？
不會。您需要在新專案中建立及重新訓練模型。
5. 我想為類別頁面使用模型。可以這樣做嗎？
可以。「為你推薦」功能適用於類別頁面。類別頁面與首頁類似，但只會顯示該類別的項目。
您可以使用標準的「為你推薦」模型搭配篩選標記，達到這個目的。
舉例來說，你可以為目錄中的項目新增自訂篩選器標記 (對應每個類別頁面)。傳送預測要求時，請將使用者事件物件設為 category-page-view，並在 filter 欄位中指定特定類別頁面的標記。系統只會傳回符合所要求篩選標記的建議結果。在這種情況下，應停用多樣性功能，因為多樣性可能會與以類別為準的篩選標記衝突。
6. 我可以停用模型的個人化功能嗎？
根據預設，系統會為「您可能會喜歡的其他項目」、「為您推薦」和「再次購買」推薦模型類型，提供個人化的預測結果。
我們不建議停用個人化功能，因為這可能會對模型成效造成負面影響。
如果需要顯示與使用者目前瀏覽產品相關的目錄項目，而非根據使用者先前與網站的互動，可以在預測要求中使用隨機的專屬訪客 ID，接收非個人化建議。請務必只針對您不希望個人化的放送設定中的要求執行這項操作。
搜尋商務控制台
以下是使用「搜尋」商業控制台的常見問題。
1. 我已清除多個事件，但資訊主頁仍顯示這些事件類型的計數。
這是可預期的情況，「搜尋」電子商務資訊主頁會顯示特定時間範圍內擷取的事件數，不會顯示目前的事件數。
一般來說，使用者事件記錄完畢後，您應保留這些事件。我們不建議清除事件。如要完全重設使用者事件，建議改為建立新專案。
如需清除未正確記錄的事件，請參閱「移除使用者事件」一文。清除事件最多可能需要幾天才能完成。
2. 如何判斷目錄或使用者事件是否有錯誤？
如果語法有問題，或要求因故無法處理，大多數目錄項目更新或使用者事件的 API 呼叫都會傳回錯誤。
「搜尋商務」資訊主頁會顯示未加入活動的百分比，這也是用來找出目錄或活動問題的實用指標。如果指定的項目 ID 不在目錄中，就會發生未彙整的事件 (或未彙整的預測呼叫)。這通常表示目錄已過時，需要上傳新的或變更的目錄項目，但也可能是因為傳遞的項目 ID 有誤。檢查要求，確認項目 ID 正確對應至目錄，然後檢查上傳的目錄，確認項目存在。
您可以使用 Cloud Monitoring 和 Cloud Logging 監控事件狀態。舉例來說，如果一段時間內沒有任何事件，或是預測通話次數低於特定門檻，您就會收到快訊。
3. 為什麼我的建議放送設定顯示為無效？如何啟用？
如要使用推薦服務設定，請先提交目錄和使用者事件資料，訓練相應的模型。模型訓練完成後，資訊主頁會顯示模型已可供查詢。
4. Search for commerce 報表會以哪種幣別顯示收益指標？
以你上傳資料中使用的幣別，搜尋電子商務報表指標。Vertex AI Search for Commerce 不支援每個目錄使用多種幣別，也不會轉換幣別。
如果您打算使用 Search for Commerce 控制台取得收益指標，請確保所有事件都使用單一幣別，或先將所有事件轉換為相同幣別，再上傳至 Vertex AI Search for Commerce。