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

Ogni OTP che Prelude invia deve essere affidato a una delle aziende di una rete di servizi SMS. Questa scelta avviene in frazioni di secondo, senza alcun intervento umano, e stabilisce quale provider consegnerà il messaggio. La scelta tra questi provider, per ogni singolo messaggio, è ciò che Prelude chiama arbitraggio.

Per fare questa scelta al meglio, occorre sapere quali provider consegnano effettivamente i messaggi. Ogni provider SMS vi dirà i propri tassi di consegna. Questo numero non è paragonabile da un provider all'altro, il che lo rende inutile come segnale di classificazione.

"Ogni provider non fornisce il report di consegna nello stesso modo e alcuni hanno una propria definizione di cosa sia in transito e cosa sia consegnato", spiega Hugo Bauer, ingegnere del software dell'infrastruttura di verifica di Prelude. "Poiché l'SMS è una tecnologia legacy, a seconda dei provider potremmo disporre di dati imprecisi”. 

Alcuni provider considerano l'SMS consegnato quando raggiunge il ripetitore telefonico. Altri aspettano che arrivi al telefono stesso. Questa incoerenza apre la strada a qualcosa di peggio: un provider che sa che il traffico viene assegnato in base al tasso di consegna ha tutto l'interesse a gonfiare quel numero. "Potrebbero imbrogliare aumentando i tassi di consegna per ottenere più traffico", spiega Hugo, "perché noi dividiamo il traffico tra i provider". La prima sfida, quindi, consisteva nel superare queste discrepanze tra gli operatori telefonici. 

Così il team di Prelude ha deciso di creare un proprio segnale. La Verify API include un endpoint /check che i clienti chiamano quando un utente inserisce il proprio codice. Una verifica riuscita significa che il messaggio è arrivato, l'utente lo ha letto e ha digitato di nuovo le cifre corrette. Questo è ciò che chiamiamo conversione. Nessuna ambiguità, nessuna manipolazione. L'utente ha ricevuto il codice o non l'ha ricevuto.

Questa decisione ha dato a Prelude una base affidabile ed è il motivo per cui molti clienti si fidano di Prelude, dove l'attenzione è rivolta all'accesso degli utenti e non a gonfiare il numero di SMS o di tentativi.

Come funzionava il sistema originale

Il sistema di arbitraggio originale era semplice per definizione. Per ogni provider in ogni paese, calcolava un punteggio combinando il tasso di conversione e il prezzo. Un provider più economico poteva batterne uno con conversioni migliori se la convenienza economica lo giustificava. Era un buon punto di partenza e, per un certo periodo, è stato sufficiente.

Quando Hugo è entrato nel team, si è passati a una maggiore granularità. Le differenze di prestazioni cominciavano a manifestarsi a livello di operatore e di dispositivo. "Abbiamo iniziato a ricevere molti più segnali e ad aggiungere granularità", racconta Hugo. "Prima avevamo solo statistiche a livello nazionale, poi abbiamo aggiunto la granularità dell'operatore e del dispositivo, perché per qualche motivo gli SMS venivano recapitati meno su alcuni specifici dispositivi Android o iOS". La logica è rimasta la stessa, ma il punteggio è diventato molto più granulare: da un punteggio per provider per paese si è passati a un punteggio per provider, per operatore, per tipo di dispositivo. 

Poi è arrivato un grande cliente di e-commerce e una lacuna in questo approccio è diventata impossibile da ignorare: un singolo punteggio di conversione condiviso tra tutti i clienti su un unico provider non è in grado di distinguere tra i clienti che convertono in modo diverso per motivi che non hanno nulla a che fare con il provider.

Un caso d'uso mai visto prima dal modello

La maggior parte dei clienti di Prelude utilizzava gli OTP per l'accesso o la registrazione dell'account. Questo cliente ha inserito la fase OTP alla fine del flusso di checkout, come conferma finale prima di completare un acquisto.

Questa differenza si è riflessa direttamente nei numeri. "Il prodotto Prelude Verify veniva utilizzato principalmente per consentire agli utenti di accedere a una piattaforma", spiega Hugo. Per gli utenti finali di questo particolare cliente, si trattava di un caso d'uso completamente diverso. "Lo usavano alla fine del flusso di acquisto per confermare un ordine. Quindi il loro tasso di conversione era molto più basso, perché alcuni utenti richiedevano gli OTP ma poi non inserivano il codice. Cambiavano idea".

Non si trattava di una mancata ricezione del messaggio da parte dell'utente. Avevano semplicemente deciso di non acquistare. I flussi di checkout registrano un tasso di abbandono che l'accesso non ha mai. Una certa percentuale di acquirenti abbandona l'acquisto tra l'aggiunta di un articolo al carrello e la conferma, indipendentemente dall'arrivo dell'OTP. Questo calo avviene a prescindere dal fatto che l'SMS venga consegnato o meno.

Questo cliente inviava una quantità di traffico tale da rappresentare una quota importante del volume di Prelude in alcuni mercati minori. Con questo peso, il loro tasso di conversione strutturalmente più basso trascinava verso il basso la media condivisa per ogni provider. Il sistema di arbitraggio reagiva spostando il traffico verso il provider successivo migliore. Il punteggio di quel provider scendeva quindi per lo stesso motivo. "L'intero sistema non era rotto, ma era impreciso", dice Hugo.

Cosa ha rivelato un singolo incidente

L'incidente del grande cliente si è rivelato una finestra su tre dinamiche che erano sempre state presenti.

Frode. Gli attacchi di frode generano richieste di OTP che non verranno mai inserite. Nelle rare occasioni in cui il traffico fraudolento supera i sistemi di rilevamento, questi tentativi non convertiti trascinano verso il basso il provider che li gestisce. "Quando passa, di solito la frode non si converte", spiega Hugo. "Quindi inviamo tentativi con i provider ma non riceveremo mai le verifiche. In questo modo la conversione globale cala per quei provider". Il provider con il punteggio migliore viene colpito per primo. Il suo punteggio crolla. Il traffico si sposta su quello successivo. L'attacco prosegue.

Se desideri approfondire il modo in cui Prelude rileva e risponde alle frodi gestite da agenti, leggi il nostro articolo precedente della serie engineering.

Filtro del Sender ID. Prelude registra i Sender ID presso gli operatori in modo che i clienti possano inviare SMS con il proprio nome del brand. Ma alcuni operatori bloccano i nomi che considerano potenzialmente ingannevoli e, quando lo fanno, questo fenomeno è invisibile nei numeri globali. 

Un cliente aveva un nome del brand che includeva un termine comune del settore retail. Alcuni operatori avevano inserito quel termine nella loro blocklist perché i truffatori usano spesso nomi generici che richiamano il commercio al dettaglio per impersonare aziende di e-commerce. I messaggi del cliente non venivano recapitati affatto tramite quegli operatori, ma le statistiche globali per il provider sembravano buone, perché solo una frazione del loro traffico totale passava per le rotte interessate.

"Solo pochi operatori filtravano quel nome, quindi non risultava nulla a nessun livello di nostra analisi", spiega Hugo. "Il provider sembrava a posto su quegli operatori perché passavano altri clienti, e il cliente sembrava a posto in quel paese perché gli altri operatori consegnavano. Lo vedi solo quando guardi un cliente su un operatore, e a quel punto non è un piccolo calo, è un muro". 

Linee di base dei clienti. Alcuni clienti convertono semplicemente a tassi inferiori rispetto ad altri, non per colpa del provider, ma per il funzionamento del loro prodotto. Una banca che chiede agli utenti di autenticarsi converte in modo diverso da un'app di e-commerce che chiede di confermare un acquisto. "In media, c'è una differenza sulla stessa rotta", dice Hugo. "Una rotta è un provider in un paese e c'è circa il 10% di differenza tra i clienti". In altre parole, il Cliente A e il Cliente B potrebbero inviare messaggi tramite lo stesso provider nello stesso paese e i loro tassi di conversione potrebbero differire di 10 punti percentuali, non perché uno riceva consegne migliori dell'altro, ma perché i loro utenti si comportano diversamente. Stesso provider, stesso paese, un divario di 10 punti. Il punteggio descriveva i clienti, non il provider.

Il risultato in tutti e tre i casi: la media condivisa non aveva modo di distinguere se "questo provider non sta offrendo buone prestazioni" o se "questo provider si trova a servire clienti che convertono in modo diverso".

Costruire un modello migliore

Tentativo 1: Porre un limite al contributo del cliente

Il primo istinto è stato quello di limitare l'influenza di un singolo cliente sul punteggio condiviso. Se un cliente rappresenta la metà del traffico di un paese, se ne limita il peso.

Questo approccio presentava un vincolo fondamentale. "Stiamo solo eliminando molti dati dall'equazione", afferma Hugo. "In alcuni paesi in cui pochi clienti rappresentano la maggior parte del traffico, se limitiamo la quantità di dati per cliente, le statistiche globali potrebbero essere troppo imprecise a causa della mancanza di dati".

In teoria, il limite proteggeva l'integrità del punteggio condiviso. In pratica, significava scartare la maggior parte dei dati sul traffico, e un punteggio basato su un campione ridotto e non rappresentativo non è più affidabile di uno basato su dati distorti. Si è scambiato un problema con un altro.

Tentativo 2: Classificazioni separate per cliente

L'approccio successivo ha dato a ogni grande cliente un proprio modello dedicato, costruito interamente sulla base dei propri dati.

Questo ha prodotto un guadagno reale e concreto. "Poiché utilizzavamo solo i loro dati, stavamo trovando alcuni operatori che non consegnavano a causa di questo problema di registrazione", spiega Hugo. "Il sistema utilizzava automaticamente altri provider". L'isolamento dei dati di un cliente ha reso visibile per la prima volta il problema del suo Sender ID.

Ma questo creava un problema diverso per i clienti più piccoli. "Il sistema ha bisogno di molti dati per funzionare bene", spiega Hugo, "e se si usano solo i dati del cliente, se questo non ha abbastanza traffico, le statistiche sono troppo ridotte. Non siamo abbastanza sicuri del risultato. Quindi finivamo per scegliere i provider sbagliati".

Il problema era reale: i dati per singolo cliente offrono segnali precisi ma perdono in volume. I dati condivisi offrono volume ma perdono precisione nel segnale.

Il sistema attivo: Prendere in prestito i dati, scommettere sulle probabilità

Un cliente che non ha uno storico consistente prende in prestito i dati collettivi e si affida maggiormente ai propri man mano che li accumula. Il traffico si distribuisce quindi tra i provider in proporzione alla probabilità che ciascuno di essi sia il migliore, anziché confluire su un unico vincitore.

"Abbiamo deciso di applicare una formula per utilizzare le statistiche globali", spiega Hugo, "e più traffico ottengono, più dati hanno e più usiamo i loro dati. Ma continuiamo a usare anche quelli globali. Si tratta di un mix di dati globali e dati del cliente, e quanti più dati ha il cliente, tanto maggiore è l'impatto sul punteggio".

La transizione è continua, non è una soglia netta. Non c'è un momento in cui il modello cambia bruscamente.

Hugo fa un esempio concreto: "Mettiamo il caso che arrivi un nuovo cliente di e-commerce. Il primo problema è che i suoi tassi di conversione di base saranno inferiori ai nostri tassi di conversione di base. E il secondo problema è che, all'inizio, non ha affatto traffico. Quindi non possiamo fare affidamento sulle sue statistiche. Inizieremo con le statistiche globali e, man mano che il traffico aumenterà, una quota maggiore sarà utilizzata in un mix tra i dati globali e i suoi dati".

La ponderazione si basa sulla confidenza statistica piuttosto che su livelli arbitrari. "Un provider che fa solo dieci tentativi al giorno non ha dati statisticamente affidabili", spiega Hugo. "Quindi la confidenza dei dati non è abbastanza forte. Nel nuovo sistema, abbiamo creato una formula matematica che calcola questa confidenza. In base alla confidenza, sceglieremo i provider. Più dati avremo, più saremo sicuri delle prestazioni del provider". 

"Per i clienti più piccoli continuiamo a usare le statistiche globali", aggiunge Hugo. "In questo modo il sistema funziona per entrambi".

Dove si nota effettivamente la differenza per i clienti

La descrizione più onesta dell'impatto quotidiano è la resilienza, non l'aumento delle prestazioni.

"Su base giornaliera non si notano grandi miglioramenti", dice Hugo. "Forse un piccolo miglioramento del tasso di conversione, ma è minimo, forse mezzo punto. Il miglioramento si vede se c'è un problema tecnico con un provider, un problema di registrazione o qualcosa del genere, o un attacco di frode che non viene rilevato. Il sistema si comporterà e si adatterà di conseguenza".

L'interruzione del servizio di un provider ad agosto rende concreta la differenza. Prelude faceva girare il vecchio e il nuovo sistema in parallelo, il che ha reso il confronto diretto. "Abbiamo avuto un problema con un provider che non consegnava alcun messaggio", racconta Hugo, "e il nuovo sistema si sta adattando decisamente meglio del precedente. Il sistema passa da un provider all'altro più rapidamente. Il tasso di conversione è più stabile in caso di incidente".

Prima di questo, la stabilità richiedeva un lavoro manuale. "Quando la prima versione dell'arbitraggio era attiva, avevamo dei sistemi di monitoraggio e vedevamo i problemi, ma l'arbitraggio non reagiva correttamente. Così chiudevamo le rotte manualmente per limitare l'impatto sui tassi di conversione per i nostri clienti, mentre ora è automatico".

Lavorare al buio: Il tassello successivo

Un problema rimane aperto: clienti diversi hanno tassi di conversione di base differenti, a prescindere dal provider che gestisce il loro traffico.

"Ogni cliente si comporta in modo diverso", spiega Hugo. "Un'app fintech rispetto a un'app di e-commerce. Quindi misuriamo i tassi di conversione per cliente per sapere qual è il loro tasso di conversione di base, in modo da poter conoscere l'impatto di ciascun provider in modo indipendente, senza guardare solo ai tassi di conversione".

Il passo successivo consiste nel misurare il valore di riferimento di ciascun cliente, rimuoverlo da quanto osservato da quel cliente e confrontare i provider su ciò che rimane. "Non è una questione di volume", spiega Hugo. "Riguarda anche il modo in cui i loro utenti si comportano sulla loro applicazione, perché questo può influire sul loro flusso di accesso e sui loro tassi di conversione".

Questo lavoro è in corso. L'architettura per supportarlo è pronta.

Hugo Bauer è un ingegnere del software presso Prelude, dove si occupa di infrastrutture di verifica e sistemi di instradamento.

Questo articolo fa parte della serie di ingegneria di Prelude, in cui il team condivide il modo in cui viene costruito il prodotto. Scopri di più sul blog o inizia a usare Prelude.