CRM のパーソナライズで AI Commerce Search を強化する

AI Commerce Search のこの API 実装ガイドでは、顧客管理（CRM）データを使用して AI Commerce Search 内の検索エクスペリエンスをパーソナライズする方法について説明します。CRM のユーザー属性を統合することで、より関連性の高い検索結果を提供し、最終的に顧客エンゲージメントとコンバージョンを向上させることができます。このドキュメントでは、データに関する考慮事項や技術仕様など、これらのユーザー属性を統合するプロセスについて詳しく説明します。

パーソナライズに使用するデータを選択する

パーソナライズの有効性は、提供する CRM データの品質、カバレッジ、関連性によって決まります。知識豊富な販売員が提供する検索結果に実際に影響する可能性のあるお客様の情報について検討します。

と自問自答してください。

パイロット テストが完了すると、どのデータが影響力があるか（ないか）について、より強力な推奨事項が得られます。

これらのデータカテゴリは、コマース サイトのユーザー行動を最もよく表す情報です。

  • 地理情報: ユーザーの所在地（都道府県や国など）。郵便番号情報が細かすぎます。詳細については、粒度の過剰のセクションをご覧ください。
  • ユーザー属性データ: 年齢や性別など、顧客の主な特徴。
    • 顧客の年齢層（18 ～ 24 歳と 55 ～ 64 歳など）を把握することで、アパレルや電子機器などの商品の表示戦略を使い分けることができます。これは非常に影響力の大きいデータです。
  • 顧客ペルソナ: たとえば、大金を費やす買い物客ではなく、予算を意識した倹約家の買い物客。

影響が少ない可能性のあるデータカテゴリ

これらのデータカテゴリは、コマース データの取得にほとんど影響しません。

  • 購入履歴から派生した属性:
    • Google のシステムでは、パーソナライズのために過去の購入行動がすでに組み込まれています。
    • user bought a green dress yesterday などの属性を送信するのは冗長です。この情報はネイティブにキャプチャされ、利用されるためです。
    • CRM から得られる新しい分析情報に焦点を当てます。
  • Clicked email #7 などの特定のマーケティング レスポンス データ:
    • マーケティング キャンペーンの分析には関連しますが、AI に表示する検索結果を指示するものではありません。

データの完全性

関連性だけでなく、ユーザーベース全体にわたるデータの完全性も、パーソナライズの有用性に大きな影響を与えます。属性は、ユーザーの大部分で利用できる場合に最も価値が高くなります。これにより、システムはより広範なパターンを特定し、パーソナライズをより広範囲に適用できます。

  • 非常に有用:
    • ユーザーの大部分が持つ属性（ユーザーベースの 70% が shipping_state:MA を利用している場合など）。
    • これにより、堅牢なパターン認識とパーソナライズの広範な適用が可能になります。
  • あまり役に立たない場合:
    • ユーザーベースの 0.1% のみに利用可能な hair_color:blonde など、ごく一部のユーザーのみが利用できる属性。

このようなスパースデータは興味深いものですが、十分な例がないため、システムが意味のあるパーソナライズ シグナルを導き出すのが難しくなります。代わりに、顧客プロファイル全体でより広範なカバレッジを提供する属性を優先します。

データの粒度に関するガイドライン

効果的なパーソナライズを実現するには、適切なレベルのデータ粒度が不可欠です。データが広すぎたり、具体的すぎたりすると、システムが有意なパターンを特定する能力が低下する可能性があります。顧客基盤を実用的なグループにセグメント化する属性を目指します。

適切な粒度

適切な粒度の例としては、次のフィールドがあります。

  • 性別
  • 状態
  • 市区町村
  • 年齢層（30 ～ 39 歳など）

この粒度レベルでは、管理できないほどの数のカテゴリを作成することなく、パーソナライズの差別化を実現できます。

粒度が不十分

たとえば、顧客ベースの大部分が米国に居住している場合、粒度が不十分な例は country:US です。これは、顧客ベース全体でばらつきが少ない属性は、パーソナライズにほとんど役立たないためです。

粒度が過度に高い

過剰な粒度の例:

  • 正確な郵便番号（zipcode:12345）: 郵便番号は数万種類に及ぶため、ほとんどの郵便番号に関連付けられている顧客はごくわずかです。この原子化により、信号が希釈されます。郵便番号を使用する場合は、最初の 2 桁に切り捨てて、より適切な粒度を実現します。郵便番号の最初の 2 桁は、州サイズのエリアにほぼマッピングされます。
  • 正確な年齢（age:37）: 年齢カテゴリが過剰に作成されます。この数を減らすには、年齢などの数値データを 10 個程度の事前定義されたビンまたはバケット（age:30-39 など）にグループ化します。

その他のデータ ガイドライン

このセクションでは、カテゴリカル データ形式とその他のデータ形式について説明します。

カテゴリデータの形式

このシステムは、次のようなカテゴリデータ（個別の名前付きの値）に最適化されています。

  • state:MA
  • gender:male

数値データ

そのため、年齢、収入、頻度などの数値属性は、データ送信前に意味のあるバケットにグループ化する必要があります。

それぞれ、正しくない例と正しい例を次に示します。

  • age:37
  • age:30-39

追加のデータ制約

  • 属性の制限: 各クエリは最大 100 個の Key-Value ペアをサポートします。今後のリリースで、ペアのサポートが追加される可能性があります。
  • 重複するキー: 1 つのクエリ内で重複するキーは使用できません。ただし、キーごとに複数の値はサポートされています。
  • 禁止されている PII: お客様のメールアドレス、社会保障番号、氏名、クレジット カード番号などの金融データなど、特定の個人情報（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"

Key-Value のハッシュ化の組み合わせ

キーと値の両方をハッシュする場合は、個別にハッシュする必要があります。結合された Key-Value 文字列をハッシュ化しないでください。

次に例を示します。

  • 使用可能 - pet_owner:hash("dog")
  • 使用可能 - hash(pet_owner):hash("dog")
  • 不合格 - hash("Pet_owner:dog")

データ送信のベスト プラクティス

このセクションでは、重複する値の処理、データの整合性、属性キーの命名の柔軟性、さまざまなユーザー プロファイルの処理など、データ送信に関するベスト プラクティスについて説明します。

繰り返し値の処理方法

ユーザーが 1 つの属性に複数の値を持っている場合（犬と猫の両方を飼っているなど）、StringList 内の 1 つの 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 です。

欠損データの処理方法

ユーザーに関する特定の情報が利用できない場合は、プレースホルダや空の値を送信しないでください。リクエストからその Key-Value ペアを省略するだけです。

  • 例: pet:unknown や pet: は避ける

SDK とライブラリへのアクセス

これらのライブラリには、次のバージョン以降でアクセスできます。