その他の考慮事項とテスト

会話型コマース エージェント インターフェースのベスト プラクティスとテストでは、追加の考慮事項を考慮する必要があります。

ベスト プラクティスを実装する

会話型コマース エージェントのインターフェースを実装する際は、以下のベスト プラクティスを参考にしてください。

  • 訪問者 ID の一貫性: 特定のエンドユーザーに対する各リクエストで、一意の visitor_id が一貫して送信されるようにします。これは、正確なパーソナライズとモデル トレーニングに不可欠です。この ID は、セッションやログイン / ログアウトの状態にかかわらず、エンドユーザーに対して一貫性を保つことが理想的です。
  • ブランチ管理: default_branch は一般的ですが、商品カタログが複数のブランチで構成されている場合は、正しいブランチ ID を使用していることを確認してください。
  • Search API のインタラクション: SIMPLE_PRODUCT_SEARCH の場合と refined_search が指定されている場合は、refined_search フィールドの query または元のクエリを使用して、コア Search API（SearchService.Search）に個別の呼び出しを行い、実際の商品のリスティングを取得してください。Conversational API は、主に会話エクスペリエンスとユーザーの意図の理解に重点を置いており、商品結果を直接返すことはありません。
  • ユーザー インターフェースの設計: conversational_text_response、followup_question、refined_search のオプションを直感的にユーザーに提示し、ユーザーをガイドするウェブ インターフェースを設計します。

A/B テストを計画する

関連性は重要な入力指標ですが、Vertex AI Search for commerce では、ビジネス成果の最適化を目的として、他の変数も考慮されます。

指標
訪問あたりの収益（RPV） 検索パフォーマンスを測るうえで最も効果的な指標は、コンバージョン率、平均注文額、関連性を考慮した「セッションあたりの収益」です。
コンバージョン - 平均注文額（AOV） コンバージョン率と AOV はどちらも RPV に影響します。
関連性 - 購入可能性 - 価格 関連性は、他の入力とともに、パフォーマンスの高い検索結果を生成するために使用されます。

A/B テストの準備状況チェックリスト

使用された成功指標は次のとおりです。

項目 定義 ステージ
イベント アトリビューション スキーム Google と協力して、測定用のユーザー イベントを適切にセグメント化します。 テスト前
モニタリング データ入力 パフォーマンスに影響する可能性のある異常がトレーニング データに含まれているかどうかをすばやく把握できます。 テスト前
イベントの報道 検索またはレコメンデーションの AI セッションに関連する考えられるすべての結果を計測していますか？ テスト前
測定可能な成功基準 完了の定義（測定可能な用語で）が文書化されている。 テスト前
UX のバイアスを測定する機能 テスト群間で一貫した UX を確保します。 テスト期間中
VAIS データと使用量の整合性 アトリビューション トークン、フィルタ、並べ替え、オフセットなどが API から UserEvents に渡されていることを確認します。イベントと API リクエストの間で訪問者 ID/ユーザー ID が一致している。 テスト期間中
テスト期間中のチューニングの承認 チューニング アクティビティを計画し、変更を文書化し、測定と解釈を適宜調整します。 テスト期間中

概念実証または最小実装製品を実装する

データの取り込み A/B テストの計画 パフォーマンス指標 ガバナンスとプロセス

最新の完全な商品カタログの取り込み

Google とお客様との間でデータを確実に同期するために、推奨されるイベント取り込み方法を遵守する。
Google では、リアルタイムのイベント トラッキング（インプレッション データを含む）を推奨。

テスト ID、訪問者 ID、適切に実装された検索トークンなど、必要なアトリビューションを渡す。

 テストのベスト プラクティスを取り入れ、確実に信頼できる結果にする:
  • 統合を確認します。
  • 一度に 1 つの変更をテストします。
  • 積極的なキャッシュ保存は避けてください。
  • テストグループとコントロール グループでウェブ インターフェースの公平性を確保する。
  • 訪問者 ID を使用したトラフィック分割でトラフィックの公平性を確保します。
  • 商品データの一貫性を確保します。
  • テストグループとコントロール グループに同じビジネスルールを適用します。
 すべての評価基準は、指標に基づいて経験的、客観的に測定する必要があります。

パフォーマンスを正確に測定するには、追跡する指標の正確な定義に基づき対応することが重要。

トラッキングする標準的な指標には、次のようなものがある:
  • 検索のクリック率（結果の関連性）
  • Null 検索率（インテントの理解）
  • 訪問者あたりの収益 / ユーザーあたりの収益
  • 変換する検索数
 データの統合、テスト、機能のロールアウト、最適化は、繰り返しのプロセスであり、リソースが必要になる。

テストの進め方の例

最小実装製品の依存関係を満たす 測定を調整する 本番環境のダークモードをデプロイする 続行または中止の判断
  • 契約
  • トレーニング済みモデルとサービング構成
  • 商品データとイベントデータの取り込み
  • （クライアント）データを Commerce 検索のテレメトリーと比較し、それに基づいて調整
  • 測定のベースラインと調整
  • オフライン評価の実施
  • 設定のチューニング
  • トラフィック分割を確認するための A/A テスト
  • QA の署名を得る
  • 勢いをつけて先に進む

A/B テストの進め方の例

継続的にテストを実施する トラフィックの X% に増やす 測定、調整、反復 実際のトラフィックの X% に増やす
  • 継続的にチューニング、最適化
  • 追加機能をテスト
  • 検索のセグメント全体でパフォーマンスを分析
  • モデリング / ルールを調整
  • パフォーマンスをさまざまな観点でチェック
  • 異常を特定して解明
  • テストを開始
  • パフォーマンス指標を毎日共有
  • パフォーマンスをチューニング

テストを成功させるための要素

測定値を調整し、成功基準を確立する テストの公平性を維持する データ品質をモニタリングする
  • 正式なリリース前に、カタログ、ユーザー イベント、API 使用量の整合性を確認する時間を確保します。
  • 事前に定量化可能な成功基準を確立します（理想的には、RPV の変化として表現します）。
  • 回帰や異常を事前に特定して説明し、修正します。
  • 測定値を頻繁に共有し、テスト群全体で指標の定義を理解して文書化します。
  • セグメント間の UX の違いを最小限に抑えます（レイアウトとビジュアルは共通で、データのみが異なります）。
  • マーチャンダイジング / ビジネスルールに注意する（バイアスが生じないようにする）。
  • カタログのドリフトを測定します。
  • 実験の結果を適切にアノテーション（ユーザー イベント経由）します。

役割とテストのオーナーシップ

Google 自分
品質評価 Commerce Search の結果 UX の影響
測定 バックアップ / 検証 権限
テレメトリー / データ プラットフォームのボリューム指標（パフォーマンスの検証）
イベントとインデックスの異常値		 アトリビューション トークンと再現手順（問題の検証）
検索プラットフォーム 商品レベルのアイテム
  • データ マッピング
  • モデル/トレーニングの調整
  • 品質/サービスの異常
  • プラットフォームの割り当て / 上限
  • 商品/クライアント ライブラリの欠陥
 クエリ/サービスの項目
  • リクエストの増加（コンテキストのルーティング、キャッシュ、インテントの処理など）
  • サービスの設定（チューニング）
  • ソースデータの拡充
  • クライアントのパフォーマンス（例: WC スレッド）
  • UX、API、プラットフォーム、ライブラリの問題点
続行/中止の決定 提案 承認

コンソールでテストを実施する

  1. Search for commerce コンソールの [テスト] ページに移動します。

    [テスト] ページに移動

  2. Google のアトリビューション方法論を適用して、Vertex AI Search for Commerce のオンボーディングと A/B テストの高度なセルフサービス分析にコンソールを使用します。

  • トラフィックのセグメンテーション、ビジネス指標、検索と閲覧のパフォーマンスをモニタリングします。

  • 検索訪問あたりの指標をキーワード検索とブラウジングの両方に適用します。

  • テストのパフォーマンスを、統計的有意性の指標を含む時系列として表示します。

  • 埋め込み Looker プラットフォームを使用します。