La ricostruzione di Arbitrage: come abbiamo reso più intelligente lo scoring dei provider

Ogni OTP inviato da Prelude deve essere affidato a una delle aziende di una rete di provider SMS. Questa scelta avviene in una manciata di millisecondi, senza alcun intervento umano, e stabilisce quale provider consegnerà il messaggio. Scegliere tra questi provider, per ogni singolo messaggio, è ciò che in Prelude chiamiamo arbitraggio.

Per fare la scelta giusta, è fondamentale sapere quali provider consegnano davvero i messaggi. Ciascun fornitore di SMS dichiara i propri tassi di consegna. Tuttavia, questo dato non è confrontabile tra un operatore e l'altro, il che lo rende inutile come parametro per stabilire una graduatoria.

"I provider non forniscono i report di consegna nello stesso modo e alcuni hanno una propria definizione di cosa sia 'in transito' e cosa 'consegnato'", spiega Hugo Bauer, software engineer dell'infrastruttura di verifica di Prelude. "Trattandosi di una tecnologia ormai un po' datata, a seconda dei fornitori a cui ci si affida, i dati a disposizione possono rivelarsi imprecisi". 

Alcuni provider considerano l'SMS come consegnato non appena raggiunge l'antenna telefonica. Altri aspettano che arrivi effettivamente sul dispositivo. Questa mancanza di uniformità crea i presupposti per un problema ancora più serio: un provider consapevole che l'assegnazione del traffico dipende dal tasso di consegna ha tutto l'interesse a gonfiare quel valore. "Potrebbero barare aumentando i tassi di consegna per ottenere più traffico", sottolinea Hugo, "visto che distribuiamo il traffico tra diversi provider". La prima sfida, quindi, è stata superare queste discrepanze tra gli operatori di telecomunicazioni. 

Per questo il team di Prelude ha deciso di creare un proprio indicatore. L'API Verify include un endpoint /check che i clienti richiamano quando un utente inserisce il codice ricevuto. Se la verifica ha esito positivo, significa che il messaggio è arrivato, l'utente lo ha letto e ha digitato le cifre corrette. È ciò che definiamo conversione. Nessuna ambiguità, nessuna manipolazione possibile: o l'utente ha ricevuto il codice, o non l'ha ricevuto.

Questa scelta ha fornito a Prelude una base solida ed è la ragione per cui molti clienti si affidano a Prelude, dove la priorità assoluta è garantire che gli utenti riescano ad accedere, non far lievitare artificialmente il numero di SMS o i tentativi di invio.

Come funzionava il sistema originale

Inizialmente, il sistema di arbitraggio era volutamente essenziale. Per ciascun provider in ogni paese calcolava un punteggio che combinava tasso di conversione e prezzo. Un provider più economico poteva essere preferito a uno con una conversione migliore se la convenienza economica lo giustificava. È stato un ottimo punto di partenza e, per un certo periodo, si è dimostrato sufficiente.

Con l'ingresso di Hugo nel team, il sistema è stato perfezionato con un livello di dettaglio superiore, poiché emergevano discrepanze nelle prestazioni legate agli operatori e ai dispositivi. "Abbiamo iniziato a raccogliere molti più segnali e ad aumentare la granularità", racconta Hugo. "Prima avevamo solo statistiche su scala nazionale, poi abbiamo introdotto il dettaglio per operatore e dispositivo, perché per qualche ragione gli SMS venivano recapitati con minore frequenza su specifici modelli Android o iOS". La logica di fondo è rimasta invariata, ma la valutazione è diventata molto più precisa: da un punteggio per provider per nazione si è passati a un punteggio per provider, per operatore e per tipo di dispositivo. 

Successivamente, con l'acquisizione di un importante cliente e-commerce, è emerso un limite strutturale impossibile da ignorare: un unico punteggio di conversione condiviso tra tutti i clienti di un determinato provider non è in grado di distinguere gli utenti che convertono in modo diverso per ragioni del tutto indipendenti dal provider stesso.

Un caso d'uso mai affrontato dal modello

La maggior parte dei clienti di Prelude impiegava gli OTP per l'accesso o la registrazione degli account. Questo nuovo cliente, invece, inseriva il passaggio OTP alla fine del checkout, come conferma finale prima di completare l'acquisto.

Una differenza che si è riflessa subito nei dati. "Il prodotto Prelude Verify veniva utilizzato principalmente per consentire agli utenti di accedere a una piattaforma", spiega Hugo. Per gli utenti finali di questo cliente, invece, il contesto era completamente diverso. "Lo usavano al termine del processo d'acquisto per confermare l'ordine. Di conseguenza, il loro tasso di conversione era nettamente inferiore: diversi utenti richiedevano l'OTP ma poi non inserivano il codice, semplicemente perché avevano cambiato idea".

Non si trattava di un mancato recapito del messaggio: l'utente aveva solo deciso di non procedere con l'acquisto. I processi di checkout comportano fisiologicamente un tasso di abbandono che non esiste nei flussi di login. Una percentuale di acquirenti rinuncia all'acquisto tra l'aggiunta di un articolo al carrello e la conferma definitiva, a prescindere dalla corretta ricezione dell'OTP. Questa perdita si verifica indipendentemente dall'effettiva consegna dell'SMS.

Il volume generato da questo cliente rappresentava una quota rilevante del traffico complessivo di Prelude in alcuni mercati minori. Con un peso simile, il suo tasso di conversione strutturalmente più basso ha finito per deprimere la media condivisa di ogni singolo provider. Il sistema di arbitraggio ha reagito dirottando il traffico verso la seconda scelta migliore, ma anche il punteggio di quest'ultimo è crollato per lo stesso motivo. "Il sistema non era compromesso, ma lavorava con dati imprecisi", chiarisce Hugo.

Cosa ha rivelato questo incidente

L'episodio legato a questo grande cliente ha fatto emergere tre dinamiche preesistenti ma rimaste fino ad allora sotto traccia.

Frodi. I tentativi di frode generano richieste di OTP che non verranno mai inseriti. Nelle rare circostanze in cui il traffico fraudolento riesce a superare i livelli di rilevamento, questi tentativi non convertiti penalizzano inevitabilmente il provider che li gestisce. "Quando un tentativo elude i controlli, di norma la frode non converte", spiega Hugo. "Inviamo quindi tentativi tramite i provider senza mai ricevere la convalida di verifica. Il risultato è un calo della conversione complessiva per quegli operatori". Il provider con il posizionamento migliore è il primo a subire il colpo: il suo punteggio crolla, il traffico viene spostato su quello successivo e l'attacco lo segue a ruota.

Per scoprire come Prelude individua e contrasta le frodi basate su agenti, consulta il nostro articolo precedente della serie dedicata all'ingegneria.

Filtraggio dei mittenti (Sender ID). Prelude registra i Sender ID presso gli operatori per consentire ai clienti di inviare SMS con il nome del proprio brand. Tuttavia, alcuni carrier bloccano i nomi ritenuti potenzialmente ingannevoli e, quando questo accade, l'anomalia resta invisibile all'interno delle metriche aggregate. 

Un cliente utilizzava un nome commerciale che conteneva un termine molto comune nel settore retail. Alcuni operatori avevano inserito quel termine in blacklist, poiché i truffatori ricorrono spesso a denominazioni generiche per fingersi store e-commerce. Di conseguenza, i messaggi del cliente non venivano recapitati da quegli operatori specifici. Tuttavia, le statistiche globali del provider non mostravano anomalie, dato che solo una frazione del traffico complessivo transitava su quelle tratte.

"Soltanto pochi operatori filtravano quel nome, quindi il problema non emergeva da nessuna delle analisi complessive", ricorda Hugo. "Il fornitore sembrava funzionare senza intoppi su quegli operatori perché il traffico degli altri clienti passava regolarmente, e il cliente sembrava non avere problemi in quel paese perché gli altri carrier consegnavano. L'anomalia diventa evidente solo isolando il singolo cliente sul singolo operatore: a quel punto non si tratta di un calo marginale, ma di un vero e proprio blocco totale". 

Metriche di base per tipologia di cliente. Alcuni clienti presentano tassi di conversione fisiologicamente più bassi rispetto ad altri, non per inefficienze del provider, ma per la natura stessa del loro prodotto. Un istituto bancario che richiede l'autenticazione converte diversamente rispetto a un'app di e-commerce che chiede la conferma di un pagamento. "In media, si riscontra una variabilità sulla stessa rotta", evidenzia Hugo. "Per rotta intendiamo un provider in un determinato paese, e tra i diversi clienti si registra una forbice di circa il 10%". In pratica, il Cliente A e il Cliente B potrebbero servirsi dello stesso operatore nello stesso paese e registrare una differenza di 10 punti percentuali nel tasso di conversione. Non perché uno riceva un servizio migliore dell'altro, ma per le abitudini d'uso dei rispettivi utenti. Stesso provider, stesso paese, 10 punti di scarto: il punteggio finiva per descrivere il comportamento dei clienti, non l'efficacia del fornitore.

In tutti e tre i casi la conclusione era la medesima: una media aggregata non consentiva di distinguere se un provider stesse rendendo poco o se stesse semplicemente gestendo clienti con una propensione alla conversione differente.

Verso un modello più evoluto

Primo tentativo: limitare il peso del singolo cliente

La prima reazione è stata quella di contenere l'influenza del singolo cliente sul punteggio comune. L'idea era semplice: se un cliente rappresenta la metà del traffico di un paese, se ne limita l'impatto.

Questo approccio, tuttavia, presentava un forte vincolo intrinseco. "Finivamo semplicemente per escludere una quantità enorme di dati", spiega Hugo. "Nei paesi in cui due o tre clienti concentrano quasi tutto il traffico, limitare il volume dei dati per cliente rischia di rendere le statistiche globali poco attendibili per mancanza di campioni sufficienti".

In teoria, la soglia massima preservava l'integrità del punteggio aggregato; nella pratica, comportava lo scarto della maggior parte delle informazioni di traffico. Un indicatore basato su un campione ridotto e non rappresentativo non è più affidabile di uno calcolato su dati alterati. In sostanza, un problema era stato scambiato con un altro.

Secondo tentativo: ranking separati per ciascun cliente

Il tentativo successivo è consistito nel creare un modello dedicato per ogni grande cliente, alimentato unicamente dai suoi dati storici.

Questa soluzione ha portato a un miglioramento concreto e tangibile. "Analizzando solo i loro dati, siamo riusciti a individuare gli operatori che non recapitavano i messaggi a causa dei problemi di registrazione del mittente", osserva Hugo. "Il sistema ha iniziato così a selezionare in automatico provider alternativi". Isolare i dati del singolo cliente ha reso visibile per la prima volta il problema legato al Sender ID.

Tuttavia, si è creato un nuovo ostacolo per i clienti di minori dimensioni. "L'algoritmo ha bisogno di grandi volumi di dati per funzionare a dovere", chiarisce Hugo, "e affidandosi solo ai dati del singolo account, se questo genera poco traffico le statistiche sono insufficienti. Mancava la necessaria affidabilità sul risultato, finendo per selezionare i provider sbagliati".

Il dilemma era chiaro: i dati per singolo cliente offrono precisione qualitativa a discapito dei volumi; i dati aggregati garantiscono grandi volumi ma perdono nitidezza.

Il sistema attuale: attingere ai dati globali, ottimizzare le probabilità

Un cliente senza uno storico significativo sfrutta i dati aggregati dell'intera piattaforma, per poi fare sempre più affidamento sui propri man mano che il volume cresce. Di conseguenza, il traffico viene distribuito tra i provider in proporzione alla probabilità che ciascuno risulti il migliore, anziché assegnarlo in blocco a una singola scelta.

"Abbiamo sviluppato una formula per valorizzare le statistiche aggregate", prosegue Hugo. "Più traffico generano, più dati abbiamo a disposizione e più utilizziamo i loro specifici parametri, mantenendo comunque come riferimento il dato globale. È un modello ibrido tra statistiche generali e dati del cliente: man mano che questi ultimi aumentano, acquistano maggior peso sul punteggio".

Il passaggio avviene in modo graduale e continuativo, senza soglie rigide: non c'è un momento di transizione netta in cui il modello stravolge la logica di calcolo.

Hugo illustra il concetto con un esempio pratico: "Ipotizziamo l'onboarding di un nuovo cliente e-commerce. Il primo aspetto critico è che i suoi tassi di conversione base saranno inferiori alla nostra media di riferimento. Il secondo è che, partendo da zero, non ha ancora volumi di traffico, quindi non possiamo basarci sulle sue statistiche. Iniziamo impiegando le metriche globali e, di pari passo con la crescita del suo traffico, integriamo progressivamente i suoi dati con quelli generali".

La ponderazione si fonda sull'attendibilità statistica anziché su scaglioni arbitrari. "I dati di un provider che registra appena dieci tentativi al giorno non sono statisticamente significativi", chiarisce Hugo. "Il grado di confidenza è insufficiente. Nel nuovo sistema abbiamo implementato una formula matematica che calcola questo livello di affidabilità, su cui basiamo la selezione dei provider. Più dati raccogliamo, più siamo certi delle effettive prestazioni del fornitore". 

"Per i clienti con volumi più contenuti continuiamo ad attingere alle statistiche globali", aggiunge Hugo. "In questo modo l'infrastruttura risponde efficacemente a entrambe le esigenze".

Dove i clienti percepiscono davvero il cambiamento

Volendo descrivere l'impatto quotidiano con la massima trasparenza, il vero valore aggiunto risiede nella resilienza, più che in un incremento immediato delle metriche.

"Nell'operatività di tutti i giorni non si notano variazioni eclatanti", osserva Hugo. "Forse un lieve miglioramento del tasso di conversione, ma parliamo di differenze marginali, intorno a mezzo punto percentuale. Il reale vantaggio emerge in presenza di un guasto tecnico di un provider, di un problema di registrazione o di un attacco fraudolento non intercettato: il sistema reagisce e si adatta all'istante".

Il disservizio registrato a carico di un provider lo scorso agosto ne è una prova tangibile. Prelude stava eseguendo in parallelo il vecchio e il nuovo sistema, consentendo un confronto diretto. "Abbiamo riscontrato un'anomalia con un provider che aveva smesso di consegnare qualsiasi messaggio", spiega Hugo, "e il nuovo motore ha gestito la situazione molto meglio del precedente, passando da un operatore all'altro con maggiore tempestività. La stabilità del tasso di conversione in caso di incidenti è nettamente superiore".

In passato, garantire questa continuità richiedeva interventi manuali. "Con la prima versione dell'arbitraggio monitoravamo l'andamento e rilevavamo le anomalie, ma il sistema non rispondeva in modo opportuno. Dovevamo escludere manualmente determinate rotte per contenere le ripercussioni sulla conversione dei clienti; oggi l'intero processo è completamente automatizzato".

Oltre i punti ciechi: i prossimi passi

Resta ancora aperta una sfida: clienti diversi hanno tassi di conversione di base differenti, a prescindere dal provider che ne instrada i volumi.

"Ogni cliente ha dinamiche proprie", afferma Hugo. "Un'applicazione fintech non si comporta come una piattaforma e-commerce. Per questo misuriamo i tassi di conversione specifici per cliente in modo da individuare la loro metrica di riferimento: questo ci consente di valutare l'impatto effettivo di ogni fornitore in modo indipendente, senza fermarci al solo tasso di conversione lordo".

Il prossimo obiettivo consiste nel calcolare il valore di base proprio di ciascun cliente, depurarlo dalle metriche rilevate e confrontare i provider solo sui dati al netto di questa componente. "Non è una mera questione di volumi", conclude Hugo. "Rientra in gioco anche il modo in cui gli utenti interagiscono con la piattaforma, con ricadute dirette sul percorso di autenticazione e sui tassi finali di conversione".

Lo sviluppo è attualmente in corso e l'architettura tecnica per supportarlo è già pienamente operativa.

Hugo Bauer è un software engineer di Prelude, specializzato in infrastrutture di verifica e sistemi di routing.

Questo articolo fa parte della serie di Prelude dedicata all'ingegneria, in cui il team racconta come nascono e si evolvono i nostri prodotti. Continua a leggere sul nostro blog o inizia subito a usare Prelude.