Time-to-Wallet - Metrica chiave

1) Definizione e varianti TTW

• clicca «Paga», i soldi sono disponibili per il gioco.
• Include UX/3DS, l'autorizzazione da PSP/banca, la conferma e la registrazione del saldo.

clicca «taglia» i soldi su un portafoglio o una banca esterna.
Include risk/KYC/SoF di controllo, same-method/ND-gate, l'orchestrazione del corridoio, la conferma da PSP/schema e il posting da banca/portafoglio.

2) Perché TTW è P & L-metrica

Conversione e AR: deposito rapido per la possibilità di prima puntata/sessione.
Ritenzione e fiducia: conclusioni rapide di churn e ticket zapport.
Il costo è spesso più costoso di un per il bilanciamento velocità-prezzo.
Rischio operatorio: le lunghe «code» di TTW creano cluster di incidenti e attrito-tensione.

3) Decomposizione TTW per fasi

3. 1. Depositi

1. UI/Checkout (render, validazione, 3DS)

2. PSP Auth (authorize)

3. Capture/Booking (conferma, aggiornamento del saldo)

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

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

3. 2. Conclusioni

1. Pre-checks (KYC/SoF, ND/same-method, limiti RG/AML)

2. Risk definizione (auto/manuale)

3. Payout orchestrazione (scelta del corridoio: 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 (conferma utente)

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

4) SLA e target

Deposito p95: 10-20 secondi (portafogli/one-tap), 30-60 secondi (carte con 3DS).

• Instant rails (SEPA Instant/PIX/FPS/RTP, push-to-wallet/card): ≤ 15–30 мин.
• Standard A2A/SEPA Credit: T + 0/T + 1 banking (ore/ore).
• SWIFT internazionali: 1-3 giorni bancari.
• p99 è importante tenere nelle comunicazioni (ETA-range) per gestire le aspettative.

5) Misura: unità, finestre, sampling

Unità di misura - Transazione (deposit/payout).
Aggregazione: p50/p90/p95/p99, SLA-hit% (quota di ETA), code (tail> 2 x p95).
Taglio: metodo/corridoio/PSP/MID/GEO/cluster BIN/ora/canale.
Escludete: disattivati/duplicati (idampotenza), pause manuali su richiesta del giocatore.

6) Modello dati (minimo)

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) Modelli di calcolo SQL

7. 1. TTW per depositi (comune e metodi)

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 di output (corridoi)

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. Decomposizione dei colli di bottiglia (conclusioni)

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-bricchi e «lunghe code»

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

TTW p50/p95/p99 per metodi/corridoi/PSP/GEO/BIN-cluster.
SLA-hit%, tail share (> 2 x p95), incidenti (annotazioni).
Vortice di conclusioni: Richiested Pre-check OK Risk OK Iniziated Posted d'Available.
Correlazioni: TTW vs AR/conversione deposito, TTW vs ticket sapport/CSAT, TTW vs churn.
Costo: «cost _ per _ payout» e «take-rate» per il corridoio vs vincita TTW.

9) Alert

p95 breach: p95 TTW per corridoio/PSP> SLA X minuti.
Tail spike: quota> 2 x p95 è aumentata> Y% in Z ore.
Pre-check stall: t _ precheck _ start c'è, t _ precheck _ ok no> 15 min (escalation automatica).
Risk backlog: t _ risk _ start c'è, t _ risk _ ok no> soglia (coda manuale).
Network/posting anataly: crescita drammatica dì network _ sec "per GEO/banca.
Policy drivt - Eventi senza le timeline necessarie.

10) Come accelerare TTW (pratiche)

Depositi

Portafogli One-tap/Apple Pay/Google Pay, network tokens.
Frictionless 3DS, incorporazione di 3DS nel modulo.
Cascata PSP per BIN/GEO/salute, retrai solo su soft-decline.
Canali Preferch 3DS/ACS, timeout aggressivi sul degrado.

Conclusioni

Pre-KYC/ pre-SoF per giocatori frequenti; pre-approval sull'importo della soglia ≤.
Corridoi: SEPA Instant/Faster Payments/RTP/PIX/push-to-card/wallet.
Cascata di corridoi: instant → fast A2A → SEPA/SWIFT standard (con ETA).
La logica Same-method & ND è automatizzata, senza controlli manuali.
Finestre temporanee: evitare cut-off e ore «strette» bancarie.
Provider health-feed e auto-failover alla crescita dì network _ sec '.

Comunicazioni

ETA all'inizio + Avanzamenti di stato (Verifica, Inizializzato, Iscritto).
Avvisi proactivi in caso di ritardo> SLA, giusti motivi e tempi previsti.

11) Economia e compromessi

Instant costa di più: confrontare l'uplift CSAT/churn/retence vs bps/fixed.
Le code sono più costose di p50: le ottimizzazioni per p95 danno un maggiore effetto P&L.
Differenze locali: in alcune GEO, il canale «veloce ma costoso» paga meglio.

12) Incidenti playbook

1. Crescita p95 per particolare PSP/corridoio

Auto-reroute per il corridoio di riserva, riduzione del limite di degrado.
Comunicazione ai giocatori con l'ETA aggiornato, ticket al provider.

2. Risk backlog (controlli manuali)

Abilita pre-approval sulle somme ≤ X, ridistribuisce la coda, alza temporaneamente le soglie auto-pass.

3. Banca posting ritardi GEO

Fare un giro con un'altra banca corrispondente/portafoglio, disattivare temporaneamente il corridoio «lento» per le nuove richieste.

4. 3DS/ACS degrado (depositi)

Forzare frictionless/alternate DS dove la politica di rischio è consentita o cascata su un altro PSP.

13) Test A/B intorno a TTW

Instant vs Standard corridoio su parte del traffico (guardrail: CCR bps, cost/payout, CSAT).
Copiato/flow pre-KYC, formulazione ETA, ordine dei metodi.
Metriche: TTW p95, SLA-hit%, tickets/1000 trx, AR/conversione, churn 7/30.

14) Best practices (breve)

1. Misurare le fasi e mantenere le timeline in un unico schema.
2. Ottimizza p95/p99, non solo la mediana.
3. Incorporare istant-rails dove l'economia si allinea.
4. Fate un pre-KYC/SoF/approval per gli scenari ripetitivi.
5. Auto-cascare corridoi e PSP, rispondere a health.
6. Parlate onestamente dell'ETA e degli stati, avvertite i ritardi.
7. SLA memorizza nella directory e controlla SLA-hit% per ogni taglio.
8. Collegare TTW a CSAT/ticet/churn nei dashboard.
9. Post-incidenti: fissa le cause, cambia le regole e i minutaggi.
10. Versionare lo schema degli eventi, convalidare la completezza delle etichette temporali.

15) Assegno-foglio di implementazione

• Definizioni TTW per depositi/conclusioni concordate con il prodotto/finanza.
• Timeout per fasi in 'payments. timeline`; Catalogo SLA.
• Dashboard p50/p95/p99, SLA-hit%, code; alert p95/tail/backlogs.
• Cascate PSP/corridoi, health-feed e auto-failover.
• Regole e criteri pre-approval ND/same-method sono automatizzati.
• Comunicazioni ETA e stato-tracciatore per l'utente.
• Modello economico «velocità-prezzo» lungo i corridoi.
• playbook di incidenti e processo post mortem.
• A/B test di miglioramento TTW con guardrail.
• Controllo regolare della completezza dei dati e della correttezza dei calcoli.

Riepilogo

Time-to-Wallet non è solo «velocità di output». Si tratta di una metrica completa di esperienza di pagamento che influisce sulla conversione, la ritenzione e P & L. Misurare TTW in base alle fasi, ottimizzare p95/p99, collegare istant-rails e cascate, rimuovere l'attrito attraverso pre-KYC/approval e automatizzare i controlli ND/same-method. La forte telemetria, l'ETA onesta e i playbook pronti renderanno i pagamenti veloci, prevedibili ed economicamente giustificabili.