このページでは、Search for Retail コンソールでの A/B テスト トラフィックのモニタリングと、検索のための主要なビジネス指標の比較方法について説明します。
概要
A/B テストを実施して、既存の検索実装と Vertex AI Search for Retail の間で主要なビジネス指標を比較できます。
テストとそのトラフィック分割を設定したら、Search for Retail コンソールの [テスト] ページでテスト トラフィックをモニタリングし、ビジネス指標を表示できます。
コンソールで A/B テストのモニタリングを設定するには、名前、期間、テスト アーム情報など、A/B テストに関する情報を入力します。各テストのバリアント アームは、A/B テスト用に作成したテストグループにマッピングされます。コンソールで最初に設定したアームがベースライン コントロールとして扱われます。
各テストには [モニタリング] タブがあり、トラフィック分割の指標が表示されます。これにより、A/B テストが正しく設定されているかどうかを判断できます。これは、A/B テストにバイアスが導入されているかどうかを検証するために重要です。たとえば、注目すべき一般的な問題は、あるクエリまたはカテゴリが、1 つのテスト アームによって提供され、別のテスト アームでは提供されないかどうかです。
各テストには [分析] タブもあり、主なビジネス指標の比較を確認できます。ビジネス指標の 2 つのカテゴリは次に含まれます。
- 検索あたり、またはブラウジングあたりの指標（検索あたりのクリック数など）。
- 検索あたり、またはブラウジング訪問あたりの指標（ブラウジング訪問あたりの収益など）。
指標の一覧については、指標の一覧をご覧ください。
各ビジネス指標は、未加工の値、ベースライン コントロールと比較した相対的リフト、95% 信頼区間を提供します。集計された指標と指標の両方を日付別に表示できます。
[トラフィック モニタリング] タブには、意図しないトラフィック分割が発生したかどうか、発生した日付が表示されます。実際のトラフィック分割の割合とモニタリングの設定時に入力した目的の分割の割合を比較することで、意図しないトラフィック分割が判断されます。相対的な差異が 10% 以下の場合、トラフィック分割は正しく行われています。たとえば、トラフィックが 2 つのアームに均等に分割されると意図される場合、実際の 45% から 55% の分割が意図される範囲内になります。
コンソールを使用して、複数のテストを同時にモニタリングできます。
テストの日付と指標で日付別にスライスされた指標では、America/Los_Angeles がタイムゾーンとして使用され、America/Los_Angeles の日付と終了日が午前 12 時に使用されます。
コンソールでテストの詳細（開始日、終了日、バリアント アームの数、テスト ID、意図したトラフィック分割の割合など）を、テストの進行中、終了、保留中のいずれでもいつでも更新できます。データは過去にさかのぼって更新されます。
A/B テストのモニタリングと分析には次の要件/制限事項があります。
トラッキングできるテストデータの最大期間は 180 日です。テストが 180 日以上前に開始された場合、それより古い指標はキャプチャされません。
クエリまたはカテゴリごとのトラフィック モニタリングでは、テストですべてのバリアント アームのトラフィックが最も多い上位 100 個のクエリまたはカテゴリのみが返されます。
始める前に
Search for Retail コンソールで A/B テストのモニタリングを設定する前に、次のことを行います。
既存の検索実装と Vertex AI Search for Retail によって提供されるイベントに対して、ユーザー イベントの取り込みを設定します。
A/B テストのベスト プラクティスを確認します。
Google オプティマイズや Optimizely などのサードパーティのテスト プラットフォームを使用してテストを設定します。
各テストグループのユーザー イベント
experimentIdsを設定してメモします。 テストのモニタリングを設定するときは、各バリアント アームのテスト ID を指定する必要があります。
コンソールでテストを追加する
Search for Retail コンソールでモニタリングする新しいテストを追加するには、次の手順を行います。
この手順では、サードパーティのテスト プラットフォームで作成した既存のテストグループに対応するバリアント アームを Search for Retail コンソールに作成します。バリアント アームを既存のテストグループにマッピングする方法の例については、テスト設定の例をご覧ください。
テストの詳細を追加する
コンソールでテストを追加し、その詳細を入力します。
Search for Retail コンソールの [テスト] ページに移動します。
[テスト] ページに移動[テストを追加] をクリックします。
[新しいテスト] ページが開きます。
テストの名前を入力します。
テストの開始日と終了日を選択します。
テスト トラフィックが徐々に増加するように設定されている場合は、増加が完了してトラフィック分割が安定する日付に開始日を設定します。
このテストが追跡するアクティビティの種類を選択します。
閲覧: ページカテゴリ別のサイト内ナビゲーション。 ブラウジング アクティビティは、検索レスポンス内の空のクエリによって示されます。
検索: サイト上のテキストクエリ検索。
次に、テストのバリアント アームを作成します。
バリアントを追加する
コンソールでテストの詳細を追加したら、各テストグループに対応するバリアント アームを作成します。
最初に設定したバリアント アームがベースライン バリアントです。通常、ベースラインは既存のソリューションを表します。
開始する前に、各テストグループにユーザー イベント experimentIds があることを確認してください。
[バリアント アームを追加] をクリックします。
[バリアント アームの作成] パネルが開きます。
このバリアント アームがモニタリングするテスト設定に関連付けられたユーザー イベント
experimentIdを入力します。最初のバリアント アームを設定する場合: ベースラインとして機能するベースライン グループに関連付けられたユーザー イベント
experimentIdを入力します。ベースライン バリアント アームをすでに設定している場合: 次のテストグループに関連付けられているユーザー イベント
experimentIdを入力します。
このバリアント アームには、人が読める形式の名前を入力します。
この名前は、コンソールのモニタリング ダッシュボードに表示されます。
（省略可）このバリアント アームの説明を入力します。
サービスを提供するトラフィックの宛先を選択します。
Google Vertex AI Search for Retail API: このバリアント アームが Vertex AI Search for Retail のトラフィックをモニタリングする場合。
外部: このバリアント アームが外部サービスからのトラフィックをモニタリングする場合。たとえば、テストで既存のサービスのトラフィックを Vertex AI Search の小売トラフィックと比較する場合、ベースライン（またはコントロール）のバリアント アームが外部の宛先を表す可能性が高くなります。
[作成] をクリックして、このパターン アームの作成を完了します。
パターン アームが [新しいテスト] ページに表示されます。
前の手順を繰り返して、モニタリングする各テストグループに関連付けられたバリアント アームを作成します。
少なくとも 1 つの外部アーム 1 つの Google Vertex AI Search for Retail API アームが必要です。
（省略可）デフォルトでは、意図したトラフィックの割合がすべてのバリアント アームに均等に分割されます。意図したトラフィックの割合をカスタマイズするには:
[バリアント] セクションの [トラフィックの割合] 列でトラフィックの割合の値をクリックします。
[トラフィックの割合] パネルが開きます。
[重み付け分布] フィールドで [カスタムの割合] を選択します。
各バリアント アームの [トラフィックの割合] 列に、目的のトラフィックの割合を入力します。
すべてのバリエーション アームの合計トラフィック割合の合計は 100% にする必要があります。
[完了] をクリックします。
[トラフィックの割合] パネルが閉じます。
[新しいテスト] ページで [作成] をクリックして、テストの作成を完了します。
テストは [オンボーディング テスト] ページに表示されます。
テスト設定の例
このセクションでは、テストの設定例を 2 つ紹介します。
例 1 は、ベースラインコントロールと 1 つの Vertex AI Search for Retail テストグループを示しています。
例 2 は、ベースライン制御を小売テストグループの 2 つの Vertex AI Search と比較する方法を示しています。
例 1: 2 つのバリアント アーム
この例では、以下を使用して A/B テストを設定するとします。
- ベースラインコントロール グループとして社内検索エンジンに送信される検索リクエストの 20%
- テストグループとして Google Vertex AI Search for Retail API に送信される検索リクエストの 20%
- A/B テストを使用していないホールドアウト グループとして 60%
リクエストとユーザー イベントの構成は、次のようになります。
| トラフィックの種類 | ディスカバリー エンジン | event.experimentIds |
event.attributionToken |
トラフィックの割合 |
|---|---|---|---|---|
| 交通整理 | 社内 | CONTROL |
該当なし | 20% |
| テスト トラフィック | Google Vertex AI Search for Retail API | EXPERIMENT |
検索レスポンスからの属性トークン | 20% |
| トラフィックの保留 | 次のいずれかまたは両方 | 該当なし | 検出エンジンに依存 | 60% |
ホールドアウト トラフィックは、社内検索エンジン、Vertex AI Search for Retail、またはその両方から提供される可能性があります。A/B テストに含まれないため、テスト ID はありません。A/B テストに含まれるユーザー イベントを示すには、experimentIds と attributionToken の情報を指定します。experimentId の文字列は、この例とは異なる場合があります。テストとユーザー イベント間で一貫した ID が使用されるようにします。
コンソールで対応するテストを作成する場合、ホールドアウト グループはテストの一部ではないため、バリアント アームは 2 つのみ作成します。2 つのバリアント アームに分割されるトラフィックの割合は、50% / 50% となります。
このサンプルテストのモニタリングを設定するには、テストグループごとに対応するバリアント アームをコンソールに作成します。次の表に、この例のバリアント アームの設定中にコンソールに入力する情報を示します。
| バリエーション アーム名 | トラフィックの宛先 | ユーザー イベント テスト ID | 意図したトラフィックの割合 |
|---|---|---|---|
| コントロール アームの例 | 外部 | CONTROL | 50% |
| テストアームの例 | Google Vertex AI Search for Retail API | 実験 | 50% |
例 2: 3 つのバリアント アーム
この例では、ヘッドクエリ（高頻度クエリ）に A/B テストを実施し、動的ファセットの有効化と無効化の両方を含めるとします。リクエストとユーザー イベントの構成は次のようになります。
| バリエーション アーム名 | トラフィックの宛先 | event.experimentIds | event.attributionToken | トラフィックの割合 |
|---|---|---|---|---|
| ヘッドクエリ制御 | 社内 | CONTROL | 該当なし | ヘッドクエリの 50% |
| ヘッド クエリの動的ファセット ON テスト | Google Vertex AI Search for Retail API | EXP_DF_ON | 検索レスポンスからの属性トークン | ヘッドクエリの 25% |
| ヘッド クエリの動的ファセット OFF テスト | Google Vertex AI Search for Retail API | EXP_DF_OFF | 検索レスポンスからの属性トークン | ヘッドクエリの 25% |
| ヘッド以外のクエリとその他のホールドアウト | Google Vertex AI Search for Retail API | 該当なし | 使用するエンジンによって異なります | 該当なし |
このサンプルテストのモニタリングを設定するには、テストグループごとに対応するバリアント アームをコンソールに作成します。次の表に、この例のバリアント アームの設定中にコンソールに入力する情報を示します。
| バリエーション アーム名 | トラフィックの宛先 | ユーザー イベント テスト ID | 意図したトラフィックの割合 |
|---|---|---|---|
| コントロール アームの例 | 外部 | CONTROL | 50% |
| テスト群 1 の例 | Google Vertex AI Search for Retail API | EXP_DF_ON | 25% |
| テスト群 2 の例 | Google Vertex AI Search for Retail API | EXP_DF_OFF | 25% |
トラフィック指標
テストの [モニタリング] ページには、次の指標の意図しないトラフィック分割が表示されます。
- 1 日あたりの検索/閲覧イベント数
- 1 日あたりの検索/参照ユーザー数
- カテゴリごとの検索/閲覧イベントの数
これらの指標のいずれかに対して意図しないトラフィック分割が発生すると、[モニタリング] ページの上部にあるカードに、意図しないトラフィック分割が発生した日付が表示されます。[意図しないトラフィック分割] をクリックすると、その指標の意図しないトラフィック分割を一覧表示するフィルタ可能なテーブルが表示されます。
テストの [モニタリング] ページの次の表では、使用状況に応じて、バリアント アーム間のトラフィック指標を比較します。テーブル タイトルの横にある [もっと見る] をクリックすると、その指標のすべてのトラフィック分割を一覧表示する、フィルタ可能なテーブルが表示されます。
1 日あたりの検索/閲覧イベント数: 特定の日付のバリアント アームで発生した検索または閲覧の総数。
1 日あたりの検索/参照ユーザー数: 特定の日付にバリアント アームに対してクエリを実行または閲覧した訪問者の数。
カテゴリ別の検索 / 閲覧イベント数: テストの開始日から終了日までの、バリアント アームで特定のクエリまたはカテゴリが検索された合計回数（テストが進行中の場合は今日の日付まで）。この表には、テストのすべてのバリアント アームの合計トラフィックに関する上位 100 件のクエリまたはカテゴリのみが表示されます。
テストをモニタリングする
[オンボーディング テスト] ページに、最近のテストの表が表示されます。
テストをモニタリングするには:
Search for Retail コンソールの [テスト] ページに移動します。
[テスト] ページに移動テスト名をクリックします。
そのテストの [モニタリング] ページが開きます。
意図しないトラフィック分割がないか、ページを確認します。
各指標には、意図しないトラフィック分割が発生した日付が表示されます。
意図しない分割があった場合は、[意図しないトラフィック分割] をクリックして、その指標の意図しないトラフィック分割を示すフィルタ可能なテーブルを表示します。
意図しないトラフィック分割に対処する
Search for Retail コンソールでテストをモニタリングすると、テストでの潜在的な問題に注意を引くことができます。
意図しないトラフィック分割が発生した場合は、イベントに正しいテスト ID がタグ付けされていることを確認してください。たとえば、コントロール グループに属するイベントが、間違ったテスト ID でタグ付けされた場合、そのイベントが誤ったバリアント アームに帰属する可能性があります。
イベントタグが正しく機能している場合、Search for Retail コンソールで報告された意図しないトラフィック分割は、テスト プラットフォームでのトラフィック分割の問題を示している可能性があります。このような場合は、テストで誤った結果が発生しないように、問題を解決する前に A/B テストを一時停止します。
分析のためのビジネス指標
ビジネス指標の 2 つのグループが利用できます。
- 検索あたり、またはブラウジングあたりの指標
- 検索訪問あたり、またはブラウジング訪問あたり
検索訪問あたりの指標
検索訪問あたりの指標の定義は、次のとおりです。ブラウジング訪問あたりの指標の定義は、検索訪問あたりの指標の定義と同様で、検索のすべてのインスタンスがブラウジングで置き換えられます。
注文書のレートでは、1 つの注文書に複数の SKU を含めることができます。各 SKU には 1 以上の数量を指定できます。
| 指標名 | 定義 |
|---|---|
| 検索訪問数 | 1 つ以上の検索を含む訪問数。 |
| ページビュー率 | クリック数（ページビュー）÷ 検索訪問数 |
| カート追加（ATC）率 | 検索訪問でのカート追加ユニット数 ÷ 検索訪問数 |
| 注文書レート | 検索訪問での注文書数 ÷ 検索訪問数 |
| 収益率 | 検索訪問での収益合計 ÷ 検索訪問数 |
| 平均注文額（AOV） | 検索訪問での収益合計 ÷ 検索訪問での注文書数 |
検索あたりの指標
検索あたりの指標の定義は、次のとおりです。ブラウジング訪問あたりの指標の定義は、検索訪問あたりの指標の定義と同様で、検索のすべてのインスタンスがブラウジングで置き換えられます。
| 指標名 | 定義 |
|---|---|
| 検索回数 | 検索イベント数 |
| 結果なし率 | 結果のない検索イベント数 ÷ 検索回数 |
| クリック率（CTR） | 検索ドリブンのクリック数（ページビュー）÷ 検索回数 |
| カート追加（ATC）率 | 検索ドリブンのカート追加ユニット数 ÷ 検索回数 |
| 購入率 | 検索ドリブンの購入ユニット数 ÷ 検索回数 |
| 収益率 | 検索ドリブンの収益の合計 ÷ 検索回数 |
| 平均単価（AUV） | 検索ドリブンの収益の合計 ÷ 検索ドリブンの購入ユニット数 |
テストのビジネス パフォーマンスを分析する
各テストの [分析] タブに、ビジネス指標のダッシュボードが表示されます。ダッシュボードには、バリアント アームのパフォーマンスの比較が表示されます。
指標のダッシュボードは 2 つあります。
- 検索訪問あたり、およびブラウジング訪問あたりの指標
- 検索あたり、およびブラウジングあたりの指標
検索指標またはブラウジング指標は、テストの ProductType 属性に基づいて表示されます。
各ダッシュボードには、期間フィルタに表示されている日付で集計された指標の結果を示す、サマリー指標テーブルが表示されます。デフォルトの日付値はテストの開始日と終了日です。
各指標は、集計結果テーブルと、より詳細な情報を提供する 1 日の値のグラフとして表示されます。
集計された表の期間では、テストの開始日と終了日がデフォルトの日付値として使用されます。テストが進行中の場合、終了日は現在の日付に設定されます。期間フィルタは変更できます。ユーザー イベントが取り込まれて userAgent が指定されている場合は、デバイスタイプで指標をスライスすることもできます。[更新] アイコンをクリックして、変更したフィルタを指標に適用します。
指標の相対的リフトが信頼区間の帯域幅を超えるほど正になると、そのバリアントに緑色の背景色が表示されます。 同様に、相対的ブランドリフトが負の値の場合は、そのバリアントに赤の背景色が表示されます。相対的リフトが信頼区間の幅よりも小さい場合、背景色が灰色となり、結果に統計的有意性がないことを示します。
たとえば、バリアント アームとベースラインコントロール アームを比較する場合は、次のようになります。
- [検索あたりのクリック率] 指標が +3.0% で、[伸び CI] として表示される信頼区間が [2.1%、4.0%] の場合、バリアント アームは緑色でハイライト表示され、ベースライン コントロールと比較してこの指標のバリアントのパフォーマンスが良いことを示しています。
- [ブラウジング訪問あたりの収益率] 指標が -1.5% で、信頼区間が [-2.6%、-0.4%] の場合、バリアント アームは赤色でハイライト表示され、ベースライン コントロールと比較してこの指標のパフォーマンスが悪いことを示しています。
- [検索あたりの平均単価] 指標が +1.0% で、信頼区間が [-1.1%、3.0%] の場合、バリアント アームは灰色でハイライト表示され、パフォーマンスの差は統計的に有意ではないことを示しています。
一般に、データポイントが多いほど、差異は小さくなります。数週間にわたる累積指標は、日次指標よりも信頼区間の幅が低くなり、統計的に有意である可能性が高くなります。
テストの詳細を変更する
コンソールでテストの詳細（開始日、終了日、バリアント アームの数、テスト ID、意図したトラフィック分割の割合など）を、テストの進行中、終了、保留中のいずれでもいつでも更新できます。データは過去にさかのぼって更新されます。
テストの詳細を編集するには:
Search for Retail コンソールの [テスト] ページに移動します。
[テスト] ページに移動最近のテストを示す表で、変更するテストを見つけます。
表の行の右側にあるその他メニューの アクション] をクリックし、[編集] をクリックします。
[テストの編集] ページが開きます。
更新したいテストフィールドを変更します。
[更新] をクリックして、変更を保存します。
コンソールからテストを削除する
Search for Retail コンソールからテストを削除するには:
Search for Retail コンソールの [テスト] ページに移動します。
[テスト] ページに移動最近のテストを示す表で、削除するテストを探します。
表の行の右側にあるその他メニューの アクション] をクリックし、[削除] をクリックします。
[テストを削除しますか？] 確認ウィンドウが開きます。
テスト名を入力し、[確認] をクリックして削除を確定します。
削除が完了すると、テストが正常に完了したことを示すメッセージがコンソールに表示されます。