Time-to-Wallet: métrica chave

1) Definição e opções de TTW

• TTW₍deposit ₎ clique em "Pagar" → dinheiro estão disponíveis para o jogo ".
• Inclui UX/3DS, autorização de PSP/banco, confirmação e registro de balanço.

TTW₍payout ₎ clique em "Tirar" → dinheiro na carteira externa/banco ".
Inclui risk/KYC/SoF de verificação, same-method/ND-gate, orquestração do corredor, confirmação do PSP/circuito e postagem do banco/carteira.

2) Por que o TTW é P & L-métrica

Conversão e AR: depósito rápido ↑ probabilidade de primeira aposta/sessão.
Retenção e confiança: conclusões rápidas ↓ churn e tíquetes de safort.
Custo: O momento-rails é muitas vezes mais caro ⇒ precisa de um equilíbrio «velocidade ↔ preço».
Risco operacional: As longas «caudas» da TTW criam clusters de incidentes e tensão chargeback.

3) Descomposição de TTW por etapas

3. 1. Depósitos

1. UI/Checkout (render, validação, 3DS)

2. PSP Auth (authorize)

3. Capture/Booking (confirmação, atualização do balanço)

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

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

3. 2. Conclusões

1. Pré-checks (KYC/SoF, ND/same-method, limites RG/AML)

2. Risk definição (auto/manual)

3. Payout orquestration (seleção de corredor: SEPA Point/PIX/Faster Payments/RTP/push-to-card/A2A/e-wallet)

4. PSP API (initiate → accepted)

5. Network/Banks (clearing/posting)

6. Reconcile & Notify (confirmação ao usuário)

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

4) SLA e níveis de destino

Depósito p95: ≤ 10-20 segundos (carteiras/one-tap), ≤ 30-60 segundos (cartões com 3DS).

• Instant rails (SEPA Instant/PIX/FPS/RTP, push-to-wallet/card): ≤ 15–30 мин.
• A2A/SEPA Credit padrão: T + 0/T + 1 banking (relógio/dia).
• SWIFT Internacional: 1 a 3 dias bancários.
• p99 é importante manter as comunicações (faixas ETA) para gerenciar as expectativas.

5) Medição: unidades, janelas, sampling

Unidade de medida: transação (deposit/payout).
Agregação: p50/p90/p95/p99, SLA-hit% (participação no ETA), caudas (tail> 2 x p95).
Corte: método/corredor/PSP/MID/GEO/BIN clusters/hora do dia/canal.
Excluindo: cancelados/duplicados (idempotidade), pausas manuais a pedido do jogador.

6) Modelo de dados (mínimo)

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) Modelos de cálculo SQL

7. 1. TTW sobre depósitos (geral e métodos)

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 de saída (corredores)

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. Descomposição de «estreitos» (conclusões)

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. Brichas SLA e «caudas longas»

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) Dashboards e KPI

TTW p50/p95/p99 por métodos/corredores/PSP/GEO/BIN-cluster.
SLA-hit%, tail share (> 2 x p95), incidentes (anotações).
As conclusões são Requested → Pré-Check OK → Risk OK → Iniciated → Posted → Available.
Correlações: TTW vs AR/conversão de depósito, TTW vs tíquetes de safort/CSAT, TTW vs churn.
O valor é 'per _ per _ payout' e 'take-rate' pelo corredor vs ganho por TTW.

9) Alertas

p95 breach: p95 TTW pelo corredor/PSP> SLA X minutos.
Tail spike:> 2 x p95 aumentou> Y% em Z horas.
Pré-check stall: t _ precheck _ start, t _ precheck _ ok> 15 min (escalação automática).
Risk backlog: t _ risk _ start, t _ risk _ ok> limiar (fila manual).
Network/posting anataly: crescimento acentuado de 'network _ sec' por GEO/banco.
Policy draft: eventos sem as marcas de tempo necessárias.

10) Como acelerar TTW (práticas)

Depósitos

One-tap carteiras/Apple Pay/Google Pay, network tocens.
Frictionless 3DS em risco, incorporando 3DS no modal.
Cascata PSP por BIN/GEO/saúde, retraí apenas em soft-decline.
Preferch 3DS/ACS canais, temporais agressivos na degradação.

Conclusões

Pré-KYC/ pre-SoF para jogadores frequentes; pré-approval na soma ≤ limiar.
Corredores de instrução: SEPA Instantâneo/Faster Payments/RTP/PIX/push-to-card/wallet.
Cascata de corredores: momento → fast A2A → SEPA/SWIFT padrão (com ETA).
A lógica Same-method & ND é automatizada, sem verificação manual.
Janelas de tempo: evitar cut-off e relógios de banco.
Provider health-feed e auto-failover ao crescer 'network _ sec'.

Comunicações

ETA no início + estados avançados («Teste», «Iniciado», «Inscrito»).
Alertas proactivos para atrasos> SLA, razões honestas e tempo previsto.

11) Economia e compromissos

O momento é mais caro: compare uplift CSAT/churn/retence vs bps/fixed.
As caudas são mais caras do que p50: otimização em p95 dá um efeito P&L maior.
Diferenças locais: em algumas GEO, o canal «rápido, mas caro» paga melhor.

12) Incidente playbooks

1. Crescimento p95 por PSP/corredor específico

Auto-rerute para o corredor de reserva, redução do limite de degradação.
Comunicação aos jogadores com o ETA atualizado, tíquete no provedor.

2. Risk backlog (verificações manuais)

Incluir o pré-approval na soma de ≤ X, redistribuir a fila, elevar temporariamente as liminares auto-pass.

3. Banco posting atrasos em GEO

Contornar outro banco correspondente/carteira, desligar temporariamente o corredor «lento» para novas solicitações.

4. 3DS/ACS degradação (depósitos)

Forçar frictionless/alternate DS onde a política de risco permitir, ou cascata em outro PSP.

13) Testes A/B em torno do TTW

Corredor Instantâneo vs Standard em parte do tráfego (CBR bps, cost/payout, CSAT).
Pré-KYC copiar/flow, formulação ETA, ordem de métodos.
Métricas: TTW p95, SLA-hit%, tíquetes/1000 trx, AR/conversão, churn 7/30.

14) Best pratices (curta)

1. Mede as etapas e mantenha as marcas de tempo em um único padrão.
2. Otimize p95/p99, não apenas a mediana.
3. Incorpore o momento-rails onde a economia está convergindo.
4. Faça pre-KYC/SoF/approval para os cenários repetitivos.
5. Carro-cascata corredores e PSP, responda ao health.
6. Diga honesto ETA e estatais, alerta para atrasos.
7. Guarde o SLA no catálogo e verifique o SLA-hit% para cada corte.
8. Vincule o TTW a CSAT/tíquetes/churn em dashboards.
9. Pós-incidentes: Registre as causas, mude as regras/liminares.
10. Versionize o padrão de eventos e verifique a totalidade das marcas de tempo.

15) Folha de cheque de implementação

• Definições de TTW para depósitos/conclusões acordadas com o produto/finanças.
• Marcadores de tempo por etapa em 'payments. timeline`; Catálogo SLA.
• Dashboard p50/p95/p99, SLA-hit%, caudas; alert p95/tiles/backlogs.
• Cascatas PSP/corredores, health-feed e auto-failover.
• Políticas Pre-KYC/SoF e pré-approval; ND/same-method é automatizado.
• Comunicação ETA e status-rastreador para o usuário.
• Modelo econômico «velocidade ↔ preço» pelos corredores.
• Playbooks incidentes e processo pós-mortem.
• Testes A/B de melhorias do TTW com guardrails.
• Auditoria regular da totalidade dos dados e da correção dos cálculos.

Currículo

Time-to-Wallet não é apenas «velocidade de saída». É uma métrica de experiência de pagamento que afeta a conversão, retenção e P & L. Mede o TTW por etapa, otimize o p95/p99, conecta o momento-rails e cascatas, retire o atrito através do pré-KYC/approval e automatize a verificação ND/same-method. Telemetria forte, ETA honesto e playbooks prontos tornarão os pagamentos rápidos, previsíveis e economicamente justificáveis.