launchdarkly-experiment-setup

LaunchDarkly の実験セットアップ

LaunchDarkly で実験をセットアップして実行する手順を案内するスキルを使用しています。実験を設計し、適切なメトリクス、トリートメント、フラグ設定を使って作成し、データ収集を開始し、必要に応じて反復の間に設計を変更し、勝者を決めて終了するのが目的です。ユーザーの承認を得るまでは、メトリクスや実験を作成しないでください。ユーザーが開始を指示するまでは、反復を開始しないでください。また、ユーザーから依頼されない限り、フラグを変更しないでください。必要な項目、提案、ラベルについては「作成前に」を参照してください。情報収集と承認についてはワークフローを、イベントの確認についてはステップ 1 を、開始についてはステップ 4 を参照してください。

前提条件

このスキルを使用するには、環境でリモートホスト型の LaunchDarkly MCP サーバーが設定されている必要があります。

必須の MCP ツール：

• create-experiment — 仮説、メトリクス、トリートメント、フラグ設定を含む新しい実験を、初回の反復とともに作成します。
• start-experiment-iteration — 実験の現在のドラフト反復でデータ収集を開始します。
• get-experiment — 実験のステータス、トリートメント、メトリクス、現在の反復を確認します。

任意の MCP ツール：

• list-experiments — プロジェクト内の既存の実験を一覧表示します。
• update-experiment — 実験または現在の反復のフィールドを更新します。mutableFieldsByStatus に従うため、編集可能な内容は反復が not_started、running、stopped のどの状態にあるかによって異なります。拒否された入力は skipped に返されます。
• save-and-start-experiment-iteration — 実行中の実験でロックされたフィールドを変更する場合に、API が推奨する方法です。現在の反復を停止し、指定されたフィールド更新を適用した新しいドラフトを作成して、1 回の呼び出しで開始します。
• stop-experiment-iteration — 実行中の反復を停止します。勝者を宣言する必要があります。winningTreatmentId（および winningReason）を渡してください。どのバリエーションも上回らなかった場合は、ベースライン／コントロールを勝者に選択します。
• list-metrics、create-metric、list-metric-events — 実験で参照するメトリクスを管理します。
• get-flag — 環境内の 1 つのフラグのターゲティングを読み取ります。フラグがオンかどうか、ルールが配信するバリエーション、オフ時のバリエーション、およびそのルールがパーセンテージロールアウトかどうかを確認できます。
• list-flags — プロジェクト内のフラグを名前またはキーで検索します。
• create-flag — プロジェクトにフィーチャーフラグを作成します。オンにするまでは、すべての環境でオフです。
• get-flag-status-across-envs — 各環境におけるフラグのステータス（new、active、launched、inactive）を読み取ります。
• search-contexts — 種類ごとに環境内の保存済みコンテキストを検索し、どのコンテキストの種類が使用されているかを確認します。

コアコンセプト

実験とは？

LaunchDarkly の実験では、フィーチャーフラグのバリエーションが主要なメトリクスに与える影響を測定します。実験は次の要素で構成されます。

• トリートメント：比較対象となるフラグのバリエーション（コントロール対テスト）です。各トリートメントには allocationPercent があり、すべてのトリートメントの値の合計が 100 になるようにします。
• メトリクス：測定する項目（コンバージョン率、レイテンシ、売上など）です。プライマリメトリクスを 1 つ指定する必要があります。
• フラグ設定：実験を動かすターゲティングルールの flagKey、ruleId、flagConfigVersion です。
• 反復：1 回のデータ収集期間です。not_started 状態で作成され、開始すると running に、終了すると stopped に遷移します。
• ホールドアウト（任意）：ベースライン測定のために実験から除外される、プロジェクトレベルのユーザーグループ（holdoutId）です。

実験のライフサイクル

1. 最初のイテレーションとともに実験を作成します（create-experiment）。
2. データ収集を開始するには、イテレーションを開始します（start-experiment-iteration）。ユーザーが明示的に開始を指示した後にのみ実行してください。
3. データの蓄積に伴い、結果を監視します（get-experiment）。
4. 必要に応じて、実験の途中で設計を変更します。save-and-start-experiment-iteration を呼び出して、treatments、metrics、methodology などの固定フィールドを変更します。この呼び出しは現在のイテレーションを停止し、変更を反映した新しいドラフトを作成して開始します。データ収集が始まるため、ユーザーが明示的に開始を指示した後にのみ実行してください。
5. 勝者が決まったとき、または明確な判断ができたときに、イテレーションを停止します（stop-experiment-iteration）。
6. 勝者となったバリエーションをリリースします。

基本原則

1. メトリクスを最初に：実験を作成する前に、参照するメトリクスが存在することを確認してください。
2. 明確な仮説：各イテレーションには、ユーザーから提供された hypothesis 文字列が必要です。「作成する前に」を参照してください。
3. 適切な対照群：baseline: true にする処置は、必ず1つだけにしてください。
4. 十分なサンプルサイズ：判断を裏付けられるだけの期間、イテレーションを実行してください。「ステップ7」を参照してください。
5. 一度に1つの変更：原因を明確に特定できるよう、1つの実験では1つの変数をテストしてください。

作成を始める前に

次の3項目はユーザーから提供してもらう必要があります。決して補完しないでください。

• フラグとバリエーション：テストするフラグと、実験に含めるそのバリエーション。
• 仮説：何がどの程度改善すると期待しているか（分かる場合）。
• 主要指標：結果を判定する単一の指標またはファネル。

この3項目のいずれかが不足している場合は、ユーザーから提供されるまで空欄にしておいてください。これらは情報収集メッセージに記載します。ワークフローを参照してください。ユーザーがフラグを指定したら、ステップ2に進んでください。

コントロールバリエーション：どのバリエーションをベースラインにするか（baseline: true）。ユーザーが指定した場合は、それを使用してください。指定がない場合：

• フラグが新規作成されたばかりの場合、対象ルールで割合によるロールアウトを行っている場合、またはフラグがオフで get-flag-status-across-envs がその環境を inactive と報告している場合は、ユーザーに尋ねて空欄にしてください。フラグが新規作成されたばかりとは、この会話中に作成した場合、または get-flag-status-across-envs がその環境を new と報告した場合です。フラグは作成から7日未満で、その環境ではまだ一度も評価されていません。割合によるロールアウトとは、単一のバリエーションを提供するのではなく、トラフィックを複数のバリエーションに分割する対象ルールです。どのルールかは get-flag で確認できます。inactive は、フラグが少なくとも7日間評価されていないことを意味するため、現在は誰にもオフのバリエーションが提供されていません。
• それ以外の場合は、候補を提案してください。フラグがオンの場合は、対象ルールで現在提供されているバリエーションを提案してください。フラグがオフの場合は、オフのバリエーションを提案してください。

ランダム化単位：実験でランダム化するコンテキストの種類です。ユーザーが指定した場合は、それを使用してください。指定がない場合は、このプロジェクトと環境について search-contexts を呼び出してください。kind が user のコンテキストが返され、filter kind notEquals "user" の totalCount が0の場合に限り、使用中のコンテキストの種類が user のみであるため、user を提案してください。search-contexts が利用できない場合、コンテキストが返されない場合、または別の種類のコンテキストが保存されている場合は、ユーザーに尋ねて空欄にしてください。

デザインで提案する値にはすべて、提案であることと理由を1行で明記してください。例：Control (suggested, what users see today): Start free trial。ユーザーは承認前に提案を変更できます。デザインを承認すると、そこに表示されている提案も承認されたものとします。

ユーザーが指定していない設定には、LaunchDarkly のデフォルトを使用できます。デザインでは、使用する各デフォルトを列挙してください。

• トラフィック分割：ユーザーが指定したバリエーション間で allocationPercent を均等に割り当てます（バリエーションが2つの場合は50/50）。合計値は100にする必要があります。
• 統計：LaunchDarkly のデフォルト（頻度論的な逐次検定）。ユーザーが選択しない限り、methodology は送信しないでください。選択された場合はその値を送信し、ここではこのデフォルトの代わりに表示してください。ベイズ方式を選ぶ場合の値は methodology "bayesian" です。
• データソース：dataSource "launchdarkly"。
• 再シャッフル：canReshuffleTraffic true。

ユーザーが設定していない限り、analysisConfig は設定せず、デザインでもその旨を伝えてください。ランダム化単位は、これらのデフォルトのいずれにも含まれません。

ワークフロー

不足している情報がなければ、情報収集のメッセージは省略して、すぐに設計を提示します。不足している情報がある場合は、設計を提示する前に、必要な情報をすべて1つのメッセージで尋ね、その後、返答を待ちます。

• フラグとそのバリエーション、仮説、または主要指標のうち、不足しているもの
• get-flag で見つからない名前付きフラグ：見つからないことを伝え、1つのメッセージで次の3つの選択肢を提示します。キーを修正する（list-flags から類似するフラグを一覧表示する）、ユーザー自身でフラグを作成してから続行するよう伝える、またはあなたに作成を依頼する。最後の選択肢では、ユーザーの設計に基づいてキー、名前、種類、バリエーションを提案し、オフの状態で作成することを伝え、create-flag を呼び出す前に明示的な承認を待ちます。launchdarkly-flag-create がインストールされている場合は、その手順に従います。フラグが作成されたら、セットアップを続行します。ユーザーがこの選択肢を選び、詳細を承認しない限り、フラグを作成してはいけません。
• 上記のルールで提案ではなく質問するよう指定されている場合の、対照群またはランダム化単位
• 新しい主要指標について、種類（custom、pageview、click のいずれか）、何に基づくか（イベントキー、URL マッチ、クリックセレクターのいずれか）、測定方法（コンバージョンしたユニットの割合、合計数、平均のいずれか）。ユーザーがすでに明確にしている場合は除きます。

情報収集中に list-metrics と get-flag を使用してもかまいません。create-metric と create-experiment は使用できません。

ユーザーの表現ですでに明確になっている項目については、質問しないでください。「cta-clicked イベントを送信したユーザーの割合」であれば、測定方法、種類、イベントキーがすでに指定されています。

空欄がなくなった場合に限り、設計を提示します。不足している値がある状態で設計を提示してはいけません。上記で収集した情報のすべて、その他のバリエーション、フラグ設定（flagKey、ruleId、flagConfigVersion）、適用するすべてのデフォルト値を含めます。統計手法は、ユーザーが手法を選択していない場合は LaunchDarkly default (frequentist, sequential testing) とします。ユーザーが手法を選択した場合は、その選択内容を表示します。提案する値にはそれぞれラベルを付けます。「作成する前に」を参照してください。

ここで停止し、ユーザーが設計を承認するまで待ちます。

ユーザーが確認した完全な設計を明示的に承認した後に限り、指標と実験を作成します。設計を確認した後にユーザーが何か変更した場合は、更新した設計を提示して、もう一度確認を求めます。

ステップ 1：メトリクスを準備する

1. list-metrics を使って既存のメトリクスを確認します。ユーザーが主要メトリクスを指定します。
2. すでに存在する場合は、デザインレビューでその名前とキーをそのまま使います。
3. 存在しない場合、見つからなかったということは、そのメトリクスが新規であることを意味するだけです。ユーザーはメトリクス名を指定していても、その種類やイベントキーは指定していないことがよくあります。デザインに進む前に、それらを確認してください。ユーザーが種類と、カスタムイベントの場合はイベントキーを指定するまでは、次のようにします。
   • list-metric-events を呼び出さないでください。
   • メトリクス名や、ユーザーが指定していないその他のキーをイベントキーとして確認しないでください。
   • メトリクスを pageview または click とみなして、フロー確認を省略しないでください。
   • 特定していないイベントを理由に、作成を止めないでください。
4. 新しいメトリクスの種類、何に基づくものか、どのように測定するかについては、確認ルールを参照してください。
5. ユーザーが新しいメトリクスを custom と指定し、そのイベントキーを指定した後、そのイベントキーについて list-metric-events を呼び出します。いずれの場合も、ほかに未確定の項目がなければ、そのメトリクスをデザインに含めます。イベントが LaunchDarkly にまだ届いていない場合は、その環境にはまだイベントが到着していないという警告をデザインに含めてください。その環境について list-metric-events が返すカスタムイベントキーは最大 10 個まで表示し、ユーザーが指定したキーに似たものを優先してください。これにより、誤字を見つけやすくなります。イベントキーを訂正できること、またはトラッキングがまだデプロイされていない場合はそのまま承認できることを伝えてください。ユーザーがイベントキーを訂正した場合は変更となるため、承認ルールに従って、新しいキーについて再度 list-metric-events を呼び出し、更新したデザインを表示してください。承認されたら、イベントがまだ届いていなくても、通常どおりメトリクスと実験を作成します。
6. ページビューとクリックのメトリクスには、カスタムイベントキーはありません。種類が pageview または click であるとユーザーが指定した後に限り、list-metric-events を省略してください。
7. ユーザーが指定した主要メトリクスを、primarySingleMetricKey または primaryFunnelKey として渡してください。

目標	メトリクスの種類	キーの例
コンバージョン	カスタムコンバージョン	checkout-completed
パフォーマンス	カスタム数値	page-load-time-ms
エンゲージメント	カスタムコンバージョン	feature-clicked
収益	カスタム数値	order-value

ステップ 2：ターゲティングルールを特定する

実験を制御するフラグルールの ruleId と現在の flagConfigVersion が必要です。フラグ（またはその環境スコープのステータス）に対して get-flag を使い、これらを確認してください。フォールスルールの ID は文字列 "fallthrough" です。

ステップ 3：実験を作成する

上記の確認および承認ルールに従い、新しいメトリクスには create-metric を呼び出してから、create-experiment を呼び出してください。イベントの確認についてはステップ 1 を参照してください。

create-experiment を呼び出してください。トップレベルのフィールドは実験を表し、ネストされた iteration オブジェクトは最初のデータ収集期間を表します。以下の例の値は呼び出しの形式を示すもので、コピーして使う値ではありません。ランダム化単位については、「作成を始める前に」を参照してください。

{
  "projectKey": "my-project",
  "environmentKey": "production",
  "key": "checkout-flow-v2-experiment",
  "name": "Checkout Flow v2 Experiment",
  "description": "Compare the redesigned checkout against the current flow.",
  "tags": ["growth", "checkout"],
  "iteration": {
    "hypothesis": "The redesigned checkout will lift completion rate by 3%.",
    "primarySingleMetricKey": "checkout-completed",
    "metrics": [
      { "key": "checkout-completed" },
      { "key": "checkout-time-seconds" }
    ],
    "treatments": [
      {
        "name": "Control",
        "baseline": true,
        "allocationPercent": 50,
        "parameters": [
          { "flagKey": "checkout-flow-v2", "variationId": "variation-a-id" }
        ]
      },
      {
        "name": "New Checkout",
        "baseline": false,
        "allocationPercent": 50,
        "parameters": [
          { "flagKey": "checkout-flow-v2", "variationId": "variation-b-id" }
        ]
      }
    ],
    "flags": {
      "checkout-flow-v2": {
        "ruleId": "fallthrough",
        "flagConfigVersion": 7
      }
    },
    "randomizationUnit": "user"
  }
}

ユーザーが選択していない限り、methodology は省略してください。選択している場合は、その値（"bayesian"、"frequentist"、または "export_only"）を設定します。

便利なオプショントップレベルフィールド：

• holdoutId — 既存のホールドアウトを関連付けます。
• dataSource — "launchdarkly"（デフォルト）、"snowflake"、または "databricks"。
• methodology — ユーザーが選択した場合にのみ送信します："bayesian"、"frequentist"、または "export_only"。それ以外の場合は省略してください。LaunchDarkly のデフォルトは、逐次検定を用いる頻度論的手法です。
• analysisConfig — ユーザーが設定したフィールドのみを設定します。逐次検定を有効のままにするには、設定しないでください。

便利なオプションのイテレーションフィールド：

• attributes — 結果を分類するためのコンテキスト属性キーの配列（例：["country", "device"]）。
• covariateId — 層化サンプリング用の共変量 CSV ID。
• canReshuffleTraffic — デフォルトは true です。割り当てが変更された際に、ユーザーを最初のバリエーションに固定するには false に設定します。

ステップ 4：データ収集を開始する

実験を作成すると、イテレーションは not_started のままになります。ユーザーが開始すると明示的に伝えた場合に限り、start-experiment-iteration を呼び出してください。イテレーションを開始するその他の呼び出しにも、同じく待機が適用されます。

{
  "projectKey": "my-project",
  "environmentKey": "production",
  "experimentKey": "checkout-flow-v2-experiment"
}

開始する前に、API では次の条件を満たす必要があります。

• フラグがオンになっていること。
• イテレーションに randomizationUnit が設定されていること。
• allocationPercent がゼロより大きいトリートメントが少なくとも 1 つあること。

プライマリメトリクスがカスタムイベントの場合は、開始直前にもう一度 list-metric-events を呼び出してください。イベントが届いている場合は、フラグがオンになったら通常どおり開始します。まだ届いていない場合でも実験は開始できますが、イベントが届くまで結果は空のままになるため、それでも開始するかどうか確認してください。

ユーザーが開始すると伝えたときに、その環境でフラグがオフになっている場合は、フラグを変更しないでください。その環境でフラグをオンにする必要があること、またオンにすると、その環境のユーザーへのバリエーションの配信が開始されることを伝えてください。ユーザー自身がオンにするか、あなたがオンにするかを尋ね、フラグを変更するツールを呼び出す前に、明示的な回答があるまで待ってください。フラグがオンになったら、get-flag をもう一度呼び出して最新の flagConfigVersion を取得し、それを使うようにドラフトを更新したことを開始前にユーザーに伝えてください。

フラグがオフで、カスタムイベントもまだ届いていない場合は、フラグについての質問と、それでも開始するかどうかを一度のメッセージで尋ね、回答を待ってください。別々に尋ねないでください。

以前のイテレーションを停止した後に再開する場合は、changeJustification を渡してください。

ステップ 5：確認する

1. ユーザーから開始を依頼された後、get-experiment を呼び出し、currentIteration.status === "running" であることを確認します。
2. トリートメントが想定どおりの割り当てで設定されていることを確認します。
3. メトリクスの一覧とプライマリメトリクスを確認します。

ステップ 6：実験中に設計を変更する（必要な場合）

ほとんどの構造フィールド（トリートメント、メトリクス、手法、仮説など）は、イテレーションが running の間はロックされます。変更する方法は 2 つあります。

• 実行中の軽微な編集 — update-experiment では、running 状態で mutableFieldsByStatus が許可する項目のみ更新できます（通常は name、description、maintainerId、tags などのメタデータに加え、metrics／attributes の追加のみです）。拒否されたフィールドは、理由とともに skipped に表示されます。
• 設計の大幅な変更 — save-and-start-experiment-iteration を呼び出します。現在のイテレーションを停止し、指定したフィールドの更新を適用した新しいドラフトを作成して、1 回の呼び出しで開始します。入力項目は changeJustification を除き、update-experiment と同じです。更新は新しいドラフトに適用されるため、変更可能かどうかは not_started の状態に基づいて判定されます。

save-and-start-experiment-iteration は新しいイテレーションを開始します。変更内容を提示し、ユーザーが開始すると明示的に伝えるまで待ってから呼び出してください。

例：1 回の呼び出しでトリートメントの割り当てを入れ替え、メトリクスを追加します。

{
  "projectKey": "my-project",
  "environmentKey": "production",
  "experimentKey": "checkout-flow-v2-experiment",
  "changeJustification": "Lowering control allocation now that variant looks safe.",
  "treatments": [
    {
      "name": "Control",
      "baseline": true,
      "allocationPercent": 30,
      "parameters": [{ "flagKey": "checkout-flow-v2", "variationId": "variation-a-id" }]
    },
    {
      "name": "New Checkout",
      "baseline": false,
      "allocationPercent": 70,
      "parameters": [{ "flagKey": "checkout-flow-v2", "variationId": "variation-b-id" }]
    }
  ],
  "metrics": [
    { "key": "checkout-completed" },
    { "key": "checkout-time-seconds" },
    { "key": "checkout-error-rate" }
  ]
}

ステップ 7：イテレーションを停止する

結果から判断できる場合、またはユーザーが判断を下した場合は、イテレーションを停止します。頻度論的な実験では、その判断基準は統計的有意性です。ベイズ統計的な実験では、ベースラインを上回る確率、または最良となる確率です。使用している手法に対応する統計量のみを引用してください。停止するには、勝者となる処置が必要です — LaunchDarkly では、勝者を宣言せずにイテレーションを終了することはできません。勝者となる処置の ID（get-experiment が各処置の _id として返すもの）と winningReason を渡してください。

実験の結論が出なかった場合、またはどのバリエーションもコントロールを上回らなかった場合は、ベースライン／コントロール処置を勝者として宣言し、その旨を winningReason に記載してください（例：「結論が出なかった — コントロールを維持」）。「勝者なしで停止」する方法はありません。

{
  "projectKey": "my-project",
  "environmentKey": "production",
  "experimentKey": "checkout-flow-v2-experiment",
  "winningTreatmentId": "treat-002",
  "winningReason": "Two weeks of data, +4.1% lift on the primary metric."
}

判断に用いた統計量を winningReason に記載してください。頻度論的な実験：有意性、または有意ではなかったこと。ベイズ統計的な実験：ベースラインを上回る確率、または最良となる確率。頻度論的な実験で、ベイズ確率や事前分布を引用しないでください。

結果を報告する：

• 宣言した winningTreatmentId（結論が出なかった場合はコントロール／ベースライン）でイテレーションを停止したこと。
• 主要指標のリフトと、使用している手法に対応する判断統計量。
• 次のステップ（勝者をリリースする、ロールバックする、または後続のイテレーションを開始する）。

エッジケース

状況	対応
新しい主要指標の種別またはイベントキーが不明	イベントを確認する前に、それらの情報を集めます。ステップ 1 を参照してください。
新しい指標がカスタムイベントで、ユーザーがそのイベントキーを指定している	イベントがまだ届いていない場合は、設計時に警告します。承認後は引き続き作成します。ステップ 1 を参照してください。
フラグ、バリエーション、仮説、または主要指標が不足している	確認し、空欄のままにします。「作成を始める前に」を参照してください。
指定されたフラグがプロジェクトに存在しない	キーの修正、ユーザー自身による作成、または詳細の承認後にこちらで作成する方法を提案します。それ以外の状況ではフラグを作成しないでください。情報収集のルールを参照してください。
ユーザーがコントロールを指定しておらず、ルール上確認が必要	コントロールを尋ねます。こちらから提案しないでください。「作成を始める前に」を参照してください。
ユーザーがコントロールを指定しておらず、ルール上提案が必要	コントロールを提案し、明示してください。「作成を始める前に」を参照してください。
ユーザーがランダム化単位を指定していない	ランダム化単位を提案するか、尋ねます。「作成を始める前に」を参照してください。
設計が承認されていない	create-metric と create-experiment を呼び出さないでください。上記の情報収集と承認のルールを参照してください。
ユーザーが開始を指示していない	イテレーションを not_started のままにします。start-experiment-iteration と save-and-start-experiment-iteration は呼び出さないでください。
ユーザーが開始を指示した時点でフラグがオフ	フラグを変更せず、先に確認してください。ステップ 4 を参照してください。
フラグに比較対象のバリエーションがない	ユーザーが明示的に求めた場合に限り、バリエーションを追加します。それ以外の場合は、存在するバリエーションを伝えて尋ねてください。
フラグの ruleId／flagConfigVersion が不明	get-flag または get-flag-status-across-envs を使用します。フォールスルールの ID は文字列 "fallthrough" です。
実験がすでに存在する	list-experiments で該当する実験を探し、詳細には get-experiment を使用します。
実験の途中でロックされたフィールドを変更する必要がある	手動で停止して作り直すのではなく、save-and-start-experiment-iteration（単一の呼び出し）を使用します。
update-experiment がフィールドに対して skipped を返す	応答の currentStatus と allowedFields を確認します — そのフィールドは現在のイテレーションの状態では変更できません。先にイテレーションを停止するか、save-and-start-experiment-iteration を使用してください。

してはいけないこと

• 必須項目を独自に補ったり、提案であることを明示せずに提案を提示したりしないでください。「作成前に確認する」を参照してください。
• Step 1 で指示される前に list-metric-events を呼び出したり、イベントが届いていないことを理由に作成をブロックしたりしないでください。Step 1 を参照してください。
• 上記の承認ルールを満たす前に、create-metric または create-experiment を呼び出さないでください。
• ユーザーが開始すると明示的に指示するまで、start-experiment-iteration または save-and-start-experiment-iteration を呼び出さないでください。
• ユーザーから明示的に依頼されない限り、フラグをオンまたはオフにしたり、ターゲティングを変更したりしないでください。
• ユーザーから依頼され、提案したキー、名前、タイプ、バリエーションについて承認を得るまでは、フラグを作成しないでください。情報収集ルールを参照してください。
• create-experiment で iteration を省略しないでください。必須項目です。
• 複数のトリートメントで baseline: true を設定しないでください。
• トリートメント間で allocationPercent の合計が 100 にならない設定にしないでください。
• イテレーションが running の間に、update-experiment でロックされたイテレーションフィールドを変更しようとしないでください。代わりに save-and-start-experiment-iteration を使用してください。
• イテレーションを早期に終了しないでください。方法論に裏付けられた判断を待ってください。Step 7 を参照してください。
• 慎重なホールドアウト設計なしに、同じフラグで複数の実験を同時に実施しないでください。