Reconstrucción del arbitraje: cómo optimizamos nuestro scoring de proveedores

Cada OTP que envía Prelude debe entregarse a una de las empresas de la red de SMS. Esa elección ocurre en milisegundos, sin intervención humana, y determina qué proveedor entrega el mensaje. Elegir entre esos proveedores, para cada mensaje individual, es lo que en Prelude llamamos arbitraje.

Para elegir bien, necesitas saber qué proveedores entregan de verdad. Cada proveedor de SMS te dirá sus tasas de entrega. Pero esa cifra no es comparable entre proveedores, lo que la hace inútil como señal de clasificación.

"Cada proveedor genera el reporte de entrega a su manera, y algunos tienen su propia definición de lo que está en tránsito y lo que está entregado", explica Hugo Bauer, ingeniero de software en la infraestructura de verificación de Prelude. "Como el SMS es una tecnología algo heredada, dependiendo del proveedor, podemos recibir datos imprecisos”. 

Algunos proveedores cuentan el SMS como entregado en cuanto llega a la antena de telefonía. Otros esperan a que llegue al propio dispositivo. Esa inconsistencia abre la puerta a algo peor: un proveedor que sabe que el tráfico se asigna según la tasa de entrega tiene incentivos para inflar ese número. "Pueden hacer trampa aumentando las tasas de entrega para recibir más tráfico", detalla Hugo, "porque dividimos el tráfico entre proveedores”. El primer reto, por tanto, era superar estas discrepancias entre operadoras. 

Así que el equipo de Prelude decidió crear su propia señal. La API de verificación (Verify API) incluye un endpoint /check que los clientes llaman cuando un usuario introduce su código. Un chequeo exitoso significa que el mensaje llegó, el usuario lo leyó y escribió los dígitos correctos. Eso es lo que llamamos conversión. Sin ambigüedades, sin manipulación. El usuario recibió el código o no lo recibió.

Esa decisión le dio a Prelude una base sólida, y es la razón por la que muchos clientes confían en Prelude, donde el foco está en que los usuarios accedan, no en inflar el conteo de SMS o de intentos.

Cómo funcionaba el sistema original

El sistema de arbitraje original era simple por diseño. Para cada proveedor en cada país, calculaba una puntuación que combinaba tasa de conversión y precio. Un proveedor más barato podía superar a uno con mejor conversión si la economía lo justificaba. Fue un buen punto de partida y, durante un tiempo, fue suficiente.

Cuando Hugo se unió, el equipo aportó más precisión. Empezaron a aparecer diferencias de rendimiento a nivel de operadora y dispositivo. "Comenzamos a recibir muchas más señales y a añadir granularidad", dice Hugo. "Antes solo teníamos estadísticas a nivel de país, pero luego añadimos la operadora y el dispositivo, porque por alguna razón los SMS se entregaban menos en ciertos dispositivos Android o iOS específicos". La lógica seguía siendo la misma, pero la puntuación ahora era mucho más detallada: una puntuación por proveedor y país pasó a ser una puntuación por proveedor, operadora y tipo de dispositivo. 

Entonces se unió un gran cliente de comercio electrónico y una brecha en ese enfoque se hizo imposible de ignorar: una única puntuación de conversión compartida entre todos los clientes de un proveedor no permite distinguir a los clientes que convierten de manera diferente por razones ajenas al propio proveedor.

Un caso de uso que el modelo no había previsto

La mayoría de los clientes de Prelude usaban OTP para iniciar sesión o registrar cuentas. Este cliente colocó el paso de OTP al final de su proceso de compra, como confirmación final antes de completar el pago.

Esa diferencia se reflejó directamente en los números. "El producto Verify de Prelude se usaba principalmente para permitir que los usuarios iniciaran sesión en una plataforma", explica Hugo. Para los usuarios finales de este cliente en particular, el caso de uso era totalmente distinto. "Lo usaban al final del proceso de compra para confirmar un pedido. Por eso su tasa de conversión era mucho menor: algunos de sus usuarios solicitaban la OTP pero luego no la introducían. Simplemente cambiaban de opinión".

No es que el usuario no hubiera recibido el mensaje. Simplemente decidió no comprar. Los procesos de pago sufren un abandono que el inicio de sesión no tiene. Un porcentaje de compradores abandona la compra entre añadir un artículo al carrito y confirmarlo, independientemente de si llega la OTP o no. Esa caída ocurre igual, se entregue o no el SMS.

Este cliente enviaba suficiente tráfico como para representar una gran parte del volumen de Prelude en algunos mercados pequeños. Con ese peso, su tasa de conversión estructuralmente más baja arrastró hacia abajo el promedio compartido de todos los proveedores. El sistema de arbitraje reaccionó desviando el tráfico al siguiente mejor proveedor. La puntuación de ese proveedor cayó entonces por la misma razón. "El sistema en sí no estaba roto, pero era impreciso", dice Hugo.

Lo que reveló un incidente

El incidente con este gran cliente resultó ser una ventana a tres patrones que siempre habían estado ahí.

Fraude. Los ataques de fraude generan solicitudes de OTP que nunca se introducirán. En las raras ocasiones en que el tráfico fraudulento supera las capas de detección, esos intentos no convertidos perjudican al proveedor que los transporta. "Cuando pasa el filtro, normalmente el fraude no convierte", explica Hugo. "Así que enviamos intentos con proveedores pero nunca recibimos confirmaciones. La conversión global cae para esos proveedores". El proveedor mejor posicionado recibe el impacto primero. Su puntuación se desploma. El tráfico pasa al siguiente. Y el ataque lo sigue.

Echa un vistazo a nuestro artículo anterior de la serie de ingeniería si quieres explorar cómo Prelude detecta y responde al fraude automatizado.

Filtrado de Sender ID. Prelude registra los nombres de remitente (sender IDs) con las operadoras para que los clientes puedan enviar SMS con su marca. Pero algunas operadoras bloquean nombres que consideran potencialmente engañosos, y cuando lo hacen, esto resulta invisible en las cifras globales. 

Un cliente tenía un nombre de marca que incluía un término comercial común. Ciertas operadoras habían puesto ese término en su lista negra porque los estafadores suelen usar nombres genéricos para suplantar a tiendas online. Los mensajes de este cliente no se entregaban a través de esas operadoras, pero las estadísticas globales del proveedor parecían correctas porque solo una fracción de su tráfico total pasaba por las rutas afectadas.

"Solo unas pocas operadoras filtraban ese nombre, por lo que no se veía nada en los niveles que analizábamos", dice Hugo. "El proveedor parecía funcionar bien en esas operadoras porque otros clientes pasaban, y el cliente parecía estar bien en ese país porque las otras operadoras sí entregaban. Solo lo ves cuando analizas un cliente específico en una operadora concreta; y entonces no es una pequeña caída, es un muro". 

Líneas base de los clientes. Algunos clientes simplemente convierten a tasas más bajas que otros, no por culpa del proveedor, sino por cómo funciona su producto. Un banco que pide autenticación convierte de forma diferente a una app de comercio electrónico que pide confirmar una compra. "De media, hay diferencia en la misma ruta", dice Hugo. "Una ruta es un proveedor en un país, y hay alrededor de un 10% de dispersión entre clientes". En otras palabras, el Cliente A y el Cliente B podrían enviar a través del mismo proveedor en el mismo país, y sus tasas de conversión diferir en 10 puntos porcentuales; no porque uno tenga mejor entrega, sino porque sus usuarios se comportan de otra manera. Mismo proveedor, mismo país, 10 puntos de diferencia. La puntuación describía a los clientes, no al proveedor.

El resultado en los tres casos: el promedio compartido no tenía forma de distinguir si "este proveedor rinde mal" o si "este proveedor resulta que da servicio a clientes que convierten de otra manera".

Construyendo un modelo mejor

Intento 1: Limitar la contribución del cliente

El primer instinto fue limitar cuánto podía influir un solo cliente en la puntuación compartida. Si un cliente representa la mitad del tráfico de un país, se limita su peso.

Este enfoque tenía una limitación fundamental. "Simplemente estábamos quitando muchos datos de la ecuación", dice Hugo. "En algunos países donde un par de clientes concentran la mayor parte del tráfico, si limitamos la cantidad de datos por cliente, las estadísticas globales pueden volverse demasiado imprecisas por falta de información".

El límite protegía la integridad de la puntuación compartida en teoría. En la práctica, significaba descartar la mayor parte de los datos de tráfico, y una puntuación basada en una muestra pequeña y poco representativa no es más fiable que una basada en datos sesgados. Se cambiaba un problema por otro.

Intento 2: Clasificaciones separadas por cliente

El siguiente enfoque dio a cada gran cliente su propio modelo dedicado, construido enteramente con sus propios datos.

Esto generó una mejora real y concreta. "Al usar solo sus datos, detectamos operadoras que no entregaban debido a este problema de registro", dice Hugo. "El sistema empezó a usar automáticamente otros proveedores". Aislar los datos de un cliente hizo visible, por primera vez, su problema con el remitente.

Sin embargo, creó un problema distinto para los clientes más pequeños. "El sistema necesita muchos datos para funcionar bien", explica Hugo, "y si usamos solo los datos del cliente, cuando este no tiene suficiente tráfico, las estadísticas son insignificantes. No tenemos suficiente confianza en el resultado. Así que acabábamos eligiendo a los proveedores equivocados".

El dilema era real: los datos por cliente aportan precisión pero pierden volumen; los datos compartidos aportan volumen pero pierden precisión.

El sistema actual: Tomar datos prestados, apostar por las probabilidades

Un cliente sin mucho historial toma prestados los datos globales y se apoya más en los suyos a medida que los acumula. El tráfico se distribuye entre los proveedores proporcionalmente a la probabilidad de que cada uno sea el mejor, en lugar de asignarse a un único ganador.

"Decidimos diseñar una fórmula para usar estadísticas globales", dice Hugo, "y cuanto más tráfico ganan y más datos tienen, más usamos sus datos. Pero seguimos apoyándonos en los globales. Es una mezcla de datos globales y del cliente; a mayor volumen del cliente, mayor impacto en su puntuación".

La transición es continua, no funciona por umbrales rígidos. No hay un momento exacto en el que el modelo cambie drásticamente.

Hugo pone un ejemplo concreto: "Digamos que llega un nuevo cliente de comercio electrónico. El primer problema es que sus tasas de conversión base serán más bajas que las nuestras. El segundo es que, al empezar, no tienen tráfico. No podemos confiar en sus estadísticas. Empezamos con las globales y, a medida que tengan más tráfico, este irá ganando peso en la mezcla entre los datos globales y los suyos propios".

La ponderación se basa en la confianza estadística más que en categorías arbitrarias. "Para un proveedor con solo diez intentos al día, los datos no son estadísticamente fiables", explica Hugo. "La confianza no es lo bastante sólida. En el nuevo sistema, creamos una fórmula matemática que calcula esa confianza. Ahora elegimos proveedores basándonos en ella. Cuantos más datos tenemos, más seguros estamos del rendimiento de un proveedor". 

"Para los clientes más pequeños seguimos usando estadísticas globales", añade Hugo. "Así el sistema funciona para ambos".

Dónde se nota realmente la diferencia para los clientes

La forma más honesta de describir el impacto diario es la resiliencia, no un subidón repentino de las métricas.

"En el día a día no verás una gran mejora", dice Hugo. "Tal vez una leve mejora en la tasa de conversión, pero muy pequeña, quizás de medio punto. La mejora real aparece cuando hay un problema técnico con un proveedor, un fallo de registro o un ataque de fraude que se cuela. El sistema reacciona y se adapta al instante".

La caída de un proveedor en agosto hizo evidente esta diferencia. Prelude ejecutaba el sistema antiguo y el nuevo en paralelo, lo que permitió compararlos directamente. "Tuvimos un problema con un proveedor que dejó de entregar mensajes", cuenta Hugo, "y el sistema nuevo se adaptó muchísimo mejor que el anterior. Cambió de un proveedor a otro más rápido. La tasa de conversión es mucho más estable durante un incidente".

Antes, la estabilidad requería intervención manual. "Con la primera versión del arbitraje activa, veíamos los problemas en la monitorización pero el sistema no reaccionaba correctamente. Teníamos que cerrar rutas manualmente para mitigar el impacto en las conversiones de nuestros clientes. Ahora es automático".

El siguiente paso: Analizar en la sombra

Queda un reto pendiente: cada cliente tiene una tasa de conversión base distinta, independientemente de qué proveedor lleve su tráfico.

"Cada cliente se comporta de manera diferente", dice Hugo. "No es lo mismo una fintech que una app de comercio electrónico. Por eso medimos las tasas de conversión por cliente para conocer su base, de modo que podamos aislar el impacto de cada proveedor de forma independiente, sin mirar solo la conversión bruta".

El siguiente paso es medir el comportamiento base de cada cliente, restarlo de lo que este observa y comparar a los proveedores con el resultado restante. "No se trata de volumen", explica Hugo. "También influye cómo se comportan sus usuarios en la aplicación, ya que eso afecta a su flujo de acceso y a sus tasas de conversión".

Este trabajo sigue en marcha, y la arquitectura que lo respalda ya está lista.

Hugo Bauer es ingeniero de software en Prelude, enfocado en infraestructura de verificación y sistemas de enrutamiento.

Este artículo forma parte de la serie de ingeniería de Prelude, donde el equipo comparte cómo se construye nuestro producto. Lee más en el blog o comienza a usar Prelude.