実験の設計と分析

概要

GitLab では、私たちの素晴らしい開発チームによって社内で構築された、独自の実験アプローチを採用しています。このアプローチを使用する理由は、ユーザーと顧客のプライバシーを保護するというコミットメントを守るためです。このカスタムアプローチは、より一般的に使われるサードパーティの実験ツールでは経験しないいくつかの課題につながります。この現実から、GitLab での実験は高い意図性と先見の明をもって取り組まれなければなりません。このハンドブックページの目的は、よくあるエラーを避けてベストプラクティスを定義するために、実験に関するいくつかのガイドラインを作成することです。

実験から学ぶ能力を維持しつつ、私たちの速度を向上させるため、GitLab Growth ステージ (Product Analysis グループを含む) は、実験を設計し分析するための新しいフレームワークを採用しています。このフレームワークは、データサイエンティスト Danielle Nelson の研究を基にしています。

GitLab のすべてのものと同様、このページとフレームワークの実装方法はドラフト中であり、時間とともにイテレーションしていきます。

フレームワーク

この実験フレームワークは、gitlab_dotcom_experiment_subjects テーブルを使用して固有の識別子をホストしていた、以前のバージョンの実験フレームワークから派生したものです。snowplow_gitlab_events_experiment_contexts_all がこのテーブルに代わって、すべての固有の識別子のランディングプレースとなります。このフレームワークは、ユーザーを識別できるデータの追跡を避けるために擬名化されたデータを使用することで、効率性を向上させ、ユーザープライバシーへのコミットメントを維持するために作成されました。

GitLab で現在使用されている実験フレームワークは、gitlab-experiment-gem または GLEX と呼ばれます。GitLab では、A/B/n テストとして実験を実行し、実験が生成するデータをレビューします。そのデータから、最もパフォーマンスの良いコードパスを判断し、それを新しいデフォルトのコードパスとして昇格させるか、元のコードパスに戻します。GitLab 内部でこの gem をどのように使用しているか興味がある方は、Experiment Guide ドキュメントをお読みください。この実験フレームワークは、フロントエンドイベントまたは私たちのデータコレクター Snowplow によって作成されたイベントに大きく依存しています。

この gem の動作について議論する際、experiment、context、control、candidate、variant のような用語を使います。これらの用語をより理解しやすくするために定義しておくのは価値があります。これらは社内全体で使用される普遍的な用語です。

• experiment は、時には実行したり実行しなかったりするコードパスの逸脱です。
• contexts は、実験で提供する一貫した体験を識別するために使用されます。
• control はデフォルト、つまり「オリジナル」のコードパスです。
• candidate は、実験的なコードパスが 1 つあることを定義します。
• variant(s) は、実験的なコードパスが複数存在する場合に使用されます。
• behaviors は、実験の可能なすべてのコードパスを参照するために使用されます。

このドキュメントでは、Snowplow イベント構造に固有の重要な用語を詳しく説明します。

Contexts

これは、実験を特定の名前空間やプロジェクトに結びつけるために使用される有用な識別子を含む JSON カラムです。これらの識別子は、KPI への実験の影響を測定するために使用され、分析のためにすべての実験で必要です。以前のバージョンの実験分析では、このカラムに保存された情報を活用するために SQL を介してこのデータを手動で解析する必要がありましたが、現在の experiment_contexts_all テーブルでは、このデータがすでに解析されており、使いやすくなっています。

Context_keys は、実験分析で定義されたさまざまな機能および/またはステージに参加する固有のユーザー/プロジェクト/名前空間を判断するために、実験分析で使用されます。Context_keys は、実験で必要なものに応じて、さまざまな識別子 (ユーザー、名前空間、プロジェクト、またはプロジェクトごとのユーザーまたは名前空間ごとのユーザーの組み合わせ) に「スティッキー」にすることができます。

例:

• 名前空間やプロジェクトに関係なく、実験の結果として特定の機能を採用したユーザーが何人いるかを特定する場合、context_key をユーザーにスティッキーに割り当てる (1 context key = 1 ユーザー)。
• 各ステージに参加したユーザー数に関係なく、実験の結果として採用されたステージ数を特定する場合、context_key を名前空間にスティッキーに割り当てる (1 context key = 1 名前空間)。
• 実験の結果として、名前空間内の特定のユーザーが特定の機能を採用した数を特定する場合、context_key をユーザーごと、名前空間ごとにスティッキーに割り当てる (1 context key = 名前空間ごとの 1 ユーザー)。これにより、複数の名前空間に属するユーザーが、その属するすべての名前空間に対して機能および/またはステージの採用がカウントされることを防ぎます。

Variant

Variant は、従来の A/B テストを実行する場合、candidate または control のいずれかとして定義できます。多変量実験を実行する場合、各 variant には variant ごとに固有の識別子が必要であり、実験のベースラインを設定するための control も必要です。

イベント要件

GLEX 実験の成功した実装には、実験を成功裏に分析できるように、イベントが特定のデータを含む必要があります。以下は、分析されるカラムとそれぞれの用途を概説した表です。

実験のデプロイにおける役割と責任の分担

実験の作成、開始、分析に関わる主な役割は 3 つあります。以下の表は、GitLab 実験の成功した実装のために関わる必要のあるさまざまな役割を概説しています。

プロダクトマネージャー向け実験ガイド

明確に定義された仮説の作成

仮説とは何か？

仮説とは、観察に対する提案された説明または解決策として定義されます。実験の世界では、仮説を実験を実行する前に作成する予測として捉え、「この実験から何を学びたいのか？」という質問に答えるのに役立ちます。

仮説の書き方

完全な仮説には 3 つの部分があります。仮説の目標は、実装しようとしている変更とその変更の効果を定義することです。仮説を書き出すには、このシンプルな 3 部構成の公式を使えます:

「もし ____ ならば、____ であろう、なぜなら ____ だからである。」

公式の もし の部分は、望ましい結果または成果を生み出すために修正、追加、または削除できる変数に関連します。たとえば、「もし追加の CTA を追加するならば」または「もしこのページを削除するならば」。

この公式の ならば の部分は、上記の変更された変数の結果として起こるであろう望ましい結果に関連します。たとえば、「もし追加の CTA を追加するならば、ならば後続のページへのビューが増えるだろう」。

公式の最後の部分または なぜなら の部分は、予想される結果の背後にある理由に関連します。これは、何が変化を引き起こしたかを説明する研究、逸話、または観察です。たとえば、「もし追加の CTA を追加するならば、後続のページへのビューが増えるだろう、なぜならより多くのユーザーをこのページに直接誘導することになるからである」。

成功メトリクス

成功メトリクスについての考慮事項

実験の成功を判断するために使用するメトリクスを定義することから始めます。定義されるさまざまなタイプのメトリクスは以下で詳しく説明していますが、実験の概要を作成する思考プロセスを経る際に考慮すべき追加の要素は次のとおりです:

1. コンバージョンメトリクスよりもターゲットメトリクスを選択する理由

   • 例: トラフィック/ボリュームが少ないと、コンバージョンメトリクスを使用すれば私たちの速度が急停止することになり、有意性に達するために実験を 9 か月間実行する必要がある
   • 例: 実験はページへのトラフィックを促進することを意図しており、必ずしもコンバージョンに影響を与えるためではない

2. 並行する実験の衝突 (またはその欠如) について行っている前提 (2 つ以上の実験が同じユーザー集団をターゲットにしている場合)

   • 例: 並行する実験はこの実験のターゲットメトリクスに重大な影響を与えないと仮定する

3. 与えられたメトリクス、実験の順序、実験設計で進めることによって私たちが想定するリスク

   • 例: クリックが増えても必ずしもコンバージョンが増えるとは限らず、下流のメトリクスにマイナスの影響を与える可能性がある

4. なぜそれらのリスクに対する許容度があるのか

   • 例: ビジネスを動かし続け、実験を継続的にイテレートできるようにしたい

5. コンバージョンメトリクスを確認するために、長期的なフォローアップを行うかどうか (実験の衝突により、長期的なフォローアップ測定が不可能な場合もある)

   • 例: 2 か月後に control と candidate のコンバージョンを確認するためにフォローアップを行う
   • 例: 以下の実験が衝突するため、コンバージョンを確認するためのフォローアップはできない

成功メトリクスの特定方法

実験のメトリクスの選択をガイドするためのいくつかの質問を以下に示します。1 つのターゲット KPI、つまりこの実験で勝者を宣言するために使用するもの、および分析に含めたい他のセカンダリ KPI を定義することをお勧めします:

1. 答えようとしているビジネスの質問は何ですか？
2. この実験の望ましい効果は何ですか？ (クリック、ページビュー、ステージ採用、または有料コンバージョンの増加などのより多くのエンゲージメント)
3. 実験で導入されている variant は何か、また予想される動作は何ですか？
4. control グループに対して variant に固有のイベントまたはイベントのシーケンスがありますか？

注意: Product Analysis は、分析を進める前により良いアラインメントのために、実験のイベントとメトリクスの定義の支援を提供できます

成功メトリクスの定義

実験に対して定義できる 3 つの異なる種類のメトリクスがあります:

1. 主要メトリクス (Primary Metrics)

これらは実験によって影響を受けると期待される主な KPI またはメトリクスです。通常、これらのメトリクスは統計的有意性を使用して実験の成功または失敗を定義するために使用されます - これらのメトリクスが統計的有意性に達するのにどれくらいかかるかを特定するために、Product Analysis チームに必ず相談してください。

例:

• トライアルに影響する実験を開始する場合、この実験から作成されたトライアル数を主要メトリクスとして使用できます
• コンバージョンに影響する実験を開始する場合、この実験から生成されたコンバージョン数を主要メトリクスとして使用できます

2. セカンダリメトリクス (Secondary Metrics)

これらは、実験によって影響を受ける可能性のあるメトリクスですが、実験の成功または失敗を宣言するために使用される主なメトリクスではないものです。

例:

• 実験が具体的にトライアル数を見ている場合、トライアルの増加が理論的にコンバージョン数に影響を与えるため、コンバージョンをセカンダリメトリクスとして配置できます。
• 実験が特定のステージの採用をターゲットにしている場合、ステージの採用の増加が追加のステージ採用につながる可能性があるため、Stages per Organization をセカンダリメトリクスとして配置できます。

3. 先行指標 (Leading Indicators)

先行指標は、variant 間のフロントエンドイベントの量に基づいた、実験のパフォーマンスの方向性を示す決定要因です

例:

• 実験が新しいランディングページへの訪問を見ている場合、ページビューを先行指標として配置できます
• 実験がプロダクトに追加される新しい CTA を見ている場合、ボタンクリックを先行指標として配置できます

実験タイプ

以下で説明する実験から、どの種類の実験を実施したいかを特定してください。実験から望む結果を決定するのに役立つアンケートも含まれています: 私たちの実験設計と分析フレームワークでは、2 つの異なる「タイプ」の実験を活用しています: 真のランダム化比較試験 (True RCT) と 疑似ランダム化比較試験 (Pseudo-RCT) です。2 つのタイプは統計的厳密性 (p 値の解釈を含む) の点で異なり、それが必要なサンプルサイズと実験期間に影響します。

True RCT は統計的確実性のために最適化されており、pseudo-RCT は実験速度のために最適化されています。

真のランダム化比較試験 (True RCT)

True RCT は最も統計的に厳密な実験で、適切に設計され実行されれば因果推論につながります。言い換えれば、実験がメトリクスの変化を「引き起こした」と実際に言うことができます。True RCT は古典的な「A/B/n テスト」です。残念ながら、これらのタイプの実験と学びの確実性には代償があります: 大きなサンプルサイズと実験期間が必要になる傾向があります。効果サイズ (検出するのに関連すると思われるメトリクスの最小変化) が小さい場合 (例: 1% の変化を検出したい)、メトリクスがあまり一般的でない場合 (例: コンバージョン率が低い)、またはメトリクスの分散が大きい場合 (つまり「ノイジーな」メトリクス) は、はるかに大きなサンプルサイズが必要です。さらに、実験が衝突しないように特に注意する必要があります。

True RCT は、業界標準の統計的有意水準 p <= 0.05 と検出力 0.8 で開発・評価されます。

• p <= 0.05: 結果は統計的に有意
  • 例: variant のランディングページは、クリック率で 10% の有意な増加を示しました。
• p > 0.05: 結果は統計的に有意ではない
  • 例: control と variant のランディングページ間のクリック率の違いは有意ではありませんでした。

疑似ランダム化比較試験 (Pseudo-RCT)

Pseudo-RCT は True RCT よりも統計的に厳密ではなく、方向的な学びにつながります。言い換えれば、実験がメトリクスの変化を「引き起こした」と言うことはできませんが、メトリクスに「方向的な影響を与えた」と言うことができます。Pseudo-RCT は、より大きなサンプルサイズと期間を必要とせずに True RCT の精神を持ち合わせています。そのため、結果が実験ではなくランダムな偶然によるものである高いリスクを伴います。

Pseudo-RCT はあまり厳密でないため、より緩い p 値の解釈に基づいて評価し、結果を理解し伝えるために異なる言語を使用します。これらの測定に使用される言語は、私たちの自信を過大評価しないように非常に意図的である必要があります。これは、不確実性と統計的有意性のレベルが誤解される可能性があるため、パーセンテージ変化 (例: 10% の増加) を伝えないようにすべきだということです。さらに、p 値を含める (または信頼レベルを記す) ことで、誤解を避けることができます。

• p <= 0.05: 実験は**「影響を与えた」**
  • 例: variant のランディングページは、クリック率が 40% から 44% に上昇しました (p=0.04)。
• p > 0.05 かつ p < 0.2: 実験は**「方向的な影響を与えた」** (または 「影響を与えた可能性がある」)
  • 例: variant のランディングページは、クリック率が 40% から 44% に方向的な上昇を示しました (p=0.11)。

実験タイプの選択についての考慮事項

どのタイプの実験を実行するかを選択するのは、必ずしも単純または容易ではありません。その決定を導くためのいくつかの質問は次のとおりです:

• この実験がメトリクスの変化を引き起こしたことについて、どれくらい確信を持つ必要がありますか？ 方向的な学びで十分ですか？
  • メトリクスがビジネスにとって重要で、実験が変化を引き起こしたという確信が必要な場合は、True RCT を実行する必要があります。
• どれくらいの大きさの影響を期待し、気にしますか？ メトリクスが 1% 動くか、それとも 10% 変化することだけが本当に重要ですか？
  • 小さな影響を検出する必要がある場合は、より大きなサンプルサイズが必要になります。
• 気にしているメトリクスはどれくらい一般的および/または変動しやすいですか？
  • メトリクスがあまり一般的でないか、より変動しやすい場合、より大きなサンプルサイズが必要になります。
  • メトリクスが非常に変動しやすい場合、pseudo-RCT を実行すると影響を検出するのに苦労する可能性があります。
• 他にどのような実験が実行中、または実行待ちですか？ この実験を長期間実行することで、別のより高優先度の実験を開始する能力が損なわれますか？ 現在実行中で、この実験と衝突する別の実験はありますか？
  • 結果に確信が必要な場合は、実験をより長期間実行する必要がある可能性があり、かつ実験の相互作用に非常に注意する必要があります。
• 結果の確実性のレベルに基づいて、何か異なることをしますか？ 実験がメトリクスの変化を引き起こしたと知っている場合と、方向的に影響を与えたと知っている場合では、異なる決定をしますか？
  • 因果的または方向的な影響に関係なく同じ決定をする場合、pseudo-RCT を実行する可能性が高いです。

どのタイプの実験を実行するかを選択するためのガイドを引き続き構築していきます。

次に取るべきステップ

1. メトリクスを定義した後、Product Analysis チームおよびエンジニアと協力して、最適な追跡方法と追跡が必要なイベントを特定します。

   • フロントエンドイベントを追跡していますか？ バックエンドイベント？
   • ファネル分析を行っていますか？ もしそうなら、追跡しているイベントの順序はありますか？
   • コンバージョンイベント (または成功したコンバージョンと見なすもの) は何ですか？
   • コンバージョン率を追跡している場合、この計算の分子と分母が何になるかを指定してください。
     • D7、D14、D30 コンバージョンのように、時間がコンバージョン率に組み込まれるべきかを指定してください。

2. Product Analysis チームの Issue を、「Experiment Analysis Request」テンプレートを使って作成します。

3. 実験がステージングでデータを持つようになったら (プロダクションに開始する前)、Product Analysis チームに知らせて、データが流れているか確認できるようにしてください。 Experiment Data Validation ダッシュボードを使用してデータを確認することもできます。

4. 実験結果が分析され variant が開始されたら、データウェアハウスストレージを最大化するために結論を出した実験を一時停止できるよう、Engineering に知らせてください。

エンジニア向け実験ガイド

1. プロダクトマネージャーと協力して、イベント名、イベントタイプ、データが収集されることが期待される場所をリストアップします。以下のイベント定義表を使用して、イベント定義をフォーマットしてください。

   アクション	ファネル	レベル	ソース	説明
   assignment	1	BE	auto	実験が評価されるたび。固有のキーを使用して体験を取得するか、合計カウントとしてレビューします。固有のキーでグループ化して、経時的な変化や後続の評価を確認します。実験はユーザーにスティッキーです。
   focus_form	2	FE	link	focus_form コンテキストを伴う標準イベント。
   change_form	3	FE	link	change_form コンテキストを伴う標準イベント。
   submit_form	4	FE	link	submit_form コンテキストを伴う標準イベント。
   create_group	5	BE	link	後続のオンボーディングステップでグループが作成されたとき

2. Product Analytics に割り当てられたメインの実験 Issue に、トラッキングおよび関連 Issue をリンクします

3. 実験がステージングまたはプロダクションで利用可能になったとき、現在どのくらいの割合 (フェーズごとまたはユーザー集団の特定の割合でロールアウトする場合) に設定されているかを、すべての利害関係者に知らせてください。

アナリスト向け実験ガイド

1. プロダクトマネージャーに対して、追跡することを推奨するメトリクスと、実験のパラメーターに基づいて考慮する必要があるイベント追跡のニュアンスについてガイダンスを提供します。

2. プロダクトマネージャーおよびエンジニアリングと協力して、分析に最も意味のあるイベントと、実験の分析に役立つ識別子を特定します。

3. Product Analysis チームは、結果が統計的に有意になるためにデータを収集する必要がある期間を判断するのに役立ちます。実験の期間を判断するのに役立つ前もっての計算のリストは次のとおりです:

   • プロダクトマネージャーから提供された基準に基づいて、推定トラフィックまたはオーディエンスを確認
   • このツールを使用してサンプルサイズを計算
   • 実験タイプに相関する z スコアを確認し、z スコアとベースラインコンバージョンに基づいてサンプルサイズを計算
   • 効果サイズを計算: 進行中

4. ステージングデータでモックダッシュボードを作成します。これにより、プロダクションへロールアウトされる前に、分析から現実的に期待されるものをプロダクトマネージャーに示すのに役立ち、何を調整するかを決めるのに役立ちます。

   • ダッシュボードには、実験チケットへのリンクと、実験の詳細に不慣れな人にも理解しやすいようにイベントの簡単な定義を必ず含めてください。
   • どのイベントが流れ込んでいるか、正しいコンテキストを収集しているかを確認し、データ収集の異常を指摘します。
   • 過去の実験分析の例:
     • Jobs To Be Done Experiment
     • SaaS Trial Onboarding Experiment

プロダクションデータが流れ始めたら、ステージングデータではなくプロダクションデータを参照するようにデータソースを切り替えてください。メトリクスがフルサンプルサイズまで成熟するのを注視し、不一致や予期しない動作をプロダクトマネージャーに指摘してください。

代表的な結果を保証するために、すべての実験分析にわたって適用する必要があるいくつかの標準フィルターがあります。Standard Experiment Dashboard 以外で独自のダッシュボードを作成している場合は、これらのフィルターが分析に適用されていることを確認してください:

• すべての名前空間および/またはプロジェクトは、標準の Growth 名前空間定義内に該当する必要があります
• growth_data_namespaces スニペットを使用するのは、すでにフィルタリングされているデータを取り込む良い方法です
• 割り当て時に有料である名前空間を除外する (これは Growth 固有の実験用で、これらの実験は通常、無料ユーザーをターゲットにします)
• 分析に含まれるデータは、実験が 50/50 にロールアウトされ、母集団が control と variant の間で均等に分布した後である必要があります。
• プロジェクトを見る場合、Learn GitLab プロジェクトは自動生成されたプロジェクトであるため除外してください

variant のサンプルサイズを GitLab ユーザーの総人口と比較して、結果が合意された有意性/信頼レベルに達するのに必要な適切なサンプルサイズを特定してください。

関連するインサイトをプロダクトマネージャーと共有し、実施する必要のある実験後の分析について話し合ってください。

一般的な実験エラー

このセクションでは、実験の作成、デプロイ、分析に関わるすべての関係者によって行われる最も一般的なエラーをいくつかレビューします。これらのエラーには注意してください。これらのいくつかは実験の全体的な結果に影響を与える可能性があります。

タイプ 1 エラーまたはタイプ 2 エラー

• タイプ 1 エラーは、通常、仮説が null の場合に、テストが正または負の影響を与えると呼ぶときに発生します。
• タイプ 2 エラーは、通常、1 つのバリエーションが他のものと実質的に異なる場合に、null 仮説を受け入れるときに発生します。
• 実験が成功か失敗かを判断する前に、実験を有意性に達するのに必要な割り当てられた時間実行することを忘れないでください。たとえば、実験がコンバージョンに影響を与えているという有望な結果を示し始め、これを早まって成功として報告し、実験を実行するために割り当てられた時間の終了までに、control と variant の間に真の違いがなかった場合などです。

実験開始後のイベントの欠落

• このタイプのエラーは、プロダクト、エンジニアリング、またはアナリスト間にコミュニケーションがないときに発生します。イベントが欠落しているか、実験のパフォーマンスを追跡するために必要な識別子が含まれていません。
• 実験に必要なすべてのイベントが文書化され、チームの他のメンバーに伝えられていることを確認してください。

実験結果の相互汚染

• データの相互汚染は、プロダクトの同じエリアで実行されている実験が多すぎる場合、および/または同じユーザー集団に表示されている場合に発生する可能性があります。
• 任意の時点で実行されている実験の数を必ず確認してください。

追加のリソース

ハンドブックと GitLab ドキュメントの全体で実験に関する追加のリソースを見つけることができます。 チェックするべきページがいくつかあります:

• Growth が実験を開始する方法
• 実験を実行する Growth Engineering ガイド
• GitLab Experiment Guide

ページのソースコードを見る - ページの編集 - please contribute.