Time-to-Wallet: ключевая метрика

1) Определение и варианты TTW

• TTW₍deposit₎: `клик «Оплатить» → деньги доступны для игры`.
• Включает UX/3DS, авторизацию у PSP/банка, подтверждение и запись баланса.

TTW₍payout₎: `клик «Вывести» → деньги на внешнем кошельке/банке`.
Включает risk/KYC/SoF проверки, same-method/ND-гейты, оркестрацию коридора, подтверждение у PSP/схемы и постинг у банка/кошелька.

2) Почему TTW — это P&L-метрика

Конверсия и AR: быстрый депозит ↑ вероятность первой ставки/сессии.
Удержание и доверие: быстрые выводы ↓ churn и тикеты саппорта.
Стоимость: instant-rails часто дороже ⇒ нужен баланс «скорость ↔ цена».
Операционный риск: длинные «хвосты» TTW создают кластеры инцидентов и chargeback-напряжение.

3) Декомпозиция TTW по этапам

3.1. Депозиты

1. UI/Checkout (рендер, валидация, 3DS)

2. PSP Auth (authorize)

3. Capture/Booking (подтверждение, обновление баланса)

4. Fallback/Retry (при soft-decline)

`TTW₍deposit₎ = t_UI + t_3DS + t_auth + t_capture + t_write_balance`

3.2. Выводы

1. Pre-checks (KYC/SoF, ND/same-method, лимиты RG/AML)

2. Risk decision (авто/ручное)

3. Payout orchestration (выбор коридора: SEPA Instant / PIX / Faster Payments / RTP / push-to-card / A2A / e-wallet)

4. PSP API (initiate → accepted)

5. Network/Banks (clearing/posting)

6. Reconcile & Notify (подтверждение пользователю)

`TTW₍payout₎ = t_precheck + t_risk + t_initiation + t_network + t_posting + t_notify`

4) SLA и целевые уровни

Депозит p95: ≤ 10–20 сек (кошельки/one-tap), ≤ 30–60 сек (карты с 3DS).

• Instant rails (SEPA Instant/PIX/FPS/RTP, push-to-wallet/card): ≤ 15–30 мин.
• Стандартные A2A/SEPA Credit: T+0/Т+1 banking (часы/сутки).
• Международные SWIFT: 1–3 банковских дня.
• p99 важно держать в коммуникациях (ETA-диапазоны), чтобы управлять ожиданиями.

5) Измерение: единицы, окна, сэмплинг

Единица измерения: транзакция (deposit/payout).
Аггрегация: p50/p90/p95/p99, SLA-hit% (доля в ETA), хвосты (tail > 2×p95).
Срезы: метод/коридор/PSP/MID/GEO/BIN-кластеры/время суток/канал.
Исключаем: отмененные/дупликаты (идемпотентность), ручные паузы по запросу игрока.

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

TTW p50/p95/p99 по методам/коридорам/PSP/GEO/BIN-кластеру.
SLA-hit%, tail share (>2×p95), инциденты (аннотации).
Воронка выводов: Requested → Pre-check OK → Risk OK → Initiated → Posted → Available.
Корреляции: TTW vs AR/конверсия депозита, TTW vs тикеты саппорта/CSAT, TTW vs churn.
Стоимость: `cost_per_payout` и `take-rate` по коридору vs выигрыш по TTW.

9) Алерты

p95 breach: p95 TTW по коридору/PSP > SLA X минут.
Tail spike: доля >2×p95 выросла > Y% за Z часов.
Pre-check stall: t_precheck_start есть, t_precheck_ok нет > 15 мин (авто-эскалация).
Risk backlog: t_risk_start есть, t_risk_ok нет > порога (ручная очередь).
Network/posting anomaly: резкий рост `network_sec` по GEO/банку.
Policy drift: события без необходимых тайм-меток.

10) Как ускорять TTW (практики)

Депозиты

One-tap кошельки / Apple Pay / Google Pay, network tokens.
Frictionless 3DS по риску, встраивание 3DS в модалку.
Каскад PSP по BIN/GEO/здоровью, ретраи только на soft-decline.
Prefetch 3DS/ACS каналов, агрессивные тайм-ауты на деградации.

Выводы

Pre-KYC / pre-SoF для частых игроков; pre-approval на суммы ≤ порога.
Инстант-коридоры: SEPA Instant / Faster Payments / RTP / PIX / push-to-card/wallet.
Каскад коридоров: instant → fast A2A → стандартный SEPA/SWIFT (с ETA).
Same-method & ND-логика автоматизированы, без ручных проверок.
Временные окна: избегать cut-off и банковских «узких» часов.
Provider health-feed и авто-failover при росте `network_sec`.

Коммуникации

ETA на старте + прогресс-статусы («Проверка», «Инициировано», «Зачислено»).
Proactive оповещения при задержках > SLA, честные причины и ожидаемое время.

11) Экономика и компромиссы

Instant стоит дороже: сравнивайте uplift CSAT/churn/retention vs bps/fixed.
Хвосты дороже, чем p50: оптимизации на p95 дают больший P&L-эффект.
Локальные различия: в некоторых GEO «быстрый, но дорогой» канал окупается лучше.

12) Инцидент-плейбуки

1. Рост p95 по конкретному PSP/коридору

Авто-reroute на резервный коридор, снижение лимита по деградирующему.
Коммуникация игрокам с обновленным ETA, тикет в провайдер.

2. Risk backlog (ручные проверки)

Включить pre-approval на суммы ≤ X, перераспределить очередь, временно поднять пороги auto-pass.

3. Bank posting задержки по GEO

Обход с другим банком-корреспондентом/кошельком, временно отключить «медленный» коридор для новых заявок.

4. 3DS/ACS деградация (депозиты)

Форсировать frictionless/alternate DS там, где позволяет риск-политика, или каскад на другого PSP.

13) A/B-тесты вокруг TTW

Instant vs Standard коридор на части трафика (guardrails: CBR bps, cost/payout, CSAT).
Pre-KYC копирайт/флоу, ETA формулировки, порядок методов.
Метрики: TTW p95, SLA-hit%, тикеты/1000 trx, AR/конверсия, churn 7/30.

14) Best practices (коротко)

1. Мерьте по этапам и держите тайм-метки в единой схеме.
2. Оптимизируйте p95/p99, а не только медиану.
3. Встраивайте instant-rails там, где экономика сходится.
4. Делайте pre-KYC/SoF/approval для повторяющихся сценариев.
5. Авто-каскадируйте коридоры и PSP, реагируйте на health.
6. Говорите честный ETA и статусы, оповещайте о задержках.
7. SLA храните в каталоге и проверяйте SLA-hit% по каждому срезу.
8. Привяжите TTW к CSAT/тикетам/churn в дашбордах.
9. Пост-инциденты: фиксируйте причины, меняйте правила/пороговые таймеры.
10. Версионируйте схему событий, валидируйте полноту тайм-меток.

15) Чек-лист внедрения

• Определения TTW для депозитов/выводов, согласованные с продуктом/финансами.
• Тайм-метки по этапам в `payments.timeline`; SLA-каталог.
• Дашборды p50/p95/p99, SLA-hit%, хвосты; алерты p95/tails/backlogs.
• Каскады PSP/коридоров, health-feed и авто-failover.
• Pre-KYC/SoF и pre-approval политики; ND/same-method автоматизированы.
• ETA-коммуникации и статус-трекер для пользователя.
• Экономическая модель «скорость ↔ цена» по коридорам.
• Плейбуки инцидентов и процесс пост-mortem.
• A/B-тесты улучшений TTW с guardrails.
• Регулярный аудит полноты данных и корректности расчетов.

Резюме

Time-to-Wallet — это не просто «скорость вывода». Это сквозная метрика платежного опыта, влияющая на конверсию, удержание и P&L. Измеряйте TTW по этапам, оптимизируйте p95/p99, подключайте instant-rails и каскады, снимайте трение через pre-KYC/approval и автоматизируйте ND/same-method проверки. Сильная телеметрия, честные ETA и готовые плейбуки сделают платежи быстрыми, предсказуемыми и экономически оправданными.