グラフは、時間の経過とともに実験に露出するユーザー数を詳述しています。x軸は、ユーザーが実験に最初に露出した日付を示します。y軸は、実験に露出したユーザー数の累計を示します。（割り当てイベントと露出イベントの違いについては、こちらをご覧ください。）各ユーザーは、複数の実験バリアントに露出しない限り、1回だけカウントされます。複数の場合、各バリアントにつき1回カウントされます。

下のグラフでは、各線が1つのバリアントを表します。3月20日は実験の初日で、158人のユーザーがコントロールバリアントの露出イベントをトリガーします。翌日、合計314人のユーザーがコントロールバリアントに露出しました。その数は、3月20日と3月21日の露出の合計です。

これはまさに標準的な累積露出グラフです：線が上へ、そして右へ伸びます。

数学的に言えば、各線の傾きは、y軸の変化をx軸の変化で割ったものです：

∆y / ∆x =

（T1日の時点で露出した累計ユーザー — T0日の時点で露出した累計ユーザー) / （T0とT1の間の経過日数）=

実験に露出する新規ユーザー数、T0日からT1日までの1日あたりの数。

このグラフについて、他に何が言えますか？

累積であり、y軸が減らないことを意味します。線の傾きは、実験に毎日露出する新規ユーザー数です。線の伸びが遅くなる、または完全に成長が止まる可能性があります。しかし、線がピークに達し、その後落ちる累積露出グラフはありません。
最後に点線があるものは、日付によっては不完全なデータがあることを意味します。詳細については、このヘルプセンターの記事を参照してください。
2つの線は、お互いを完璧にトラックしているわけではありません。これは、各線がユニークなバリアントを表し、同じ量のトラフィックを受信するように設定されていても、露出がバリアント間でわずかに異なることがあるためです。
両方のバリアントは、着実な成長軌道にあります。これは、季節性が無いことを意味します。例えば、ユーザーが平日にプロダクトにエンゲージする確率が高い（したがって、実験に露出する確率が高い）場合、これがチャートに表われます：週末は、y軸の値が緩やかに増加します。

多くの場合、x軸の設定を1日単位から1時間単位に変更すると、チャート理解の新しい方法となります：

ここでは、トレンドはまだかなり直線です。しかし、時間ごとのグラフを見ると、午後9時から午前5時まで、実験に露出している追加のユーザーがほとんどいないことがわかります。これはおそらく、人々が眠っている時間であり、それがプロダクトを使用していない理由です。これは、グラフの1日単位では分からなかったものです

これは、より極端な例です。ここでは、露出はステップ関数のようになります。この場合、実験に少なくとも1回露出したユーザーが、これらの「フラットな」時間中に機能フラグを評価している可能性があります。

変曲点

時には、線に変曲点があることがあります：

ここでは、2月27日に3本の線の傾きが少し変化しており、バリアントあたりの1日のユーザー数が約70から約100になったことがわかります。（傾きは、変曲点の後で平坦になることもあることに注意します。）

なぜそうなってしまうのでしょうか？いくつかの可能性があります：

実験のトラフィックを増加させましたか？
各バリアントのトラフィック割り当てを増やしましたか？（トラフィックを1つのバリアントで増やした場合、1つの線だけにこの変曲点が現れます。）
ターゲティング基準を変更しましたか？（もともとカリフォルニアのユーザーをターゲットにしていて、その後、カリフォルニアとフロリダのユーザーにした、など）
広告予算の増加や**新機能のリリースなど、**実験に多くのユーザーを誘導する可能性のある、外部イベントがありましたか？

実験の途中でバリアントのトラフィック、またはトラフィック割り当ての設定を変更しないことを強く推奨します。実際に、Amplitude Experiment内でこの動作を行わないように警告が表示されます。これをすると、結果がシンプソンのパラドックスに陥る可能性があります（技術的な説明と分析については、こちらの記事を参照してください）。トラフィック割り当てを変更した場合は、新しい開始日を選択して実験を再開することを推奨します。すでにターゲットにしたユーザーを含めることは避けてください。

同様に、実験中にターゲット基準を変更すべきではありません。そうすると、サンプルがユーザーの100％にバリアントをロールアウトした場合を表すものでなくなります。その代わり、実験全体のトラフィックを徐々に増やすか、実験の代わりに段階的な機能のロールアウトを検討します。

実験の最初の週に、Androidユーザーのみをターゲットにし、100人のユーザーが実験を閲覧したと想像してください。翌週、ターゲット基準をiOSユーザーを含めるように変更し、実験は20人のユーザーが閲覧します。実験は2週間で220人のユーザーが閲覧し、そのうちの9％（20/220 = 1/11 = 9％）はiOSユーザーです。ただし、実験を100％トラフィックにリリースすると、iOSユーザーの真のパーセンテージが実際には16.7％であることがわかります。この場合、iOSユーザーの効果を過小評価することになります。実験がAndroidユーザーにプラスのリフトになり、iOSユーザーにマイナスのリフトになったとしたら、肯定的な実験との考えに基づいて機能をロールアウトするかもしれませんが、実際には否定的なものになりかねません。

傾きが変わった理由の疑問に答えたら、実験の終了日を調整するかどうかを検討します。トラフィックが増えると、統計的有意性に早く到達します。トラフィックが減る場合、統計的有意性に到達するのは遅くなります。

傾きを減少させる

時には、実験の累積露出が最初に強く始まり、時間の経過とともに緩くなることがあります。

この実験を開始したとき、各バリアントは、毎日約280人の新規ユーザーに露出しました。しかし、終わりに向かって露出率は減少し、バリアントの1日あたりの新規ユーザーが約40人になりました。

これは、Amplitudeで作成した静的コホート、すなわち、それ自体は成長または低下しないものをターゲットにしている場合かもしれません。例えば、100人のメンバーがいる静的コホートを想像します。初日に、実験はこのうち40人のユーザーに示されました。この結果、将来的に含められるユーザーは60人しかありません。日が経つにつれ、実験に参加できるユーザーが減少し、累積露出グラフの傾きが必然的に平坦になります。

実験に静的コホートを使用している場合は、サンプル量計算ツールをどう使用しているか考え直すことを検討してください。サンプル量の問題を解決する代わりに、この固定サンプル量で合理的に検出できるリフトのレベルを考える必要があります。

静的コホートは、実験の影響も制限します。

コホートをこのように使用するときは、そのコホートが実際に大きな集団を代表しているかどうか、より多くのユーザーが勝利バリアントに露出した場合、同様の上昇を示すかどうかを自問します。これを推測することはできません。それは、ある国での実験が、他の国で同じ影響を見せると推測するようなものです。

他に考えられる原因は次のとおりです：

動的なコホートを使用していながら、成長速度が足りず、実質的に静的なコホートである
スティッキーバケットの処理：ユーザーがコホートを入力して離脱し、ターゲット基準を満たさなくなったとしても、実験を（一貫性のために）表示し続けるか？
実験に参加するユーザー数が限られる可能性がある
実験が、後で露出するユーザーの代表ではないユーザーのグループに最初に表示される。プロダクトを30日間使用したユーザーがテストしている機能は、100日間使用しているユーザーと違う可能性があります。ユーザーの定常状態に処置が与える影響を検証するため、実験を当初の計画よりも長く実行することを検討しましょう。
ユーザーは徐々に実験に麻痺し、繰り返し露出した後、反応しなくなります。しかし、累積露出グラフが平坦になるということは、実験の影響が限られることを意味するものではありません。実験に露出しているユーザーが増えなくても、もともと露出しているユーザーが反応し、価値を提供するかもしれません。

累積露出グラフが平坦になったからといって、実験の影響が限られているわけではないことに注意してください。すべてはユーザーの行動の詳細に依存します。

実験前の期間推定と現在の期間推定は、何を意味しますか？このようなグラフを見ることは、実験に必要な時間の長さについて重大な示唆を与えてくれます。実験の期間を測る標準的な方法は、サンプル量計算ツールを使用し、推定サンプル数を1日あたりの平均トラフィックで割ることです。ここは、その例ではありません。一般に、分母が過大評価されたため、実験を予想以上に長く実行する必要があります。

平坦になった傾き

3月4日から3月11日までのデータに限ると、グラフはかなり平坦です。これは、その期間に実験に追加された新規ユーザーがほとんどいないことを示します。説明としてありうるのは以下のようなものです：

実験に追加するユーザーがいなくなった
露出イベントの送信にバグがある
プロダクトの使用は季節性に強く影響される。

この時間ごとのチャートで、箇条書きの最後のポイントを見ることができます：

3月21日午後7時から3月22日午前9時（グラフの最も右端）の間に、この実験に露出したユーザーはごくわずかでした。しかし、その直前の午前5時頃から、多数のユーザーが露出しました。しかし、グラフの左側は、ユーザーがゆっくり増えるパターンです。この実験をオンラインギャンブルの会社が行っていると考えると、大当たりの際にトラフィックが急増することに納得がいきます。

似た傾きのある発散線

この例では、2つのバリアントは2月23日と2月28日という別々の日にトラフィックを受信し始め、グラフ上の線はずれます。

理想的には、すべてのバリアントがトラフィックを受け取る準備ができるまで、実験を開始すべきではありません。実験中に後で新しいバリアントを追加すると、すべてのバリアントが同じ期間に同じ条件にならないため、結果を誤らせる可能性があります。結果に影響を与えるかもしれない新しいバリアントを追加する前に、何かが起こった可能性も捨てきれません。

もう1つの潜在的な問題は、新奇性効果です：緑のバリアントに露出したユーザーは、新しいエクスペリエンスに適応する時間が長くかかるかもしれません。最後に、その緑のバリアントに露出したユーザーは、主要指標をトリガーする機会が増え、特に制限のない時間指標である場合はバリアントの比較が公正でなくなります。

実験の中心的要件は、処置とコントロールの唯一の違いが、テストしている機能であることです。そうすれば、違いが単なる相関関係ではなく、因果関係であることがわかります。

異なる斜きの発散線

この状況になるには、いくつかの理由があります。カスタム露出イベントを使用している場合、ユーザーが割り当てイベントをトリガーせずに露出イベントをトリガーし続けると、古いキャッシュのバリアントを閲覧するかもしれません。

例えば、ユーザーは露出イベントをトリガーすることなく、コントロールバリアントに割り当てられる可能性があります。コントロールバリアントのトラフィック割り当てを0％に設定する場合、そのユーザーが後で戻り、新しい割り当てイベントをトリガーすることなく、露出イベントをトリガーする可能性があります。そのユーザーは、コントロール露出としてカウントされます。

この推論は、スティッキーバケットを付ける実験にも当てはまります。

この例では、このユーザーは3月15日に、コントロールバリアント100％でロールアウトしました。スティッキーバケットがオンになったため、トラフィック割り当てが0％に設定された後でも、ユーザー数は増加します。これは、バリアントがSDKまたはAPIを介して要求されたときに割り当てるため、ユーザーが露出されなくてもバリアントが「詰まる」可能性があるためです。

スティッキーバケットを選択し、さらにトラフィック割り当てを変更すると、望むトラフィック割り当てを得ることができないことに注意してください。代わりに、2つの割り当ての加重平均が得られます。これは、以前にバケットに入ったユーザーがバケットに留まるためです。望むトラフィック割り当てに近くなるまで、少し待つ必要があります。

実験でスティッキーバケットがオンになり、バリアントが終了した後にロールアウトする予定の場合は、コードの適切なブランチを削除し、機能フラグを除去する必要があります。コードを導入したくない場合は、スティッキーバケットをオフにすることもできます。

Need help? Contact Support

Visit Amplitude.com

Have a look at the Amplitude Blog

Learn more at Amplitude Academy