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: Т + 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.ru Вимірюйте TTW за етапами, оптимізуйте p95/p99, підключайте instant-rails і каскади, знімайте тертя через pre-KYC/approval і автоматизуйте ND/same-method перевірки. Сильна телеметрія, чесні ETA і готові плейбуки зроблять платежі швидкими, передбачуваними і економічно виправданими.