支払い方法の A/B テスト

ダッシュボードで新しい支払い方法の A/B テストを開始します。

A/B テストを使用すると、新しい支払い方法をすべての顧客に提供する前に、それらを一定の割合の買い手に提供した場合影響を測定できます。A/B テストはコードを作成せずに実行できます。

A/B テストは以下の目的で使用します。

Klarna、Affirm、Afterpay などの後払いの支払い方法を、顧客全体に導入する前に一部の顧客でテストします。
特定の支払い方法の最低購入金額を設定するなど、ターゲット設定ルールの影響を測定します。
新しい支払い方法を徐々に提供し、顧客の割合を増やしていきます。

Payment Element Web または Checkout を動的な支払い方法で使用して A/B テストを実行する必要があります。テストできる支払い方法のリストについては、サポートされている支払い方法をご覧ください。

A/B 実験を開始する

Stripe ダッシュボードで、支払い方法の設定を開き、実験を作成するをクリックします。
- Stripe ダッシュボードでは、実験の開始、停止、管理のみ実行できます (API オプションは提供されていません)。
- 複数の支払い方法を設定している場合は、実験を実行したい設定を選択してから、実験を作成するをクリックします。一度に実行できる実験は 1 つの設定につき 1 つのみです。
実験に含める支払い方法を選択します。
「(オプション)」支払い方法を利用対象にする状況を制御するための追加のフィルターとして、取引額や取引通貨などのカスタムの支払い方法のルールを追加します。スタンドアロンの機能を使用して、カスタムのルールを作成することもできます。
実験に名前を指定して、トリートメントグループに含めるトラフィックの割合を選択します。
- トラフィックの配分: デフォルトでは、スピーディーな結果の受け取り (統計的に有意義な結果には時間がかかり、割合が低くなる) と、実験のパフォーマンスが低い場合のリスク管理のバランスを保つため、50% を推奨しています。リスクの許容度と実験の目標に基づいて、より少ないまたはより高い割合を選択できます。トリートメント/コントロールを 50/50 に均等に分割すると、サンプルサイズが 8 万の場合は、購入完了率の 100 BPS の変化を 5% の有意水準で検出することが可能です。
- 実験のランダム化: Stripe は、UserAgent、IP アドレス、日付などの一意の識別子に基づいて買い手セッションをランダム化します。この結果、個々の買い手には、特定の日付について、トリートメントまたはコントロールの支払い方法として、同じの選択肢一式が表示されます。ページの更新など、二重カウントの発生を避けるために、Stripe では一意の各ユーザーのセッションを日次で集計します。
実験を確認して開始します。
注
実験を開始する際、トリートメントグループのトラフィックの配分率を変更できますが、トリートメントグループまたはコントロールグループの支払い方法の有効・無効を切り替えることはできません。実験の開始後に支払い方法の設定を変更するには、まず実験を終了する必要があります。
注
実験を開始する準備ができていない場合は、下書きとして保存し、後で開始できます。
「(推奨)」後払い (BNPL) 支払い方法をテストする場合は、Payment Method Messaging Element をインストールすることをお勧めします。この埋め込み可能な UI コンポーネントを使用すると、顧客は商品、カート、支払いの各ページから直接、利用可能な決済の選択肢を表示できます。

A/B 実験を管理および終了する

支払い方法の設定からアクティブな実験と過去の実験をすべて表示するには、オーバーフローメニュー () をクリックして、実験を管理を選択します。
実験が有効な間に実行できる操作は、以下の 4 つです。
- トラフィックの配分を調整:トリートメントグループに割り当てられるトラフィックの割合を 1% ～ 99% の範囲で調整します。
- 実験レポートを表示
- 実験を一時停止または再開: 一時停止すると、買い手はコントロールの支払い方法のみを利用でき、実験データはレポートにキャプチャーされません。
- 実験を終了: 実験の終了時に、トリートメント設定を採用することも、以前の (コントロール) 設定に戻すこともできます。実験が 180 日を超える場合は、Stripe がお客様に代わって終了し、管理設定を有効にします。
注
Connect プラットフォームを実装していて、treatment configuration (トリートメント設定) を選択すると、トリートメントでの新しい支払い方法はすべてのユーザーに対して有効になります。

実験結果を理解する

実験を開始したら、 Stripe ダッシュボードで進捗状況を確認します。

A/B テストでは、次の 2 つの条件を満たすと実験完了と見なされます。

セッションあたりの平均売上は統計的に重要です。Stripe では、ランダムなケースによる結果である可能性が 5% 未満である場合、その結果を統計的に重要であると見なしています。実験方法をご覧ください。
実験では十分なセッションが発生しました。これは、実験作成時に設定した、トリートメント対コントロールの割合に基づく動的な数値です。

実験結果の指標には以下が含まれます。

1 セッションあたりの平均売上: 1 セッションあたりの平均売上は、総売上を合計セッション数で割ったものです。これは、トリートメントグループとコントロールグループの間の 1 セッションあたりの売上の差異を示し、実験の全体的な結果を要約したものです。合計セッション数には、購入に至ったセッションと購入に至らなかったセッションの両方が含まれます。支払い方法によって購入完了率と平均注文額に大きな違いがあるため、実験の全体的な成功について判断する際は、指標として 1 セッションあたりの平均売上を使用することをお勧めします。
セッションの 100% における売上: 処理グループの支払い方法が、トリートメントとコントロールの全体の 100% のトラフィックに提供された場合に見込まれる売上。
総収入: 実際の売上 (総購入額)。この金額は、主にトリートメント/コントロールの割合の選択による影響を受けます。
購入完了率: 購入完了率とは、購入が行われたセッションの数を対象のセッションの総数で割ったものです。対象となるセッションは以下のように定義されます。
- 1 つ以上の処理の支払い方法が適格であった (たとえば、買い手の所在地が、その支払い方法が受け付けられる国であった)
- 支払いインターフェイス (Payment Element または Checkout) が買い手に表示された
平均注文額: 平均注文額とは、買い手が購入を行ったセッションでの平均購入額です。

統計的有意性

概要テーブルのインジケーターを使用して、統計的有意性を把握します。実験が、必要なセッションの推定値の 80% 以上に達すると、指標は緑色または黄色で差異を示します。

インジケーターには、以下の 3 つのタイプがあります。

グレーのインジケーターは、実験において、統計的有意性を確実に判断するのに十分なセッションが発生していないことを示します。
緑色のインジケーターは、トリートメントグループとコントロールグループの間で統計的に有意な増加が見られることを示します。
黄色のインジケーターは、トリートメントグループとコントロールグループの間で統計的に有意な減少が見られることを示します。

統計的有意性に達する前

統計的有意性に達した後

さらなる分析を行う

レポートページから未加工データをダウンロードして、実験結果をさらに分析できます。

注

ページの更新などのインスタンスの二重カウントを避けるため、experiment_session_id ごとにグループ化することをお勧めします。この方法は、A/B テストレポートで、セッションあたりの平均売上、購入完了率、平均注文額が計算される方法と合致しています。

ディメンション	説明
occurred_at_day	セッションの日 (‘yyyyMMdd’)。
experiment_session_id	各実験セッションに Stripe が生成した一意の ID。セッションは UserAgent、IP アドレス、および日付に基づきます。
is_treatment	結果がトリートメント (1) またはコントロール (0) のどちらとして割り当てられたかを示すブール値。
購入完了	このセッションが購入完了につながった (1)、あるいはつながらなかった (0) ことを示すブール値。
payment_method	購入に使用された実際の支払い方法。
converted_transaction_count	ユーザーセッションにおける個々の取引レベルの購入完了数。通常、この値は 1 または 0 ですが、同じ買い手が 1 日に複数の購入を行っている場合には、同じセッション内で複数の購入完了が発生することがあります。
rendered_transaction_count	ユーザーセッションにおける個々の取引レベルのレンダリングの数。買い手が購入ページに複数回アクセスした場合 (たとえば、再読み込みしたり、後日アクセスした場合など)、1 より大きい値になることがあります。
amount_capturable	取引合計額。
通貨	この取引で使用される通貨のタイプ (USD、GBP、EUR など)。
is_eligible_session	このセッションが A/B テストの対象であったか (1)、対象外 (0) であったかを示すブール値。このフィールドが 0 を返す場合 (たとえば、トリートメントの支払い方法が対象でなかった場合)、そのセッションは、平均注文額や購入完了率などの報告対象のメトリクスに含まれません。
buyer_countries	ユーザーセッションに関連付けられた国。ほとんどの場合、これは 1 つの国ですが、買い手が旅行中やブラウザーの場所設定を変更している場合は複数の国が存在することがあります。
control_payment_method_types	このセッションで表示対象になった、コントロールの支払い方法のリスト。
treatment_payment_method_types	このセッションで表示対象となったトリートメントの支払い方法のリスト。
rendered_payment_methods	ユーザーセッションで利用可能だった支払い方法のリスト。この中には、‘show more’ セレクターを選択したときに表示されるオーバーフローの支払い方法が含まれます。
visible_payment_methods	ユーザーセッションで表示された支払い方法のリスト。 (‘show more’ で表示されるオーバーフローの支払い方法は含まれない)。
connected_account_id	セッションに関連付けられた連結アカウントの ID。

実験手法

A/B テストでは、トリートメントとコントロールの結果を比較して、平均処置効果 (ATE) を測定します。実験が統計的に有意と見なされるのは、その結果が偶然によるものである可能性が 5% 未満であるときです。統計学的には、Z 検定を使用して、トリートメントグループとコントロールグループの間の差を水準 5% で計算します。これは、その差の 95% 信頼区間に 0 が含まれているかどうかを確認するのと機械的に同じです。影響を検出するのに必要なセッション数を判断するため、選択されたトリートメントとコントロールの分割割合に基づいて検出力の計算が実行されます。この検出力の計算では、有意水準 5% でトリートメントとコントロールの間の 1% の差を検出するのに 80% の検出力を示すために必要なセッション数が返されます。

注

Stripe はこの A/B テストサービスを貴社に提供するために、貴社の取引データから顧客のアクティビティーに関する分析情報を取得する必要があります。Stripe では、決済フローのいずれかのページで決済手段が表示されたユーザーが手続きを進めて決済フローを完了した時点を特定するために、顧客の IP アドレスとユーザーエージェントの情報を使用します。貴社と貴社の顧客に適用される法律によっては、貴社に代わってこの作業を実施するように Stripe に指示することで、貴社にて、開示事項の提供やこの作業に対する顧客の同意の収集などの手続きが必要になる場合があります。適用されるデータ保護法に基づくすべての義務を遵守していることを確認するには、弁護士にご相談ください。

サポートされている支払い方法

組み込みオプション

構築済みのシステムにおいて Payment Element Web または Checkout を動的な決済手段と組み合わせて使用している場合は、A/B テストにアクセスできます。

サポートされている支払い方法

Connect の A/B テスト Connect

A/B テストは Connect プラットフォームで利用できますが、個々の連結アカウントでは利用できません。 A/B テストを設定すると、コントロールとトリートメントに選択した支払い方法が、対象となるすべての連結アカウントに適用されます。特定の連結アカウントをオプトアウトするには、実験作成プロセス時にアカウント ID のリストを指定します。

プラットフォームは、連結アカウントが各自の支払い方法設定をカスタマイズして、特定の支払い方法を有効または無効にできるようにすることができます。連結アカウントが、トリートメントまたはコントロールグループに含まれる支払い方法を有効または無効にする場合、連結アカウントの設定がトリートメントセッションとコントロールセッションの両方に適用されます。たとえば、プラットフォームが Klarna を有効にして実験を実行し、連結アカウントが Klarna を無効にした場合、 Klarna が連結アカウントのユーザーに選択可能な支払い方法として表示されることはありません。