運用 CRM 個人化功能提升 Vertex AI Search for commerce 體驗

這份 Vertex AI Search for commerce API 導入指南，說明如何使用客戶關係管理 (CRM) 資料，在 Vertex AI Search for commerce 中提供個人化搜尋體驗。整合 CRM 中的使用者屬性後，您就能提供更相關的搜尋結果，最終提升顧客參與度和轉換率。本文將詳細說明整合這些使用者屬性的程序，包括資料考量事項和技術規格。

選取用於個人化的資料

個人化功能的成效取決於您提供的顧客關係管理資料品質、涵蓋範圍和關聯性。請考慮哪些顧客資訊會真正影響專業銷售人員提供的搜尋結果。

完成先導測試後，您就能更清楚哪些資料具有影響力，哪些則否。

建議用來評估影響的資料類別

這些資料類別最能說明商務網站的使用者行為。

地理位置資訊：顧客所在位置，例如州或國家/地區。郵遞區號資訊過於詳細。詳情請參閱「過於精細的層級」一節。
客層資料：核心顧客特徵，例如年齡和性別。
- 瞭解顧客的年齡層 (例如 18 到 24 歲，而非 55 到 64 歲)，有助於為服飾或電子產品等項目制定不同的產品展示策略。這項資料的影響力極高。
顧客輪廓：例如精打細算的購物者，而非大手筆的消費者。

影響較小的資料類別

這些資料類別對商業資料擷取作業的影響不大。

根據購買記錄推導出的屬性：
- 系統已將過去的購物行為納入考量，提供個人化服務。
- 傳送 user bought a green dress yesterday 等屬性是多餘的，因為系統會原生擷取及使用這項資訊。
- 著重於從 CRM 取得新洞察資料。
特定行銷回應資料，例如：Clicked email #7
- 雖然這項資訊有助於分析行銷活動，但不會告訴 AI 要顯示哪些搜尋結果。

資料完整性

除了相關性，使用者群的資料完整度也會大幅影響個人化功能的實用性。如果屬性適用於大部分使用者，系統就能找出更廣泛的模式，並更廣泛地套用個人化設定，因此這類屬性最有價值。

非常實用：
- 您擁有的使用者屬性，例如 shipping_state:MA (如果 70% 的使用者都有這項屬性)。
- 這項技術可進行穩健的模式辨識，並廣泛應用於個人化服務。
較不實用：
- 屬性僅適用於一小部分使用者，例如僅適用於 0.1% 的使用者。hair_color:blonde

雖然這類稀疏資料很有趣，但由於缺乏足夠的範例，系統難以從中衍生出有意義的個人化信號。請優先使用可涵蓋各種客群的屬性。

資料精細程度指南

適當的資料精細程度是有效提供個人化服務的關鍵。如果資料範圍過於廣泛或過於具體，系統識別有意義模式的能力就會降低。請選擇可將顧客群劃分為可採取行動的群組的屬性。

精細程度合宜

精細程度合宜的範例包括：

性別
狀態
城市
年齡層 (例如 30 至 39 歲)

這個精細程度可提供個人化差異，不會產生難以管理的大量類別。

精細程度不足

舉例來說，如果您的絕大多數客群都位於美國，則 country:US 粒度不足。這是因為如果屬性在整個客群中差異不大，對個人化設定的價值就極低。

過度精細

過度細分的例子包括：

確切的郵遞區號 (zipcode:12345)：由於郵遞區號多達數萬個，大多數郵遞區號的相關聯顧客人數都很少。這種原子化會稀釋訊號。如果使用郵遞區號，請將郵遞區號截斷為前兩位數，以達到更適當的精細程度。郵遞區號的前兩位數大致對應到州大小的區域。
確切年齡 (age:37)：這會產生過多的年齡類別。如要減少數量，請將年齡等數值資料分組到約 10 個預先定義的資料夾或容器 (例如 age:30-39)。

其他資料規定

本節將說明類別和其他資料格式。

類別型資料格式

這個系統已針對類別資料進行最佳化處理，也就是不同的具名值，例如：

state:MA
gender:male

數值型資料

因此，傳輸資料前，應先將年齡、收入或頻率等數值屬性分組到有意義的區間。

以下分別為錯誤和正確的範例：

age:37
age:30-39

其他資料限制

屬性限制：每項查詢最多支援 100 個鍵/值組。日後推出的版本可能會支援更多語言組合。
重複的鍵：單一查詢中不得有重複的鍵。不過，每個鍵可有多個值。
禁止傳送的個人識別資訊：請勿以任何形式傳送特定個人識別資訊 (PII)，例如顧客電子郵件地址、身分證字號、全名或財務資料 (如信用卡號碼)。

API 整合與資料傳輸

客戶資料應在搜尋要求的 query 欄位中傳輸，而非在事件中。

通訊協定緩衝區結構 (適用於開發人員)

使用者屬性是在 SearchRequest 訊息中定義，做為字串對應至 StringList 訊息的地圖。

查看 protobuf 範例

// A list of string values.
message StringList {
// String values.
repeated string values;
}

// Request message for [SearchService.Search][] method.
message SearchRequest {
...
// The user attributes that could be used for personalization of search.
maptring, StringList> user_attributes;
}

JSON 要求範例

這個範例說明如何在 JSON 搜尋要求中建構 user_attributes。

查看 JSON 範例

{
...

user_attributes: [
       { key: "pets" # note keys can be hashed or unhashed
         value {
           values: "dog" # Note: these values MUST be hashed
           values: "cat"
         }
       },
       { key: "state"
         value {
           values: "CA"
         }
       }
      ]
}

API 回應

使用這項功能時，SearchResponse API 不會變更。系統會根據您提供的使用者屬性，在內部進行個人化設定。

資料雜湊處理規定

為確保資料隱私和安全性，屬性值必須經過雜湊處理。金鑰可以經過雜湊處理或未經雜湊處理。

雜湊處理金鑰

屬性鍵 (例如 pet_owner 和 state) 可以原始字串形式或雜湊形式傳送。這兩種方式都可以接受。

例如：

可接受 - pet_owner
可接受 - hash(pet_owner)

雜湊處理值

屬性值 (例如 dog 和 CA) 必須經過雜湊處理。不得傳送純文字值。

例如：

可接受 - hash(dog)
不符合規定 - "Dog"

合併鍵/值雜湊

如果鍵和值都要經過雜湊處理，必須分別進行雜湊處理。請勿對合併的鍵/值字串進行雜湊處理。

例如：

可接受 - pet_owner:hash("dog")
可接受 - hash(pet_owner):hash("dog")
不符合規定 - hash("Pet_owner:dog")

資料傳輸最佳做法

本節將說明資料傳輸的幾項最佳做法，包括如何處理重複值、資料一致性、屬性鍵命名彈性，以及處理不同的使用者設定檔。

如何處理重複值

如果使用者單一屬性有多個值 (例如同時養狗和貓)，請在 StringList 內的單一 key 下提供所有值。

這些程式碼範例分別示範錯誤和正確的用法：

查看範例

// This is incorrect because it sends the same key multiple times for different
// values, causing only one of the two values for pets to be used, choosing one
// value or the other in an inconsistent manner.
{
  key: "pets",
  value {
    values: "dog"
  }
},
{
  key: "pets",
  value {
    values: "cat"
  }
}

查看範例

{
  key: "pets",
  value {
    values: "dog",
    values: "cat"
  }
}

資料一致性

所有鍵和值都必須嚴格遵守拼字、空格和大小寫規則。即使是微小的差異，系統也會解讀為不同的類別。

舉例來說，State:MA、state:MA、state:ma、STATE:MA 和 residence_state:MA 都會視為個別且不相關的屬性。

屬性鍵命名彈性

雖然屬性鍵 (例如 pet_owner、pets、codeabc) 的特定命名慣例不會影響系統使用資料的能力，但仍建議您保持一致。重要環節在於傳輸資料的一致性。

如何處理不同的使用者個人資料

不同使用者可以擁有不同的屬性組合。

示例：使用者 A 可能有 age:30-39 和 pet:dog，而使用者 B 只有 gender:male，沒有寵物或年齡資料。系統會妥善處理部分設定檔。

動態資料更新

使用者屬性可能會隨著時間改變。您可以在取得新資訊時更新使用者設定檔。

示例：使用者一開始的識別資訊為 age:30-39 和 pet:dog，但如果系統取得位置資訊，之後可能會新增 state:MA。

跨平台一致性

盡量確保特定使用者在所有接觸點 (例如行動應用程式或網站) 的屬性傳輸作業一致。確保提供一致的個人化體驗。

最佳：使用者 A 在行動應用程式和網站上都age:30-39。
不理想：使用者 A 在行動應用程式中為 age:30-39，但在網站上僅為 pet:dog。

如何處理遺漏的資料

如果無法提供特定使用者資訊，請勿傳送預留位置或空白值。只要從要求中省略該鍵/值組合即可。

範例：避免使用 pet:unknown 或 pet:

SDK 和程式庫存取權

您可以在下列版本和後續版本中存取這些程式庫：