このページでは

For AI agents: a documentation index is available at /docs/llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.

概要

Amplitude アカデミー

Amplitude 実験を開始する

Amplitude 実験のワークフローを学び、信頼できる結果を生み出す実験の準備方法を理解すると、バッジを獲得できます。

今すぐ始める

Amplitude実験はフィーチャーフラグのロールアウト、A/Bテスト、Web実験を実行するため、プロダクトの変更をすべてのユーザーに配信する前に検証できます。バリアントを設定し、トラフィックの割合を割り当て、評価するメトリックを選択します。そして、実験にシーケンシャルテストモデルまたはTテストのいずれかを使用して影響を測定させます。

Amplitude実験は3つのユースケースをサポートしています:

  • プロダクトの実験: 実験や A/B テストを実施して新規ユーザーをオンボーディングし、チェックアウト体験におけるフリクションを減らし、新機能を展開することで、主要な KPI を改善できます。
  • プログレッシブな機能提供: ベータテスター、ユーザーの割合、または特定のターゲットユーザー向けに新機能を事前に計画および準備します。
  • 動的な製品内体験: カスタム体験を大規模にデプロイおよび適応させます。

実験には 2 つのカテゴリがあります。

  • 機能の実験: 機能フラグを使用して、機能や A/B オプションを顧客に表示または非表示にします。
  • ウェブ実験: ウェブエディタを使用して、ウェブサイトに直接変更を加えます。

機能フラグと Web エディタの違い

機能実験では、機能フラグを使用して実験的なバリアントを作成します。 フラグは、コードを変更することなく製品のエクスペリエンスを変更できるスイッチです。 フラグを使用してプロダクトで実験を行う場合や、ユーザーに新しい機能を準備して展開する場合などに利用できます。コードはAmplitude 実験 SDKまたはREST APIを使用してAmplitude 実験と通信します。機能フラグの詳細については、「機能フラグ」を参照してください。

Amplitude 実験では、すべての実験において逐次テスト統計モデルがデフォルトですが、代わりにT検定を選択することもできます。

Web 実験では、ビジュアルエディタを使用して実験的なバリアントを作成します。 このエディタは、A/B や多腕バンディットの実験に最適です。ビジュアルエディタを使用すると、コンテンツや要素のプロパティなど、Web要素を選択したり変更したりできます。Web 実験を使用すると、技術レベルの低いユーザーやシステム内の権限が少ないユーザーでも、エンジニアリングリソースなしで実験を作成できます。

ウェブ実験では、ページを使用して実験のバリアントがウェブサイト上のどこに適用されるかを制御します。 ページを使用すると、サイトの関連性のない部分に影響を与えることなく、実験の範囲を特定のURLに限定できます。

機能の可用性

機能実験、ウェブ実験、またはその両方のタイプの実験で利用できる機能の詳細については、「機能実験とウェブ実験の間の違い」を参照してください。

実験の作成

多くの実験プログラムが最初のステップで失敗するのは、実験によって解決できるかもしれない問題を誰も明確に説明できないためです。 なぜ実験を行っているのかを明確でシンプルな言葉で説明できない場合、そこから有益なことを学ぶことは現実的に期待できません。

他のことをする前に、時間をかけて実験のための強力なミッションステートメントを作成してください。 この声明は2つの質問に答えます:問題は何か、そして実験を実行することでどのように問題を解決するのに役立ちますか?この段階であなたが行った努力は、後で報われるでしょう。

ミッション・ステートメントを作成したら、実験を設定する準備が整いました。 実験用の新しいデプロイメントを作成し(または以前に作成したデプロイメントを選択)、使用予定のSDKをインストールします。

仮説を立てる

次に、実験のために作成したミッションステートメントに焦点を当ててください。 ミッション・ステートメントは、実験の仮説の基礎となります。 仮説とは、実験でどの選択肢が正しい可能性が高いかについての予測です。仮説は、実験が成功するか失敗するかを示します。

問題の記述は仮説の最初の部分にすぎません。 仮説には、他に2つの要素があります:提案されたソリューションと予測された結果です。

提案されたソリューションとは、問題を解決するために必要な変更内容を記述したものです。 たとえば、「オンボーディングプロセスの2つのステップを1つに統合する」などです。予測結果とは、実験から期待される結果です。 例えば、「オンボーディングの解約率を20%削減する」といった例です。

仮説文の例を次に示します。

「当社のオンボーディングファネルにおけるユーザーの解約率は、業界平均を大幅に上回っています。 プロダクトデータによると、当社のファネルは複雑すぎる可能性があります。当社は、ファネル内のステップ2と3を統合することでこの問題を解決できると考えています。この変更の結果、オンボーディングのチャーン率は20%減少すると予想しています」

すべての仮説ステートメントは、特に問題定義段階において、お客様のニーズに合わせて独自のものです。 たとえば、「なぜこれほど多くのユーザーがオンボーディングファネルから脱落しているのですか?」という質問は、より本質的に探究的なものかもしれません。 あるいは、「ユーザーの既知の課題を解決するために、いくつかの潜在的なUI変更を考え出しました」など、すでに理解している問題に対するさまざまなソリューションをテストすることによりより興味があるかもしれません。 どちらが一番効果的ですか?」

この基本テンプレートをほとんどの仮説の出発点として使用してください。特に実験を初めて行う場合はそうしてください。

メトリックを選択

仮説文の最後の文に注目してください。 この文には、ユーザーの行動がどのように変化するかを具体的に測定する方法が含まれています。「オンボーディングの解約率は20%減少します」と書かれています。 この測定値は、実験が成功したかどうかを決定します。この数値に到達するか、失敗するかです。

この数字に到達したかどうかを知るには、解約率の低下を測定する方法が必要です。 メトリクスが必要です。Experimentでは、ログに記録したイベントはすべて実験メトリックとして使用できます。上記の実験例では、プロダクトがファネル内のドロップオフを追跡するために使用するイベントをメトリックとして使用します。

バリアントを作成する

新しいオンボーディングプロセスをすべてのユーザーに展開し、その結果を確認することができます。 そうした場合、プロダクト変更がオンボーディングの解約率を改善したかどうかを知ることはできません。また、新しいファネルを導入した後にその割合が低下した場合、その原因は設計上の選択が不十分だったことや偶然の発生、または考慮していなかった何らかの外部からの影響である可能性があります。 その具体的な原因を見つける方法はありません。

このため、実験用に少なくとも 1 つのトリートメント用バリアントを作成する必要があります。処理バリアントとは、一定割合のユーザーに表示する異なるユーザーエクスペリエンスのことです。 このオンボーディングの例では、このバリアントはオンボーディングプロセスの新しい合理化されたバージョンです。 一部のユーザーは新しいバージョンを体験しますが、他のユーザーは現在のプロセス(コントロールと呼ばれます)を継続します。 各バリアントに対するユーザーの反応の違いは、実験の成功を左右します。

バリアントを作成する際は、各バリアントの変更箇所を最小限に抑えるようにしてください。理想的には、各バリアントには単一の変更が含まれています。 1 つの変更で、どの変更が肯定的な結果をもたらすかを把握できます。 また、バリアントが互いに著しく異なることを確認してください。 明確なバリエーションは、各セグメントのユーザーが異なる体験をしていることを裏付け、あなたの変更がセグメント間の行動に違いをもたらしていることを確認します。

バリアントを受け取る人を決定する

次に、バケット設定単位を定義します。この単位は、どのグループの人々が同じバリアントを見るかを決定します。 最も一般的なバケット単位は「ユーザー」です。 ただし、B2B ビジネスを展開している場合やコラボレーション機能を使用している場合は、「組織」または company_id などのバケット単位を使用することで、同じ組織内のすべてのユーザーが同じバリアントを体験できるようにすることをお勧めします。バケットの設定の一貫性は、ユーザーが同僚の隣に座っている場合に、異なるユーザーインターフェイスによって引き起こされる製品関連の混乱を軽減するのに役立ちます。 company_idでバケット化するもう一つの理由は、カスタマーサポートチームの負担を軽減するためです。サポートチームは、どのアカウントでどの機能が有効になっているかをより簡単に追跡できます。 いずれにしても、推論を確実にするために、選択したバケット単位に対して安定ユニット処理値仮定(SUTVA)が成り立つことを確認してください。

組織がAccountsアドオンを購入している場合は、ユーザーではなくグループに対してバケット化と分析を実行できます。

ユーザーの割り当て

バリアントを作成したあと、バリアントを受信するユーザーの数を決定してください。 実験をユーザーベース全体に展開することも、ユーザーベースの一部に展開することもできます。 実験でコントロールエクスペリエンスを受け取るユーザーの数と、バリアントを受け取るユーザーの数を指定します。 実験に含めるか除外する特定のユーザーセグメントを定義できます。また、個々のユーザーやデバイスIDに対して特定の体験を選択することもできます。

実験を開始する

これで、ユーザーに実験を展開する準備が整いました。 「実験を開始」を選択すると、実験が開始されます。

結果を分析する

実験が開始された後は、いつでも結果を生成して表示できます。 実験は、実験が統計的有意性を達成した時点を示します。これは、実験が十分な結果とデータを得た時点で、収集している情報が正確であることを信頼できる時点です。 実験は収集したすべてのデータを提供するため、結果を分析・解釈することができます。

実験の設計方法、展開方法、学習方法の詳細については、実験ワークフローに関するこれらの記事を参照してください。

チーム間のコミュニケーションを改善し、実験プロセスを合理化するために、実験概要の使用を検討してください。 実験概要は、透明性を高め、実験目標を調整するのに役立ちます。 実験概要とその使用方法について詳しくは、このブログをご覧ください。

ウェブサイトコンバージョンエージェントは、ガイド付き AI ワークフローを通じて、インパクトの高いページの特定、実験戦略の生成、実験の下書き作成を支援できます。

これは役に立ちましたか?