予測の提供と Recommendations AI の評価
Google Cloud Japan Team
※この投稿は米国時間 2021 年 10 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。
この投稿では、Recommendations AI を使用して運用中のウェブサイトに予測を表示し、A/B テストを設定してパフォーマンスを測定する方法をご紹介します。A/B テストでは、ページを 2 つ以上のバージョンで作成し、ユーザー トラフィックをグループに分けて、その変更による影響を見極めます。これは、Recommendations AI の効果を測定するのに最も優れた方法です。A/B テストを使って既存のレコメンデーション エンジンと Recommendations AI を比較できます。または現在サイトでレコメンデーション エンジンを使用していない場合は、Recommendations AI のようなレコメンデーション エンジンの効果を測定できます。また、ページ上の配置場所の変更や、さまざまなオプションをテストして、ご自身のサイトに最適な設定を見つけることができます。
もしこれまでの Recommendations AI のブログ投稿をご覧になっていれば、モデルを作成し、ライブ レコメンデーション（「予測」とも呼ばれる）を提供する準備ができていることと思います。Retail API の predict メソッドを使用して、どのサービス構成を使用するかを指定し、さらに入力データを指定すると、アイテム ID のリストが予測として返されます。
predict メソッド
predict メソッドは、Recommendations AI からレコメンデーションを取得する手段です。予測結果はモデルタイプの目標に基づき、確率の高いアイテムから順に並ぶ順序付きリストで返されます。入力されたデータに基づいて、アイテム ID のリストが返され、それをエンドユーザーに表示できます。
predict メソッドは、サービス アカウントを使用して OAuth 経由で認証されます。一般的には、predict リクエスト専用のサービス アカウントを作成し、「Retail 閲覧者」のロールを割り当てます。Retail のドキュメントには、curl で predict を呼び出す方法の例が記載されています。しかし本番環境では、通常、Retail クライアント ライブラリを使用をおすすめします。
predict リクエストにはいくつかのフィールドが必要です。
プレースメント ID（提供構成）
URL の一部として渡されますuserEvent
呼び出されるモデルの必須フィールドを指定します。これは、対応するページビューで送信される実際のユーザー イベントとは区別されます（異なる場合もあります）。userEvent は必要な情報をモデルに渡すために使用されます。eventType
home-page-view（ホームページ表示）、detail-page-view（詳細ページ表示）、add-to-cart（カートに追加）などvisitorId
すべてのリクエストに必要です。これは通常、セッション ID ですuserInfo.userId
ログインしたユーザーの ID（必須ではありませんが、ユーザーがログインしている場合や、その他の方法でユーザーを特定できる場合は、強く推奨します）productDetails[].product.id
商品 ID を使用するモデルでは必須です（関連商品のおすすめ、似ている商品アイテム、よく一緒に購入されている商品）。「あなたへのおすすめ」は、単に vistorId / userId の履歴に基づいているため、必要ありません。
1 つの商品（商品詳細ページのプレースメント）または商品のリスト（カートページ、注文完了、カテゴリーページなど）を渡すことができます
また、結果を制御するためのいくつかのオプション フィールドがあります。
filter
カタログの一部として含まれているカスタムタグのフィルタリングに使用されます。また、OUT_OF_STOCK（在庫なし）の商品を除外することもできます。pageSize
レスポンスで返す予測の数を制御しますparams
各種パラメータ:returnProduct を使用して、レスポンスで商品の全データを返します（デフォルトでは ID のみ）
returnScore を使用して、商品ごとの確率スコアを返します
priceRerankLevel と diversityLevel を使用して、再ランク付けとダイバーシティの設定を制御します。
予測応答は、好みに合わせて使用できます。通常、結果はウェブページに組み込まれますが、パーソナライズされたメールやアプリケーション内でレコメンデーションを提供するために使用することもできます。ほとんどのモデルはリアルタイムでパーソナライズされているので、結果はすぐに古くなってしまうため、長期間キャッシュまたは保存されるべきではないということに留意してください。
クライアントサイドでのレコメンデーションの提供
完全なウェブページのレスポンスの一部として結果を返すことは、レコメンデーションをページに組み込むための 1 つの方法ですが、いくつかのデメリットがあります。サーバーサイドでの実装は「ブロッキング」リクエストであるため、ページのレスポンス全体に若干のレイテンシをもたらす可能性があります。また、ページのサービスコードとレコメンデーションのコードが密結合になります。サーバーサイドのインテグレーションによって、レコメンデーションのサービスコードがウェブ検索結果の提供のみに限定され、モバイルアプリケーションでは別のハンドラが必要になる場合もあります。
レコメンデーションを Ajax で実装することで、これらの問題を解決できます。predict メソッドには認証が必要なため、クライアントサイドの JavaScript から直接呼び出すことができる Recommendations AI の直接 API エンドポイントはありませんが、Ajax リクエストを処理するハンドラを実装するのは簡単です。既存のサービスを提供するインフラストラクチャ内にデプロイされたウェブアプリやエンドポイントとして実装することもできますし、App Engine や Google Cloud Function にデプロイするのもよい方法です。
Google Cloud Functions（GCF）は、この種のハンドラを迅速にデプロイするのに優れたサーバーレスの方法です。Recommendations AI に適した GCF の例はこちらからご覧いただけます。この例では、python と Retail クライアント ライブラリを使用して、JSON または HTML でレコメンデーションのレスポンスを返すことができるエンドポイントを提供しています。
この動画では、Cloud Functions を設定し、ウェブページから呼び出して、結果を <div> 内にレンダリングする方法を紹介します。
レコメンデーションの A/B テスト
Recommendations AI のフロントエンド インテグレーションが完了したら、自分のサイトで評価することをおすすめします。変更をテストするための最良の方法は、通常、ライブ A/B テストです。
レコメンデーションの A/B テストは、さまざまな変更をテストして比較するのに便利です。
既存のレコメンデーション エンジンと Google Recommendations AI の比較
Google のレコメンデーションとレコメンデーション エンジンを使用しない場合の比較
さまざまなモデルや提供されるサービスの変更（CTR と最適化された CVR の比較、または再ランク付けとダイバーシティの変更）
UI の変更やページ上の異なるプレースメント
Recommendations AI の A/B テストに関するヒントはこちらでご覧いただけます。
一般的には、A/B テストでは、トラフィックを 2 つ以上のグループに分け、各グループに異なるバージョンのページを提供し、その結果を報告します。社内でカスタマイズされた A/B テストのフレームワークや、サードパーティの A/B テストツールをお使いの場合もあるかと思いますが、ここでは例として、Google オプティマイズを使用して Recommendations AI の基本的な A/B テストを行う方法を紹介します。
Google オプティマイズとアナリティクス
すでに Google アナリティクスを使用している場合、Google オプティマイズによって管理しやすい A/B テストが提供され、その結果は Google アナリティクスのレポートとして表示されます。Google オプティマイズを使用するには、Google アナリティクスにオプティマイズのアカウントをリンクし、オプティマイズ タグをインストールするだけです。一度インストールすれば、サーバーサイドのコードを変更することなく、新しいテストを作成して実施できます。
Google オプティマイズは、UI、DOM の変更、CSS といった主にフロントエンドのテスト用に設計されています。オプティマイズでは、テストの各パターンに JavaScript を追加することもできます。これは、Ajax 呼び出しを経由して表示されるコンテンツ（Google の Cloud Functions など）をテストする際に便利です。サーバーサイドでレンダリングされたコンテンツを使用して A/B テストを行うことは可能ですが、通常はリダイレクト テストを行うか、Optimize JavaScript API を使用して実施する必要があります。
例えば、2 つの異なるモデル（似ている商品アイテムや関連商品のおすすめ）を同じページでテストしたいとします。どちらのモデルも商品 ID を入力として受け取り、商品詳細ページのプレースメントに適しています。この例では、レコメンデーションを HTML 形式で返す Cloud Functions の関数またはその他のサービスが実行されていると想定しています。この結果は、div に挿入され、ページが読み込まれたときに表示されます。
オプティマイズのテストを設定するための基本的な手順は次のようになります。
Google オプティマイズのコントロール パネルで [エクスペリエンスを作成] をクリックします
エクスペリエンスに名前をつけ、エクスペリエンス タイプとして A/B テストを選択します
「関連商品のおすすめ」と「似ている商品アイテム」の 2 つのバリアントを追加します
バリアントの重みをオリジナルでは 0 にして、2 つのバリアントでは 50% / 50% に設定します
各バリアントを編集し、Ajax 呼び出しを「グローバル JavaScript コード」に追加して、div が自動入力されるようにします
ページのターゲット設定に URL のマッチング ルールを追加し、すべての商品詳細ページにマッチさせます
テストの主な目標と副次的な目標を設定します
例えば、主な目標として収益やトランザクション、副次的なのものとしてレコメンデーションのクリックやその他の有用な指標、のように設定します必要に応じて、トラフィックの割り当てなどのその他のオプション設定を変更します
インストールを確認し、[開始] をクリックしてテストを開始します
このシナリオでは、デフォルトでページ上に空の <div> を用意し、Cloud Functions の関数を呼び出す 2 つのバリアントを、各バリアントで異なるプレースメント ID で作成しています。現状のレコメンデーションを既存の <div> で使用したものをオリジナルとし、バリアントを 1 つのみにすることもできますが、レコメンデーション エンジンへの不要な呼び出しが発生するだけでなく、既存の <div> コンテンツが変更されるのに伴って画面がちらつく可能性があります。
テストが実施されたら、[レポート] タブをクリックして、いくつかの指標を見ることができます。
オプティマイズは、主な目標に基づいてテストの結果、最適なものを予測します。ただし、より詳細なレポートを表示するために、[アナリティクスで表示] ボタンをクリックして、テストで異なるセグメントに対してアナリティクスが分析したすべての指標を見ることができます。
このケースでは、最適なものを明確に選ぶのは難しいですが、「似ている商品アイテム」モデルがセッションあたりの収益を少し増やしていて、他の目標を見るとクリックスルー率が高いことがわかります。テストを続行、または別のオプションで新たなテストをすることもできます。小売店の多くは、A/B テストを継続的に行い、サイト上の新しい機能やオプションをテストして、ビジネスの目標に最適なものを見つけています。ですから多くの場合、最初の A/B テストはほんの始まりにすぎません。
詳しくは、メインの Retail のドキュメントや、Recommendations AI を使用した A/B テストに関するヒントをご覧ください。
- テクニカル ソリューション コンサルタント Eric Larson
