決済シナリオのA/Bテスト

1）なぜ支払いシナリオをテストするのか

承認（AR）を増やし、失敗（DR）を減らす。
コスト削減：テイクレート（交換/スキーム/マークアップ/固定）および承認あたりのコスト。
リスクを軽減：同じ承認でのチャージバック/詐欺が少なくなります。
サステナビリティ：特定のGEO/BIN/メソッドのprovider/3DS戦略/ルーティングを選択します。

2）実験設計

2.1.ランダム化ユニット

ユーザーレベル（推奨）：1人のユーザーのすべての試みが1つのブランチに分類されます→3DS/tokensの「ミキシング」はありません。
BINレベル：テストが発行者によるルーティングについてのとき；クロスユーザーの混乱のリスク。
Order/Attempt-level：小さなUI実験（例えば、エラーのコピー）では許容でき、routing/3DSでは望ましくない。

2.2.層別化（ランダム化前）

によって層別化：GEOプレーヤー、発行者のcountry/BIN6、支払方法、チャネル（網/app）、量セグメント、危険率。これにより、SRMの分散とリスクが軽減されます。

2.3.私達がテストするもの

ルーティング/カスケード：PSP_A対PSP_B、 スティッキーBIN、リミット認識。
3DSポリシー：frictionless→challenge、 BIN/GEO用の3DSを強制。
UXフロー：ステップのシーケンス、エラー/繰り返しテキスト。
パラメータ：ウィンドウとソフトダウンコード。
価格設定：IC++対のプロバイダがブレンドされ、オールインコストに影響を与えます。

3）指標： ターゲット、二次、ガードレール

3.1.Main（メイン）

AR（承認率）=承認/試行。
Cost-per-Approval=（auth+down fees）/承認。
テイクレート％（オールイン）=手数料/ボリューム（通貨を報告する場合）。
3DSパスレート；責任シフト％。
レイテンシp95/p99の支払いフロー。

3.2.リスクメトリクス

チャージバック率（CBR）、返金率、詐欺アラート/1000 trx。
FX slippage （bps）=reference FXに対して有効です。

3.3.ガードレール（停止条件）

AR> Y bpsの低下またはCBR/Refundsの上昇がしきい値を超えています。
SRM （Sample Ratio Mismatch）-トラフィックの不均衡と予想との比較。
スパイク：レイテンシ、ソフトダウンサージ、3DS異常。

4）統計および力

4.1.サンプルサイズ（分数の近似）

n_per_group ≈ 2 (Z_{1-α/2} + Z_{1-β})^2 p(1-p) / δ^2

ここで、'p'はベースAR、 'δ'はARで期待されるアップリフトであり、αは意義レベルであり、βはタイプIIエラーである。

4.2.シーケンシャル分析（早期停止）

アルファ支出（O'Brien-Fleming/Pocock）：検査スケジュールを修正し、段階的にαを費やします。
SPRT/ベイズ-運用ソリューションのために、しかし、プロトコルを修正します。

4.3.Varysエディトリアル

CAPPED： 'Y=Y − θ （X − μ_X）'、ここでXは実験前の共変量（AR/DR/リスク率）、θは共変係数である。
層別スコア、クラスタ堅牢なエラー（ユーザー/BINクラスタ）。
テイクレート/コストメトリック（ヘビーテール）のブートストラップ。

4.4.多変量性テストと盗賊

MAB （UCB/Thompson）：その場で「学ぶ」ことが大切なとき。
コンプライアンス・クリティカル指標（CBR、責任）については、ガードレール付きの古典的なA/Bを好みます。

5）実験的なプラットフォームアーキテクチャ

1.代入サービス：決定的ハッシュ'（user_id、 experiment_id、塩）'→bucket。
2.Feature-flags/Rules-engine：ブランチに沿ったroute/3DS/retractのアクティブ化。
3.イベント：attempts/results （authorize/capture/refund/cb）→bus （Kafka/PubSub）。
4.Idempotency：カスケードごとの合計'idempotency_key'。
5.DWH/ショーケース：正規化されたステータス、手数料、FX、リスクフラグ。
6.監視：オンラインSLI （AR/3DS/レイテンシー）、アラート、SRMチェック。
7.プロトコル：事前登録仮説、最終基準、データフリーズ。

6）データモデル（最小）

sql ref. experiments (
exp_id PK, name, hypothesis, owner, start_at, end_at,
unit -- USER      BIN      ORDER,
target_metric, guardrails JSONB, design JSONB, alpha NUMERIC, power NUMERIC, meta JSONB
);

ref. experiment_arms (
exp_id FK, arm_id, name, traffic_share NUMERIC, params JSONB, enabled BOOLEAN
);

assignments. buckets (
exp_id, user_id, assigned_arm, assigned_at, salt, hash_key, PRIMARY KEY (exp_id, user_id)
);

events. payments (
attempt_id PK, user_id, exp_id, arm_id,
provider, method, bin, iso2, risk_score,
status, decline_code, three_ds_used BOOLEAN, liability_shift BOOLEAN,
amount_minor BIGINT, currency, latency_ms INT,
authorized_at, captured_at, settled_at, meta JSONB
);

finance. fees (
attempt_id FK, interchange_amt NUMERIC, scheme_amt NUMERIC, markup_amt NUMERIC,
auth_amt NUMERIC, refund_amt NUMERIC, cb_amt NUMERIC, gateway_amt NUMERIC,
fx_slippage_amt NUMERIC, reporting_currency TEXT
);

risk. outcomes (
attempt_id FK, is_refund BOOLEAN, is_chargeback BOOLEAN, fraud_alert BOOLEAN
);

7） SQLテンプレート

7.1.SRMチェック（手作業によるトラフィックのシェア）

sql
SELECT arm_id,
COUNT() AS n,
ROUND(100. 0 COUNT() / SUM(COUNT()) OVER (), 2) AS share_pct
FROM assignments. buckets
WHERE exp_id =:exp
GROUP BY 1;

7.2.手作業による主な指標

sql
WITH base AS (
SELECT e. arm_id,
COUNT()                  AS attempts,
COUNT() FILTER (WHERE status='APPROVED') AS approvals,
AVG(latency_ms)              AS latency_avg_ms,
AVG((three_ds_used)::int)         AS three_ds_share
FROM events. payments e
WHERE e. exp_id=:exp AND e. authorized_at BETWEEN:from AND:to
GROUP BY 1
),
cost AS (
SELECT e. arm_id,
SUM(f. interchange_amt + f. scheme_amt + f. markup_amt +
f. auth_amt + f. refund_amt + f. cb_amt + f. gateway_amt + f. fx_slippage_amt) AS fees_rep,
SUM(e. amount_minor)/100. 0 AS volume_rep
FROM events. payments e
JOIN finance. fees f USING (attempt_id)
WHERE e. exp_id=:exp AND e. settled_at BETWEEN:from AND:to
GROUP BY 1
)
SELECT b. arm_id,
approvals::numeric/NULLIF(attempts,0)             AS ar,
fees_rep/NULLIF(volume_rep,0)                 AS take_rate,
(SELECT COUNT() FROM risk. outcomes r
JOIN events. payments e2 USING (attempt_id)
WHERE e2. exp_id=:exp AND e2. arm_id=b. arm_id AND r. is_chargeback)=0
AS cb_zero_flag,
latency_avg_ms, three_ds_share
FROM base b LEFT JOIN cost c ON c. arm_id=b. arm_id;

7.3.CAPPED for AR（例）

sql
WITH pre AS (
SELECT user_id, AVG((status='APPROVED')::int) AS ar_pre
FROM events. payments
WHERE authorized_at <:pre_from_end
GROUP BY 1
),
cur AS (
SELECT e. user_id, e. arm_id, (e. status='APPROVED')::int AS ar_flag
FROM events. payments e
WHERE e. exp_id=:exp AND e. authorized_at BETWEEN:from AND:to
)
SELECT arm_id,
AVG(ar_flag - theta (ar_pre - mu_pre)) AS ar_cuped
FROM cur
LEFT JOIN pre USING (user_id),
LATERAL (SELECT AVG(ar_pre) AS mu_pre FROM pre) mu,
LATERAL (SELECT COVAR_SAMP(ar_flag, ar_pre)/VAR_SAMP(ar_pre) AS theta FROM cur LEFT JOIN pre USING(user_id)) t
GROUP BY arm_id;

7.4.ガードレールの確認（例）

sql
SELECT arm_id,
100. 0 SUM(is_chargeback::int)::numeric / NULLIF(COUNT(),0) AS cbr_pct,
100. 0 SUM(is_refund::int)::numeric  / NULLIF(COUNT(),0) AS refund_pct
FROM risk. outcomes r
JOIN events. payments e USING (attempt_id)
WHERE e. exp_id=:exp AND e. settled_at BETWEEN:from AND:to
GROUP BY 1
HAVING 100. 0 SUM(is_chargeback::int)::numeric / NULLIF(COUNT(),0) >:cbr_threshold
OR 100. 0 SUM(is_refund::int)::numeric  / NULLIF(COUNT(),0) >:refund_threshold;

8）テストプロセス（エンドツーエンド）

1.事前登録：仮説、メトリクス、デザイン、寸法、ストップルール。
2.「空」効果のSRM/AAテスト（数日）。
3.起動：割り当てフリーズ、rules-engine/phicheflagsのロジック。
4.オンラインモニタリング：AR/3DS/latency/health+ガードレール。
5.中間アルファ支出チェック（予定されている場合）。
6.フィニッシュと日付フリーズ：資金調達/準備/後期CB/払い戻しの会計後にのみ。
7.分析：CUPED/層別化、感度、GEO/BIN/method/channel heterogeneity。
8.解決：ロールアウト、ロールバック、または追跡テスト；ルール/ルーティングの更新。
9.ドキュメンテーションとレトロスペクティブ：レッスン、しきい値/重みの更新。

9）アンチパターンとトラップ

Peeking/re-review without protocol→false victories。
ルーティングテストでのオーダーレベルのランダム化→手の間の漏れ。
α修正なしの多重性ゲーム（多くのメトリック/スライス）。
不完全な費用（FX/予約/払い戻し手数料を忘れた）→間違ったテイクレート。
SRMチェック→ピンのずれ。
非idempotent retrays→double AR authorizations/distortions。

10）安全、コンプライアンス、倫理

same-method/return-to-sourceはテストによって壊れてはいけません。
制裁/ライセンス/GEOポリシーは実験を超えています。
RG/責任ゲーム：ARのための防御メカニズムを低下させないでください。
PCI/GDPR： PANの代わりにトークン、個人データの最小化、DPA/SOC2。

11）実験ダッシュボードKPI

AR/DR、アームとキー層別（GEO/BIN/メソッド）によるアップリフトと信頼区間。
Cost-per-Approval、 take-rate％、 FX slippage （bps）。
3DSのパス/責任の転位、柔らかい衰退の共有。
レイテンシp95/p99、エラー/タイムアウト。
CB/払い戻し（ラグ対応）、SRM、トラフィックカバレッジ、期間。

12）ベストプラクティス（短い）

1.ユーザーレベルでランダム化し、層別化します。
2.ガードレールおよびSRMの点検を使用して下さい；プロトコルを修正します。
3.フルコスト（手数料+FX+予約）と承認あたりのコストを考慮してください。
4.コスト指標には、CAPPED、クラスタ堅牢なエラー、およびブートストラップを使用します。
5.重要なリスク-古典的なA/B；bandits-主に価格/ARタスク。
6.最終的な撤退の前に資金調達/準備金/後期CBを検討してください。
7.規則を文書化してバージョンアップする。死後にしてください。

13）スタートアップチェックリスト

• 仮説、指標、効果、設計、サンプルサイズ、用語。
• ユニットのランダム化とストラタ、割り当てサービス、phicheflags。
• ガードレール/スレッショルド、SRM/AA-precheck、アラート。
• ログ/イベント、idempotency、ステータス正規化。
• ディスプレイケース手数料/FX/予約；通貨を報告します。
• アルファ支出計画とデータ凍結。
• Playbooksのロールアウト/ロールバック；結果のドキュメント。

概要

決済シナリオのA/Bテストは、正確なランダム化と層別化、フルコストとリスクメトリクス、ガードレールとSRM、きちんとした分析（CUPED/クラスタ・ロバスト性/シーケンシャル分析）、および「戦闘対応」インフラストラクチャ（アイデンポテンシー、テレメトリー、調整）という工学的な規律です。この手法に従うことで、ARを増加させ、オールインテイクレートを削減し、同時にチャージバックと規制上のリスクを増加させて「誤った勝利」を支払うことはありません。