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