Amplitudeエクスペリエンス概要: A/Bテストを通じて製品エクスペリエンスを最適化する – Amplitude

この記事のテーマ:

一般の実験の値と、Amplitude Experimentが御社のより良い意思決定とより良い製品の構築にどのように役立つかを理解する
Amplitude Experimentで実験または機能フラグの作成に関連するコンセプトとプロセスに慣れる

何十年もの間、製品チームは、製品調整を優先し、実行する方法として、実験に依存してきました。しかし、それは決して簡単ではありませんでした。そのため、実験は、多くの場合、製品エクスペリエンス全体を最適化する全体像の変更を推進するのではなく、マージンに関する周辺の問題を微調整しているだけとなっています。

Amplitude Experimentは、ワークフロー主導の行動実験プラットフォームであり、実際にロードマップを加速し、お客様がより良い意思決定とより良い製品の構築に集中できるようにします。

Experimentでは、固有オーディエンスに対する製品エクスペリエンスを簡単に変更および構成できます:

製品実験: 実験とA/Bテストを実行することで、新しいユーザーのオンボード、チェックアウトエクスペリエンスの摩擦を軽減、新しい機能のロールアウトなどを行ない、主要なKPIを改善します。
プログレッシブ機能デリバリー: ベータテスター、一定の割合のユーザー、または特定のターゲットオーディエンスのための新しい機能の事前計画とステージングです。
ダイナミックなインプロダクトエクスペリエンス: カスタムエクスペリエンスを大規模に展開および適応させます。

Amplitude Experimentは、フラグを通じて、これらすべてを有効にします。これは、コードを変更することなく、製品のエクスペリエンスを変更できる簡単なセットアップスイッチです。それを使用して、製品で実験を設定したり、新しい機能をユーザーに直接ステージングしたり、またロールアウトしたりできます。コードは、Amplitude Experiment SDKまたはREST APIを使用して、Amplitude Experimentと通信します。

注意: Amplitude Experimentは、すべての実験で連続テスト統計モデルを使用します。

この記事では、Amplitude Experimentワークフローのハイレベルな概要について説明します。これには、ヘルプセンターにある詳細記事へのリンクが含まれています。最初のワークフローでは、実験を作成し、次のワークフローで機能フラグを作成します。

実験の作成: 概要

多くの実験プログラムは、プロセスの最初のステップで失敗します。そして、誰も、実験が解決するはずの問題を明らかにすることができません。実験を行っている理由を、単純明快な言葉で説明できないのなら、なぜ実験を行っているのでしょうか。そこから何か有益なことを学ぶことは現実的に期待できません。

他のことをする前に、時間を取って実験についての強力なミッションステートメントを考えてみてください。少なくとも、これらの2つの質問に答えてください: 問題は何ですか、そして実験を行うことで、その問題がどのように解決しますか？この段階で注いだ労力は、のちに大きな成功となります。

ここまで終われば、実験を構成する準備が整います。これは、実験の新しい環境を作成（または以前に作成したものを選択）して、これから使用するSDKをインストールするという意味です。

仮説を作成する

次に、実験のミッションステートメントに戻ります。これは、実験の仮説の基礎となります。仮説とは何でしょうか？それは、実験がどのように結果として出てくるかを予測することです。それで実験が成功するか、または失敗するかを知ることができます。

しかし、この問題ステートメントは、仮説の最初の部分に過ぎません。他にも2点: 提案されたソリューション、そして予測された結果があります。前者は、基本的に、問題を解決する変更の説明です。例えば、2つのオンボーディングプロセスのステップを1つに統合するなどです。後者は、結果として何を期待するかです。つまり、「オンボーディングチャーンの20%低減」などです。

以下は仮説ステートメントの例です:

「当社のオンボーディングファネルにおけるユーザーチャーンは、業界平均よりも大幅に高いです。製品データは、ファネルがわかりにくい可能性があると示しており、ファネルで2、3のステップを連結すれば、これを修正できると思います。この変更の結果、オンボーディングチャーンは20%減少すると予想されます。」

使用する仮説ステートメントは、特に問題定義の段階で人によって異なるでしょう。たとえば、あなたの質問は、性質上もっと調査を要するもの、つまり「なぜ多くのユーザーが当社のオンボーディングファネルから脱落するのか？」であったり、既にわかっている問題の異なるソリューションをテストすることに、より関心があるのかもしれません(「既知のユーザーの、なかなか解決しない問題を修正するために、いくつかの潜在的なUIの変更を思いつきましたが、どれが最も有効でしょうか?」など)。それでも、この基本テンプレートは、特に実験が初めての場合には、従うべきものです。

メトリックを選ぶ

その仮説ステートメントの最後の文を見てください。気づいたことは何かありますか？一つには、オンボーディングチャーンが20%減少する、のようにユーザーの行動の変化を期待する特定の測定値が含まれています。これは、実験が成功するかどうかを決定するものです: つまり、この数字になるか、ならないかということです。

ですが、どうやって知るのでしょうか？チャーンが減少することを測定する方法が必要です。そうするには、メトリックが必要となります。Amplitude Experimentでは、Amplitude Analyticsにログインしたイベントは、どれも実験メトリックとして使うことができます。上記の実験例では、メトリックとしてファネルのドロップオフを追跡するために、お手持ちの製品が使用するイベントを使います。

バリアントを作成する

この時点で、新しいオンボーディングプロセスをすべてのユーザーにロールアウトするだけで、何が起こるかを確認することができます。しかし、そうする場合、オンボーディングチャーン率が改善しても、その製品変更が原因だったのかまではわかりません。さらに、新しいファネルをロールアウトした後に、そのレートが悪化した場合はどうなるでしょうか？それは、デザインの選択の失敗、偶然の可能性、または考慮していない外部要因があったからかもしれませんが、理由を知ることはできません。

ですから、実験に少なくとも1つのバリアントを作成する必要があります。バリアントとは、簡単に言うと、一定の割合のユーザーに表示される別のユーザーエクスペリエンスです。使用例に従うと、ここでのバリアントは、オンボーディングプロセスの新しく合理化されたバージョンです。それがわかるユーザーもいますが、他のユーザーは代わりに現在のプロセス(別名コントロール)を目にすることになります。これは、実験の成功を決定する各バリアントにユーザーがどのように応答するかの違いです。

バリアントを考え出すときは、各々の変化の数を低く保つとよいでしょう(数を1まで減らすことができれば、それに越したことはありません)。また、バリアントがそれぞれ違うことを確認できるようにするのもよいです。このようにして、各バリアントセグメントのユーザーが互いにさまざまな方向から製品を経験していることを確認することができます。また、変化がセグメント間での行動に違いをもたらすことも確認できます。

ユーザーを割り当てる

バリアントが完了しました。次に、それらを見るユーザーの数を決定する必要があります。実験をユーザーベース全体にロールアウトするか、またはその一部だけにロールアウトできます。実験で何人のユーザーがコントロールを見るか、そして何人がバリアントを見るかを指定します。実験に含める、または除外する特定のユーザーセグメントを定義できます。また、個々のユーザー、あるいはデバイスIDに向けた特定のエクスペリエンスを選択することもできます。

実験を有効にする

この時点で、実験をユーザーにロールアウトする準備が整います。トグルスイッチを[有効]にするだけで、実験が有効になります。以上です！

結果を分析する

実験が完了したら、いつでも結果を生成および表示することができます。実験は、統計的有意に達したときにそのことを通知します。また、結果を分析および解釈するのに必要なデータが得られるので、そこから学習したものを今後の製品エクスペリエンスに適用します。

実験の設計、ロールアウト、学習についての詳細は、Amplitude Experimentを活用するのヘルプセンターの記事を参照してください。

機能フラグの作成: 概要

一方、フェーズド機能のロールアウトを計画する場合、ワークフローはさらにシンプルになります。製品でユーザー行動について質問していないため、仮説の作成、メトリックの選択、結果の分析などを心配する必要はありません。機能フラグを作成するだけです。

注意: 舞台裏では、実験とフラグは非常に似ていますが、基本的な違いは次のことです: 実験は、ビジネスに適したものを構築しているか確認するのに役立ちます。機能フラグでは、シームレスな機能をリリースおよびロールバックできます。両方で同様のアプローチができますが、それについては別々に考える必要があります。また、おそらく、ワークフローにもそうしたことを反映させるべきでしょう。

環境を構成したら、バリアントを作成するに進みます。基本的な考えは変わりません。つまり、一部のユーザーには見えるが、その他のユーザーには見えない、新しい、異なる製品エクスペリエンスです。しかし、異なるユーザーセグメントが異なるユーザーエクスペリエンスにどのように反応するかを探るのではなく、最初に新しい機能にアクセスできるユーザーを選択します。機能フラグを処理する場合、このバリアントは、ユーザーベース全体にまだリリースされていない新しい機能のコードを表します。

実験を行っている場合と同様、まだ希望のバリアントにユーザーを割り当てられます。フラグを有効にするのは、実験を切り替えるのと同じくシンプルです。

機能フラグとそれがAmplitude Experimentでどのように動作するかについての詳細は、ヘルプセンターの記事を参照してください。

古い実験とフラグを削除する

もはや必要のなくなった実験と機能フラグを削除するのは簡単です。[有効]トグルスイッチの横にあるドロップダウンメニューから[アーカイブ]を選択します。

さらに読む

Amplitude Experimentの詳細と、それがどのようにユーザーの製品エクスペリエンスを最適化するかについての詳細は、ヘルプセンターの記事を参照してください: