A/Bテストとは

A/Bテストでは、同じスキルの2つのバージョンを同時にデプロイし、ユーザーからリアルタイムのフィードバックを受けて比較することができます。このため、特定の変数を使ってテストし、どちらのバージョンがよりよい反応を得られるかを判断できます。このプロセスにより、データに基づいてローンチの判断や新機能のリリースを行うことができます。

たとえば、あらかじめ設定したテストメトリクスを使って、新しい更新でスキルに問題が発生しないかを見極めたり、新機能のテストでユーザーエンゲージメントを高めたりすることができます。

A/Bテストでできること

評価する仮説に応じて、スキルで実施するテストの種類を決定します。ただし、テストできるスキルアトリビュートの種類には、一部制限があります。

  • A/Bテストを実施できるスキルアトリビュート： スキル内課金プロンプト、プレビューされたコンテンツ、対話モデル、スキルマニフェストなど、スキルのAWS Lambdaまたはスキルコードで提供されるアトリビュート（APL-Aデータを含む）。
  • A/Bテストを実施できないスキルアトリビュート： 新しいロケールのローンチ、呼び出し名の変更、権限の変更、アカウントリンクの変更、ISPの商品価格変更（無料トライアルの長さなど）。

以下の表に、実施できるサンプルテストをまとめています。

テストカテゴリー テスト例

スキル内課金（ISP）
  • ユーザーの再購入頻度を増やすため、さまざまなISP購入プロンプトをテストします。
  • 有料ユーザーを増やすため、ユーザーがプレミアムサウンドをプレビューできる新しいインテントをテストします。

対話モデル
  • さまざまな発話やインテントをテストします。
  • さまざまなスロット値をテストします。

エンドポイント
  • 条件付きロジックを使って2つのバージョンにスキルコードを分岐させます。
  • 2つのLambdaを使ってスキルコードを分離し、異なるエクスペリエンスをテストします。

A/Bテストのしくみ

ユーザーがスキルを呼び出すと、ユーザーにはコントロールバージョン、トリートメントバージョンのうち、どちらかのバージョンがランダムに提供されます。

  • コントロールバージョン（C） – テストを開始する前の、公開中スキルの現在のエクスペリエンスです。
  • トリートメントバージョン（T1） – スキルの新しいエクスペリエンスです。これは、テスト中のスキルバージョンであり、更新したコード変更が含まれます。

正確な比較を行えるよう、A/Bテストはブラインドテストで行われます。つまり、ユーザーは、自分に提供されているバージョンがコントロールかトリートメントかを知りません。テストの最後に、トリートメントバージョンをすべてのユーザーに公開するか、コントロールバージョンに戻すかを選択できます。

実行できるA/Bテストの種類

  • エンドポイントベースのテスト – A/Bテストの実施に、公開中スキルの1つのバージョンのみを使用します。公開中スキルのコードに条件文を追加することで、コントロールとトリートメントのエクスペリエンスを定義します。これらの文により、スキルをC、T1のバージョンに効果的に分岐できます。

利用資格条件

A/Bテストを実施するには、以下の利用資格条件を満たす必要があります。

エンドポイントベースのA/Bテスト

エンドポイントベースのA/Bテストを実施するには、スキルが以下の利用資格条件を満たす必要があります。

  • スキルが公開中であること。
  • スキルがカスタム音声対話モデルを使っていること（カスタムスキル）。

テストをCとT1に分岐させる方法

以下の手順に従って、スキルの動作をT1とCに分けます。

エンドポイントベースのテスト

エンドポイントベースのテストを実施する場合、スキルコードをCとT1のバージョンに分岐させる必要があります。以下のコードは、これらの分岐の作成例です。

エンドポイントベースのテストを作成する詳細な手順については、エンドポイントベースのA/Bテストをセットアップするを参照してください。

NodeJSの例

const testId = "<<test_id>>"; // テストIDをASK CLI/開発者コンソールの独自IDに置き換えてください
      const test = handlerInput.requestEnvelope.context.Experimentation
                          .activeExperiments.find(exp => exp.id == testId);
      if (test) {

        const treatment = test.assignedVariant.name;

        if (treatment == interfaces.alexa.testation.VariantName.TREATMENT_1) {
          return handlerInput.responseBuilder.speak("トリートメントの応答")
                .addExperimentTrigger(testId)
                .getResponse();
        } else {
          return handlerInput.responseBuilder.speak("control response")
                .addExperimentTrigger(testId)
                .getResponse();
        }
      } else  {
        return handlerInput.responseBuilder.speak("トリートメントには露出しません")
              .getResponse();
      }

A/Bテストのライフサイクル

A/Bテストの実施中は、作成済み、有効、実行中、停止済み、削除済みのプライマリー状態のいずれかで遷移します。これらの状態により、テストが特定のタイミングでどのようなアクションを実行するかがわかります。

また、次のようなセカンダリー状態もあります。これらの状態は、プライマリー状態間での遷移中に使用されます。セカンダリー状態には、有効化、停止中、失敗などがあります。

A/Bテスト状態遷移図

A/Bテストを完了するには、テストの作成、テストの開始、テストの停止という状態を有効にする必要があります。

次のワークフロー図は、このライフサイクルを表しています。

A/Bテストを作成する（必須）
→
A/Bテストを更新する（任意）
→
A/Bテストを有効にする（任意）
→
A/Bテストを開始する（必須）
→
A/Bテストを停止する（必須）
→
A/Bテストを削除する（任意）

状態の遷移

A/Bテストを次の状態間で遷移するには、ASK CLI、SMAPI APIのいずれかを使用します。

  • A/Bテストの作成API – 遷移先はCREATEDです。
  • A/Bテストの管理API – 遷移先はENABLED、STOPPED、RUNNINGです。
  • A/Bテストの削除API – 遷移先はDELETEDです。

各APIを使って対応する状態に遷移する方法の詳細については、A/B Testing SMAPI APIsを参照してください。

状態の詳細

以下の表に、各状態の具体的な実装の詳細をまとめています。

プライマリー状態

状態 値 説明 次のステップ

テストを作成する

CREATED

指定した設定でテストを作成します。

テストのデザイン時にこの状態に遷移します。

  • この状態によって、ユーザーに対してテストが開始されたり、テスト設定が有効になったりすることはありません。
  • 必要に応じてテスト設定を更新できます。

テスト設定を調整している間は、この状態のままにします。

  • テストを試すには、ENABLED状態に遷移します。
  • QAチェックなしでテストを開始するには、RUNNING状態に遷移します。
  • テストを削除するには、DELETED状態に遷移します。

テストを有効にする

ENABLED

テスト設定をデプロイしますが、テストは開始しません。

ユーザーに公開する前に設定のQAを行う場合、この状態に遷移します。

  • 自分が所有するスキルで、ユーザートリートメントオーバライドをT1に設定しているものだけに、T1エクスペリエンスが提供されます。
  • データ収集は開始されません。自分が行うQAがテスト結果に影響することはありません。

テストのQAを行っている間は、この状態のままにします。

  • テストを開始して、ユーザーへの公開を行うには、RUNNING状態に遷移します。
  • テストを中止するには、STOPPED状態に遷移します。

テストを開始する

RUNNING

テストを開始します。

ユーザーにT1エクスペリエンスの提供を開始する場合は、この状態に遷移します。

  • テストは、exposurePercentage値で定義したパーセンテージのスキルユーザーに表示されます。ユーザーは、T1、Cのエクスペリエンスにランダムに割り当てられます。
  • データ収集が開始されます。

テストを実施している間は、この状態のままにします。

  • テストを停止して結果を分析するには、STOPPED状態に遷移します。

テストを停止する

STOPPED

テストを終了します。

テストを停止して結果を分析する場合、この状態に遷移します。

  • すべてのユーザーに、Cのエクスペリエンスが提供されます。
  • メトリクスの収集は行われなくなります。
  • この状態に遷移したあとに、テストを再開することはできません。

テストメトリクスを分析している間は、この状態のままにします。

テストを削除する

DELETED

テストを削除します。

テストと、分析を含めて関連するすべてのデータを完全に削除する場合、この状態に遷移します。

ASKがテストを削除するまで待機します。

セカンダリー状態

状態 値 説明 次のステップ

テストを有効化中

ENABLING

CREATEDからENABLEDに遷移する間の状態です。

この状態は一時的なものであり、この状態にある間にテストに対して何らかのアクションを実行することはできません。

有効にしなければテストは始まらないため、ENABLED状態をバイパスする場合も、自動的にこの状態に遷移します。

テストがENABLEDに遷移するまで待機します。

テストを停止中

STOPPING

RUNNINGからSTOPPEDに遷移する間の状態です。

この状態は一時的なものであり、この状態にある間に何らかのアクションを実行することはできません。

テストがSTOPPEDに遷移するまで待機します。

テスト失敗

FAILED

テストが有効にされなかったか、開始されませんでした。

この状態に遷移することはできません。テストを有効にしたり、開始したりしようとしたときにテスト設定のデプロイに失敗した場合、この状態に遷移します。

テスト設定を確認して、もう一度試してください。

このページは役に立ちましたか？

最終更新日: 2022 年 02 月 18 日