フラグの前提条件

新しい実験を実行したり、新しい機能フラグを展開したりするときに、一部の機能は他の機能も有効になっている場合にのみユーザーに適用されます。 これらの依存関係を最初に評価し、その結果をフラグや実験の評価に使用してください。

実験を使用すると、フラグや実験に対して、前提条件となるフラグや実験の依存関係を作成できます。

フラグの前提条件を設定する

機能フラグの前提条件を [依存関係] カードに設定します。 実験 > 機能フラグ > お使いの機能フラグに移動し、「Dependencies」カードまでスクロールします。

このカードには、その機能フラグの前提条件フラグ、実験、相互排除、ホールドアウトグループなど、すべての依存関係が要約されています。 このカードには、それに依存するフラグと実験も記載されています。

1. 新しい前提条件を設定するには、編集アイコンを選択します。
2. **「依存関係を追加」**を選択して、新しい前提条件フラグまたは実験を追加します。
3. フラグまたは実験を選択し、目的のアイテムを選択します。

4. フラグが依存するバリアントを選択します。 特別なバリアントである Off は、前提条件フラグまたは実験によって除外されたユーザーを表します。
5. [保存] を選択します。

ワークフローに関する考慮事項

フラグを有効にするか、実験を開始する前に、前提条件フラグがアクティブになっていること、およびバリアント割り当てが期待どおりに機能することを確認してください。 前提条件フラグと実験がアクティブになるまで実験を開始することはできません。

フラグや依存関係のある実験の場合、Amplitudeは以下のアクションをブロックします：

• 別のフラグや実験がそれに依存している場合、バリアントを削除したり、バリアントキーを変更したりします。
• そのフラグや実験をアーカイブすること。

前提条件フラグを使用した評価の仕組み

この例は、前提条件フラグが存在する場合の評価の仕組みを示しています。

たとえば、新しいフィーチャーフラグ（Flag-B）を、別の機能（Flag-A）を最初に見たユーザーにのみ展開したいとします。Flag-B では、Flag-A のOnバリアントへの依存関係を追加し、両方のフラグを有効にします。

AmplitudeがユーザーをフラグBと関連付けるかどうかを評価する場合：

1. Amplitudeは、ユーザーがFlag-Bのコホートに属しているかどうかをチェックします。

   • ユーザーがそのコホートに属している場合、Amplitudeは設定済みのバリアントを提供します。

2. 次に、Amplitudeはユーザーの依存関係を評価します（この場合はフラグA）。

   • ユーザーがOn Flag-A のバリアントを受信しなかった場合、Amplitude はユーザーを Flag-B から除外します。

3. その後、Amplitude はユーザーを Flag-B と判断します。

Flag-Bのターゲティングは、ユーザーが受信するバリアント（存在する場合）を決定します。この時点では、Flag-A への依存関係は影響を与えません。

ユーザープロパティターゲティングと比較した前提条件

フラグの前提条件を使用するか、または[Experiment]ユーザープロパティに基づくターゲット設定ルールを使用することで、同様の結果を得ることができます。この2つのアプローチは重要な点で異なります。

ターゲティングに [Experiment] ユーザープロパティを使用してください

Amplitudeがユーザーをフラグまたは実験バリアントに割り当てる場合、Amplitudeは、バリアントキーを値とする形式[Experiment] <flag_key>でユーザープロパティを設定します。このユーザープロパティを別のフラグのターゲット設定ルールで参照することで、ユーザーの以前の割り当てに基づいてユーザーをターゲットにすることができます。

例: [Experiment] Flag-Aがonと等しいユーザーをターゲットにします。

制限事項

• タイミングの問題: Amplitudeは、割り当てまたはエクスポージャーイベントを取り込む際に[Experiment]ユーザープロパティを設定します。プロパティを同期する前に依存フラグを評価した場合、そのユーザーはターゲット設定ルールに一致しない可能性があります。
• 正式な依存関係追跡機能がない:UIにはフラグ間の関係が示されません。どのフラグが他のフラグに依存しているかを手動で追跡する必要があります。
• 潜在的な不整合: プロパティ同期とフラグ評価の間の競合条件は、ユーザーに一貫性のない体験を与える可能性があります。

フラグの前提条件を使用する

フラグの前提条件は、フラグ間の依存関係を正式に定義します。 Flag-AをFlag-Bの前提条件として追加した場合、AmplitudeはまずFlag-Aを評価し、その結果を使用してFlag-Bの適格性を判断します。

利点:

• 一緒に評価される：Amplitudeは1回の評価コール中に前提条件を順番に評価するため、タイミングの問題がなくなります。
• 依存関係を可視化: 依存関係カードにはすべての関係が表示されるため、複雑なフラグ階層を簡単に管理できます。
• 一貫したバケット設定: 前提条件の評価がアトミックに行われるため、ユーザーは一貫した体験を得ることができます。
• 変更の保護: Amplitudeは、前提条件フラグをアーカイブしたり、他のフラグが依存しているバリアントキーを変更したりすることを防ぎます。

各アプローチを使用するタイミング

一般的なユースケース

フラグの前提条件は、多くのユースケースをサポートしています。 一般的な例としては次のとおりです。

リリースグループ

フラグの前提条件を使用して、複数のサブ機能を持つプライマリ機能を構築します。 サブ機能には、サブ機能内のコホートにユーザーが個別に含まれている場合を除き、プライマリ機能がOnである必要があります。Amplitudeは、プライマリ機能からのターゲティングとバケット設定を、プライマリ機能を前提条件としてリストアップしているすべてのサブ機能に適用します。 そうしないと、プライマリ機能とサブ機能を受信するユーザは一致しません。

リリースグループの一般的なユースケース:

• 多くの開発者やチームによる大規模な機能リリースの活発な開発。
• アドオンを使用したプライマリSKUへのユーザーのプロビジョニング。
• コード内の機能フラグロジックを簡素化します。

この例には、primary-featureフラグと、前提条件としてプライマリ機能をリストアップするsub-featureフラグが含まれています。

このprimary-featureフラグは、ユーザープロパティpremiumがtrueであるすべてのユーザーを、100%の割り当て率で対象としています。サブ機能は、ユーザーが必要なユーザープロパティを持ち、サブ機能の基準を満たしている場合にのみ評価されます。 例外は、サブ機能に個別にユーザーが含まれている場合です。これは通常テストフェーズ中に発生します。

• このsub-feature-1フラグは、ユーザープロパティbetaがtrueであるユーザーのターゲティング基準を追加します。sub-feature-1を受け取るには、premiumとbetaの両方のユーザープロパティがtrueである必要があります。
• このsub-feature-2フラグはユーザーを 100% 割り当てます。Amplitudeは、premiumがtrueと等しいすべてのユーザーをこの機能に割り当てます。
• このsub-feature-3フラグは、ユーザーの 0% を割り当てています。Amplitudeは、premium が trueである場合でも、ユーザーを sub-feature-3に割り当てません。

連鎖された相互排除グループ

フラグの前提条件を使用して、異なる時刻に開始される相互に排他的な実験の複雑な階層を構築できます。 従属実験では、off と評価される既存のアクティブな実験を前提条件として指定します。このルールは、既存の実験で割り当てられていないすべてのユーザーを対象としています。 前の実験ですべてのユーザーが割り当てられなかった場合、この連鎖を継続して相互排他的な実験をさらに追加してください。

この例では、experiment-1 が今実行され、experiment-1 と相互に排他的な experiment-2 は後で実行されます。

• このexperiment-1実験では、20%のユーザーに50/50のコントロール/トリートメントを割り当てます。
• experiment-2実験では、experiment-1を前提条件として指定し、100% のユーザーに 50/50 のコントロール/トリートメントを割り当てます。

実験では、ユーザーの 20% を experiment-1に割り当て、残りの 80% を experiment-2に割り当てます。実験では、experiment-1 と experiment-2の両方のバリアントにユーザーを割り当てることはありません。