このページでは

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.

バリアント間の切り替え

バリアント・ジャンプは、ユーザーが単一のフラグまたは実験に対して2つ以上のバリアントを受け取った場合に発生します。 特定のしきい値を超えるバリアント・ジャンプが起きると、分析の信頼性に対する懸念が生じる可能性があります。

バリアントジャンプには正常なものもあり、一般的で通常は説明がつくものです。他のタイプは追跡が困難です。

バリアント ジャンプをデバッグする

バリアント・ジャンプをデバッグする最善の方法は、バリアントをジャンプしたユーザーを特定し、そのユーザーのタイムラインを分析することです。リモート評価を使用する場合は、Assignmentイベントをチェックして割り当てやエクスポージャーの不一致を特定してください。

バリアントをジャンプしたユーザーを見つけるには、次の手順に従ってください。

  1. 実験の診断カードに移動します。
  2. バリアントのジャンプチャートを見つけ、「チャートで開く」をクリックします。
  3. バリアントをジャンプしたユーザーのバーをクリックし、[ユーザー ストリームの表示] をクリックします。

分析を容易にするため、ユーザーのタイムラインには割り当てイベントと露出イベントのみを表示します。

ユーザータイムラインをデバッグする際は、次の点に注意してください。

  • フラグや実験がアクティブな間にターゲティングを変更しましたか? 変更のタイミングがこのユーザーに割り当てられたバリアントに影響を与えた可能性がありますか? バージョン番号をクリックすると、バージョン履歴を確認できます。
  • フラグまたは実験で使用されたバケットキーはどれですか? このプロパティの値は、このユーザーに対する割り当てまたはエクスポージャーの間で変化しますか?
  • ユーザーに未確認のエクスポージャーや割り当てイベントはありませんか?その場合、不足しているイベントは別のユーザーに送信された可能性があります。
  • 割り当てに含まれるべきユーザープロパティが欠落していませんか? その場合は、割り当てイベントのサーバーアップロードタイムスタンプを再確認し、それを周辺のアクティブなイベントと比較してください。 クライアントから送信されたイベントは、クライアント側での順序が異なっていても、割り当てイベントの後にAmplitudeに到着することがあります。

通常のバリアント間の切り替え

標準的なバリアント ジャンプは、次のような原因で発生する可能性があります。

  • ターゲット設定の変更: 実験の実行中に誰かがターゲット設定のルールを変更しました。
  • 匿名アイデンティティの統合:Amplitude IDによってバケット化された匿名ユーザーは、Amplitudeが一致するユーザーIDを通じてそれらのアイデンティティを解決するまで、異なるバリアントを受け取ることができます。

ターゲット設定の変更

次のアクションにより、ユーザーはバリアントをジャンプすることがあります:

  • バリアントの追加または削除。
  • バリアント分布の重みを変更します。
  • 動的なコホートをターゲットにします。
  • バケットキーを変更します。
  • 相互排除を更新します。

スティッキー・バケッティングを有効にしてバリアントジャンプを回避します。

ターゲット設定を変更する前にスティッキー・バケッティングを有効にすることで、バリアントジャンプを回避できます。スティッキ バケットは、サンプル比率の不一致(SRM)を引き起こす可能性があります。

匿名 ID マージ

Amplitudeが匿名ユーザーを処理する方法は、バリアントのジャンプにつながる可能性があります。Amplitudeは、匿名IDを既存の正しいユーザーID(存在する場合)とマージするのに十分な情報を取得した時点ですぐにマージします。 このマージは、ユーザーがログインせずに異なるデバイスでアプリを使用した場合や、ログアウト時にデバイス ID が再生成された場合に発生することがあります。

AmplitudeのID解決とユーザーの統合について詳しくはこちらをご覧ください。

このタイプのバリアントのジャンプを識別するには、ユーザーがバリアント間をジャンプした割り当てイベントを見つけます。 次に、両方のイベントのAmplitude IDを比較します。 イベント間でAmplitude IDが異なる場合、匿名IDのマージが原因である可能性があります。

この種のバリアントのジャンプを避けるため、ユーザー ID を持つログインユーザーのみをターゲットに設定する場合、ユーザー ID ごとにバケットを割り当てます。 また、匿名ユーザーのみをターゲットにしている場合(サインアップ実験など)は、デバイス ID ごとにバケットを割り当てることができます。

許可リスト

含めるリストにユーザー ID がいくつかあると仮定してください。 fetch() を呼び出し、その呼び出しにユーザー ID を渡します。この呼び出しは、インクルージョンリストに従ってコントロールエクスペリエンスを返します。次回fetch()を呼び出す際には、ユーザー ID を渡す必要はありません。ユーザーはもはやインクルージョンリストの基準を満たしていないため、Amplitudeはバケットキーをハッシュ化し、ユーザーは代わりに別のバリアントを受け取ることができます。デバイス ID を含めると、同じ結果が発生する可能性があります。

次の例では、ユーザーにはユーザー ID があります。ユーザーは包含リストに一致し、signin-up-new_design体験が提供されます。

ユーザー ID を持つユーザーは、対象リストと一致し、`signin-up-new_design`体験を受け取ります。

この例では、ユーザー ID は存在しません。ユーザーは対象リストに一致せず、「その他のすべてのユーザー」セグメントに分類され、代わりにsignin-up-original-viewエクスペリエンスを受け取ります。

ユーザー ID を持たないユーザーは、対象リストに一致せず、「その他のすべてのユーザー」セグメントに分類され、`signin-up-original-view`体験を受け取ります。

異常なバリアントジャンプ

異常なバリアント・ジャンプの例は、どの通常の説明にも当てはまらない。 異常なバリアントジャンプは、追跡が困難な場合があります。最も頻繁に発生する原因はアイデンティティの不一致です。ユーザーのアイデンティティは割り当てと露出トラッキングの間で異なります。 アイデンティティの不一致は、ほとんどの場合、実装の不整合に起因します。

以下の例は網羅的ではありませんが、Amplitude実験における一般的なID問題を示しています。

1台のデバイスに複数のログインアカウントがある場合

単一のデバイス上のアプリで、複数のユーザーアカウント(U1とU2)を持つユーザーの、このタイムラインについて考えてみてください。

  1. ユーザーU1としてアプリを開き、バリアントを取得します。U1 は experiment-1 に対して treatment を受け取ります。
  2. U1 を experiment-1 バリアント treatment に公開します。
  3. U1 からログアウトして U2 にログインし、ログイン時に非同期にバリアントを取得します。
  4. U2 のフェッチが解決される前に、U2 は experiment-1variant treatmentへのエクスポージャーを認識します。
  5. U2 のフェッチ処理が解決されます。 U2は「experiment-1」を受け取りますcontrol。
  6. U2 を experiment-1 バリアント control に公開します。

この場合、ユーザー U2 は U1 の保存済みバリアントを確認した後、バリアントを treatment から control にジャンプしました。この問題を回避するには、ユーザーエクスペリエンスをレンダリングする前にフェッチが解決されるのを待つか、ログアウト時に SDK のclear()メソッドを呼び出して、SDK から保存されているすべてのバリアントを消去してください。 バリアントをクリアすると、SDK のバリアントストレージが消去され、ユーザーはキャッシュされたバリアントを見ることができなくなります。 バリアントをクリアしても、フェッチリクエストが解決される前にユーザーがフォールバックエクスペリエンスを表示してしまうことを防ぐことはできません。

ログイン全体でデバイス ID を一貫性のあるものにしておくと、この種のバリアント ジャンプをチェックできます。 同じデバイス ID を共有する複数のユーザーを検索します。

割り当てと公開の間でのアイデンティティ入力に一貫性がありません

Amplitudeでは、ユーザーIDとデバイスIDのプロパティがユーザーを識別し、Amplitude IDを解決します。 割り当ての取得と評価に使用されるデバイスIDまたはユーザーIDが、エクスポージャーイベントの追跡に使用されるデバイスIDおよびユーザーIDと異なる場合、バリアントジャンプ、SRM、および一貫性のないまたは予期しないバケッティング動作が発生することがあります。

たとえば、Amplitudeに送信する前にIDをマスクするプロキシやCDP経由でイベントを送信する場合などがあります。この場合、バリアントを取得するために使用される ID は、エクスポージャーイベントに含まれる ID とは異なります。

もう1つの一般的な原因は、単純な実装エラーです。たとえば、次のケースではバリアントジャンプが発生しています。

  • ID 内の追加文字。 実際のアイデンティティの周囲に余分な引用符があることに注意してください:
    • 15a4f7e9-db4e-4c57-82c7-e57a2995803a
    • "15a4f7e9-db4e-4c57-82c7-e57a2995803a"
  • 大文字化に一貫性がありません。特に、UUID の場合:
    • 15a4f7e9-db4e-4c57-82c7-e57a2995803a
    • 15A4F7E9-DB4E-4C57-82C7-E57A2995803A

実験分析からバリアントジャンプしたユーザーを削除する

結果を分析する際は、データを削除するときに注意してください。データを削除するとバイアスが発生する可能性があります。 バリアントジャンプの原因を理解し、実装上のバグを修正することで、将来の実験で再発を防ぐことができます。バリアントを飛ばしたユーザーを削除することが最善の方法である場合は、[実験分析] タブの [フィルター] カードを使用します。 All exposed usersセグメントがデフォルトで有効になっている場合は、そのセグメントをクリックして*「実験セグメント」>「バリアントがジャンプしたユーザーを除外」*を選択します。

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