タイムツーウォレット：キーメトリック

1） TTWの定義および変形

• TTW₍deposit ₎：「支払い」→「お金をプレイすることができます」をクリックしてください。
• UX/3DS、 PSP/銀行による承認、確認および残高記録が含まれています。

TTW₍payout ₎："［出金］→［外部ウォレット/銀行のお金］をクリックします。
リスク/KYC/SoFチェック、同じ方法/NDゲート、廊下オーケストレーション、PSP/スキームでの確認、銀行/ウォレットでの投稿が含まれています。

2） TTWがP&Lメトリックである理由

コンバージョンとAR：最初の賭け/セッションの確率を迅速に入金します。
リテンションと信頼：迅速な結論が得られます。チケットをチャーンしてサポートします。
コスト：インスタントレールの方が高価な場合が多く、「スピード↔価格」のバランスが必要です。
運用リスク：TTWの長い尾は、インシデントとチャージバックのクラスタを作成します。

3）段階によるTTWの分解

3.1.デポジット（預金）

1.UI/チェックアウト（レンダリング、検証、3DS）

2.PSP認証（authorize）

3.キャプチャ/予約（確認、残高更新）

4.フォールバック/リトライ（soft-dection）

' = + + + '

3.2.結論は次のとおりです

1.事前チェック（KYC/SoF、 ND/same-method、 RG/AML制限）

2.リスク判断（自動/マニュアル）

3.ペイアウトオーケストレーション（通路選択： SEPA インスタント/PIX/高速 Payments/RTP/push-to-card/A2A/e-wallet）

4.PSP API （initiate→accepted）

5.ネットワーク/銀行（清算/投稿）

6.調整して通知する（&N）

' = + + + + '

4） SLAと目標レベル

入金p95： ≤ 10-20 sec（財布/ワンタップ）、≤ 30-60 sec （3DS付きカード）。

• インスタントレール（SEPA Instant/PIX/FPS/RTP、プッシュツーウォレット/カード）：≤ 15-30。
• 標準A2A/SEPAクレジット：T+0/T+1銀行（時間/日）。
• 国際的なSWIFT： 1-3の銀行業務日。
• p99は、期待を管理するためにコミュニケーション（ETAバンド）を維持することが重要です。

5）測定： 単位、窓、見本抽出

単位：トランザクション（デポジット/ペイアウト）。
集計：p50/p90/p95/p99、 SLAヒット％（ETAシェア）、尾（尾>2 × p95）。
スライス：method/corridor/PSP/MID/GEO/BIN クラスタ/time of day/channel。
除外：キャンセル/重複（idempotency）、プレイヤーの要求に応じて手動で一時停止します。

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

sql payments. timeline (
tx_id PK, kind -- DEPOSIT    PAYOUT,
user_id, method, corridor, provider, mid, iso2, currency, amount_minor BIGINT,
t_ui_start TIMESTAMP, t_3ds_start TIMESTAMP, t_3ds_end TIMESTAMP,
t_auth_req TIMESTAMP, t_auth_ok TIMESTAMP,
t_capture_ok TIMESTAMP,     -- депозиты t_precheck_start TIMESTAMP, t_precheck_ok TIMESTAMP, -- выводы t_risk_start TIMESTAMP, t_risk_ok TIMESTAMP,
t_payout_initiated TIMESTAMP, t_network_posted TIMESTAMP,
t_wallet_available TIMESTAMP, -- final availability status TEXT, decline_code TEXT, meta JSONB
);

sla. catalog (
kind, method, corridor, geo, p95_target_seconds INT, p99_target_seconds INT, eta_text TEXT
);

7） SQL計算テンプレート

7.1.預金によるTTW（合計および方法による）

sql
SELECT method,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_ui_start))) AS p95_ttw_sec,
PERCENTILE_CONT(0. 99) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_ui_start))) AS p99_ttw_sec,
COUNT() AS attempts,
100. 0 AVG((EXTRACT(EPOCH FROM (t_wallet_available - t_ui_start)) <= s. p95_target_seconds)::int) AS sla_hit_p95_pct
FROM payments. timeline t
JOIN sla. catalog s ON s. kind='DEPOSIT' AND s. method=t. method
WHERE t. kind='DEPOSIT'
AND t. status='SUCCESS'
AND t. t_ui_start BETWEEN:from AND:to
GROUP BY 1;

7.2.出力（通路）によるTTW)

sql
SELECT corridor,
PERCENTILE_CONT(0. 50) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start))) AS p50_sec,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start))) AS p95_sec,
PERCENTILE_CONT(0. 99) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start))) AS p99_sec,
100. 0 AVG((EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start)) <= s. p95_target_seconds)::int) AS sla_hit_p95_pct,
COUNT() AS payouts
FROM payments. timeline t
JOIN sla. catalog s ON s. kind='PAYOUT' AND s. corridor=t. corridor
WHERE t. kind='PAYOUT' AND t. status='SUCCESS'
AND t. t_precheck_start BETWEEN:from AND:to
GROUP BY 1;

7.3.ボトルネック分解（出力）

sql
SELECT corridor,
AVG(EXTRACT(EPOCH FROM (t_precheck_ok - t_precheck_start))) AS precheck_sec,
AVG(EXTRACT(EPOCH FROM (t_risk_ok - t_risk_start)))     AS risk_sec,
AVG(EXTRACT(EPOCH FROM (t_network_posted - t_payout_initiated))) AS network_sec,
AVG(EXTRACT(EPOCH FROM (t_wallet_available - t_network_posted))) AS posting_sec
FROM payments. timeline
WHERE kind='PAYOUT' AND status='SUCCESS'
AND t_precheck_start BETWEEN:from AND:to
GROUP BY 1
ORDER BY network_sec DESC;

7.4.SLAレンガとロングテール

sql
SELECT method, corridor,
COUNT() FILTER (WHERE EXTRACT(EPOCH FROM (t_wallet_available - COALESCE(t_ui_start, t_precheck_start))) > s. p95_target_seconds) AS breaches,
COUNT() AS total,
100. 0 COUNT() FILTER (WHERE EXTRACT(EPOCH FROM (t_wallet_available - COALESCE(t_ui_start, t_precheck_start))) > s. p95_target_seconds)
/ NULLIF(COUNT(),0) AS breach_pct
FROM payments. timeline t
JOIN sla. catalog s ON s. kind=t. kind AND COALESCE(s. method, t. method)=t. method AND COALESCE(s. corridor, t. corridor)=t. corridor
WHERE t. status='SUCCESS' AND (t. t_ui_start BETWEEN:from AND:to OR t. t_precheck_start BETWEEN:from AND:to)
GROUP BY 1,2
ORDER BY breach_pct DESC;

8）ダッシュボードとKPI

方法/corridor/PSP/GEO/BINクラスタによるTTW p50/p95/p99。
SLAヒット％、テールシェア（>2 × p95）、インシデント（注釈）。
要求された→Pre-check OK→Risk OK→Initiated→Posted→Available。
相関：TTW vs AR/デポジット変換、TTW vs サポートチケット/CSAT、 TTW vsチャーン。
コスト：「cost_per_payout」と「TTW win」の廊下に沿った「take-rate」。

9）アラート

p95違反：廊下/PSP> SLA X分に沿ってp95 TTW。
テールスパイク：シェア>2 × p95増加>Z時間でY％。
事前チェックストール：t_precheck_startは、t_precheck_okは15分以上ではありません（自動エスカレーション）。
リスクバックログ：t_risk_startは、t_risk_okは>threshold（手動キュー）ではありません。
ネットワーク/投稿異常：GEO/bankによる'network_sec'の急激な増加。
ポリシードリフト-タイムスタンプなしのイベント。

10） TTWを加速する方法（プラクティス）

デポジット（預金）

ワンタップ財布/Apple Pay/Google Pay、ネットワークトークン。
リスクによる摩擦のない3DS、モーダルに3DSを埋め込む。
BIN/GEO/healthのPSPのカスケード、柔らかい衰退のだけ再トレイ。
3DS/ACSチャンネルのプリフェッチ、劣化時の積極的なタイムアウト。

結論

頻繁なプレーヤーのためのPre-KYC/pre-SoF；≤しきい値の量のための事前承認。
インスタンス通路：SEPAインスタント/高速決済/RTP/PIX/プッシュツーカード/ウォレット。
通路のカスケード：インスタント→高速A2A→標準SEPA/SWIFT （ETA付き）。
同一メソッドとNDロジックは手動チェックなしで自動化されます。
時間の窓：締切りおよび銀行「狭い」時間を避けて下さい。
プロバイダのヘルスフィードと自動フェイルオーバーで、'network_sec'が増加します。

コミュニケーション

開始時のETA+進捗状況（「チェック」、「開始」、「入金済み」）。
プロアクティブな遅延アラート>SLA、正直な理由と予想される時間。

11）経済とトレードオフ

インスタントコストを増やす：アップリフトCSAT/チャーン/保持とbps/固定を比較します。
尾はp50よりも高価です。p95の最適化はP&L効果を高めます。
ローカルの違い：一部のGEOでは「、高速だが高価な」チャネルはより良い報酬を支払います。

12） Playbookインシデント

1.PSP/回廊固有のP95成長

バックアップ通路に自動再ルーティングし、劣化した限界を低減します。
更新されたETA、プロバイダへのチケットを持つプレーヤーへの通信。

2.リスクバックログ（手動チェック）

X ≤量の事前承認を有効にし、キューを再配布し、自動パスのしきい値を一時的に上げます。

3.GEOに遅延を投稿する銀行

別の対応する銀行/財布でバイパスし、新しいアプリケーションの「遅い」廊下を一時的に無効にします。

4.3DS/ACS劣化（預金）

リスクポリシーが許容する摩擦のない/代替のDSを強制するか、別のPSPにカスケードします。

13） TTWのまわりのA/Bテスト

インスタントとトラフィックの一部の標準通路（ガードレール：CBR bps、コスト/ペイアウト、CSAT）。
Pre-KYC著作権/フロー、ETA文言、メソッドの順序。
メトリクス：TTW p95、 SLAヒット％、チケット/1000 trx、 AR/変換、チャーン7/30。

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

1.ステージごとに測定し、タイムスタンプを単一のパターンに保ちます。
2.中央値だけでなく、p95/p99を最適化します。
3.経済が収束するインスタントレールを埋め込みます。
4.反復シナリオのKYC/SoF/承認前を実行します。
5.自動カスケード回廊とPSPは、健康に反応します。
6.正直なETAとステータスを言い、遅延を通知します。
7.カタログにSLAを保存し、スライスごとにSLAヒット％をチェックします。
8.TTWをCSAT/チケットに結び付け、ダッシュボードでチャーンします。
9.ポストインシデント：キャプチャの原因、変更ルール/しきい値タイマー。
10.イベントスキーマをバージョン化し、タイムスタンプの完全性を検証します。

15）実装チェックリスト

• 製品/財務に同意した預金/出金のTTW定義。
• 支払いの段階別タイムスタンプ。タイムライン'；SLAディレクトリ。
• ダッシュボードp50/p95/p99、 SLAヒット％、尾；p95/tails/backlogsアラート。
• PSP/回廊カスケード、ヘルスフィードおよび自動フェイルオーバー。
• Pre-KYC/SoFおよび事前承認ポリシー；自動化されるND/same方法。
• ユーザーのETA通信とステータストラッカー。
• 通路に沿って速度↔価格経済モデル。
• 事件のプレイブックと死後のプロセス。
• ガードレールによるTTW改善のA/Bテスト。
• データの完全性と計算の正確性の定期的な監査。

概要

Time-to-Walletは「出力速度」だけではありません。"これは、コンバージョン、リテンション、P&Lに影響を与える支払い経験のエンドツーエンドの指標です。段階ごとにTTWを測定し、p95/p99を最適化し、インスタントレールとカスケードを接続し、事前KYC/承認を通じて摩擦を除去し、ND/同じ方法のチェックを自動化します。強力なテレメトリー、正直なETA、既製のプレイブックは、支払いを迅速、予測可能、経済的に実行可能にします。