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 Exposure イベントです。 Amplitudeはこの設定をそのまま残すことを推奨していますが、カスタム露出イベントを指定することもできます。
- プロキシ露出イベント: フィーチャー実験の場合、プロキシ露出イベントは、そのイベントの履歴データに基づいて実験の期間を推定するために使用されるプレースホルダです。デフォルトは「任意のアクティブイベント」です。記録されたイベントはすべてプロキシとして指定できます。
- 露出設定のカスタム化:露出設定をさらにカスタマイズするかどうかを選択します:
- アトリビューション: 露出イベントがユーザーによってトリガーされた最初のインスタンスでのみ有効になるか、任意のインスタンスで有効になるかを選択します。
- ウィンドウ: 実験がイベントの特定の期間内に開始されるかどうかを選択します。
統計の設定
統計設定は、Amplitudeが実験結果をどのように分析および表示するかを決定する構成可能な設定です。 これらの環境設定により、チームは次のようなパラメータを選択できます。
統計設定は実験のどの段階でも変更できます。 これらは実験終了後の最終分析に最も役立ちます。
この記事は、ヘルプセンターの実験から学ぶことに関する記事に直接続くものです。 まだその記事を読んでいない場合は、ここへ進む前に読んでください。
CUPED
既存のデータを使用した制御実験(CUPEDとも呼ばれます)は、Amplitude実験の分散を減らすためのオプションの統計手法です。 CUPEDをオンにすると、Amplitude実験はユーザーセグメントごとに異なる可能性のある処置効果を考慮します。CUPEDがすべての実験にとって最適な選択肢というわけではありません。たとえば、新規ユーザーのみをターゲットにしている場合はCUPEDを避けてください。
ランダムなバケット設定プロセスは、各バリアントに不均衡なユーザーグループを配信する可能性があります。 このアンバランスは暴露前のバイアスであり、CUPEDはこれに対処しています。 CUPEDを使用しない場合、実験では暴露前のバイアスが残ります。このため、CUPEDを使用する場合と使用しない場合に同じ実験を実行した場合に、バリアントごとの平均値に違いがあることに気付くことがあります。
より技術的な説明については、こちらの詳細なブログ記事を参照してください。
CUPEDが実験結果に与える影響についての詳細は、このブログを参照してください。
ボンフェローニ補正
Amplitude実験では、ボンフェローニ補正を使用して、複数仮説検定で発生する可能性のある問題に対処します。 信頼できる統計手法ですが、この手法をすべての場合に使用したいとは限りません。その一例として、結果をボンフェローニ法をサポートしていない内部システムによって生成された結果と比較したい場合があります。 この場合、また偽陽性率が高いことを受け入れる場合は、ボンフェローニ補正をオフにしてください。
統計的手法
使用する統計方法を選択します。
- 逐次検定: 固定されたサンプルサイズでのみ分析するのではなく、データが入手されるたびに継続的に結果を分析する統計手法です。このアプローチにより、チームは偽陽性のリスクを増大させることなく実験結果を継続的にレビューできます。 この方法はデータを繰り返し参照した場合に修正を行うため、効果が強い場合に迅速な意思決定を行うのに役立ちます。 これはバイアスを避けるために、慎重に設定する必要があります。詳細については、逐次テストを参照してください。
- T検定:対照群と治療群などの2つのグループの平均を比較して、その差が統計的に有意かどうかを判断する従来の統計的検定です。 この方法では、正規分布データと固定サンプルサイズを想定しています。t 検定はシンプルで広く理解されていますが、結果を継続的に確認したり、より複雑な結果分布を処理したりする場合、柔軟性が低くなります。 詳細については、T 検定を参照してください。
- ベイズ:あるバリアントが別のバリアントよりもパフォーマンスを発揮する確率を計算することによって、グループを比較する統計手法です。p値や固定仮説検定に依存する従来の方法とは異なり、ベイズ統計はチームの意思決定方法と一致する直接的な確率推定を提供します。 ベイズ手法は、実験のパフォーマンスについて継続的なインサイトを得たい場合に優れています。これらは、事前の知識を取り入れたり、より小さなサンプルサイズで意思決定を下したり、あるいは「このバリアントが成功する確率はどのくらいですか?」といったビジネス上の質問に直接答える確率の記述が必要な場合に役立ちます。詳細については、ベイズ統計を参照してください。
- トンプソン・サンプリング: より優れたパフォーマンスを発揮するように見えるバリアントにより多くのトラフィックを動的に割り当てるベイジアン・バンディット・アプローチです。 実験が終了するまで待つのではなく、トンプソンサンプリングはリアルタイムで探査と活用をバランスよく行います。このアプローチは、より多くのユーザーを有望なバリアントに徐々に誘導することでユーザー体験を向上させます。 この方法は古典的なp値を提供しませんが、事後確率に依存するため、適応的な意思決定が必要な場合に役立ちます。
信頼レベル
信頼レベルは、繰り返し展開しても実験で同じ結果が得られるという点について、実験がどの程度の信頼度を持っているかを測定します。デフォルトの信頼水準は95%なので、5%の確率で、実際には統計的に有意でない結果を統計的に有意であると解釈してしまう可能性があります。実験の信頼レベルを下げると、実験が統計的有意性に達する可能性が高くなりますが、偽陽性の可能性も高くなります。80% を下回らないでください。実験結果がもはや信頼できない可能性があるためです。
バケットオプション
実験でバケッティングがどのように機能するかを指定します。次のことを指定できます。
- 評価モード:Amplitudeが実験をAmplitudeサーバー上でリモートで評価するか、ユーザー自身のマシン上でローカルで評価するかを選択します。デフォルトでは、Amplitudeは実験をリモートで評価します。詳細については、パフォーマンスとキャッシュを参照してください。
- スティッキバケット:ロールアウトまたはターゲティング基準が変更された場合でも、割り当て後に同じバリアントをユーザーに提供するかどうかを指定します。スティッキ バケット設定が有効になっている場合、ターゲティング基準が変更された場合でもAmplitudeはユーザーを再バケット設定しません。 デフォルトはオフです。詳細については、スティッキーバケットを参照してください。
- バケティング ソルト: ハッシュ処理の一部として使用される文字列値です。 バケティングソルトは、ユーザーを決定論的に実験バリアントに割り当てます。バケティングソルトとユーザーIDや実験キーなどの識別子を組み合わせることで、Experimentはランダムに見えるが繰り返し可能なハッシュを生成し、各ユーザーをセッション間で同じバリアントに配置します。バケティングソルトを変更すると、割り当てが再編成され、その実験に参加するユーザーも再びランダム化されます。
これは役に立ちましたか?