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

Cada OTP que envía Prelude pasa por una red de proveedores de SMS. La decisión se toma en milisegundos, sin intervención humana, y determina qué operador entrega el mensaje. Elegir entre esos proveedores, mensaje a mensaje: eso es lo que en Prelude llamamos arbitraje.

Para elegir bien, hay que saber quién entrega de verdad. Todos los proveedores de SMS presumen de sus tasas de entrega. Pero esa métrica no es comparable entre ellos; como señal de ranking no sirve de nada.

«Cada proveedor entrega los reportes a su manera; algunos tienen su propia definición de qué está en tránsito y qué entregado», explica Hugo Bauer, ingeniero de software en la infraestructura de verificación de Prelude. «El SMS es tecnología legacy: según el proveedor, los datos pueden ser imprecisos». 

Unos dan el SMS por entregado al llegar a la antena. Otros esperan a que llegue al dispositivo. Esa disparidad abre la puerta a algo peor: si un proveedor sabe que recibe tráfico según su tasa de entrega, tiene incentivos para inflarla. «Pueden falsear las cifras para captar más tráfico», aclara Hugo, «porque repartimos el volumen entre ellos». El primer reto era superar estas discrepancias entre operadoras. 

Así que en Prelude decidimos crear nuestra propia señal. La Verify API incluye un endpoint /check que los clientes llaman cuando el usuario introduce su código. Si el check es positivo, el mensaje llegó, el usuario lo leyó y metió los dígitos correctos. Eso es conversión. Sin trampa ni cartón: o el código llegó o no llegó.

Esa decisión dio a Prelude una base sólida. Por eso tantos clientes confían en Prelude: el foco está en que los usuarios entren, no en inflar cifras de SMS ni intentos fallidos.

Cómo funcionaba el sistema original

El motor de arbitraje original nació simple. Para cada proveedor y país, calculaba una puntuación combinando conversión y precio. Un proveedor más barato podía ganar a uno con mejor entrega si los números cuadraban. Funcionó bien como punto de partida; durante un tiempo fue suficiente.

Con la llegada de Hugo sumamos granularidad. Surgían diferencias de rendimiento por operadora y dispositivo. «Empezamos a recibir más señales y a hilar fino», dice Hugo. «Antes eran estadísticas por país; luego añadimos operadora y dispositivo, porque vimos que en ciertos Android o iOS los SMS fallaban más». La lógica no cambió, pero el scoring ganó precisión: pasó de una nota por proveedor y país a una por proveedor, operadora y tipo de dispositivo. 

Entonces llegó un gran cliente de e-commerce y dejó al descubierto una grieta crítica: una nota única de conversión por proveedor no distingue qué clientes convierten peor por causas ajenas al propio proveedor.

Un caso de uso inédito para el modelo

La mayoría de clientes de Prelude usaban OTP para login o registro. Este cliente colocó el OTP al final del checkout, como confirmación previa al pago.

El impacto en las métricas fue inmediato. «Prelude Verify se usaba sobre todo para accesos», explica Hugo. Aquí el escenario era otro: «Lo usaban al final del carrito para confirmar el pedido. La conversión cayó en picado: muchos pedían el OTP pero no lo introducían. Cambiaban de idea».

El mensaje no se perdía; simplemente no compraban. El checkout tiene un abandono que el login jamás sufre. Muchos usuarios caen entre el carrito y el pago final, llegue o no el SMS. Esa pérdida ocurre al margen del operador.

Este cliente movía tanto volumen que dominaba el tráfico de Prelude en ciertos mercados. Con ese peso, su baja conversión hundió la media de todos los proveedores. El arbitraje derivó tráfico al siguiente mejor clasificado, cuya nota se desplomó por la misma razón. «El sistema no estaba roto, pero sí descalibrado», resume Hugo.

Lo que reveló este incidente

El caso destapó tres patrones que siempre habían estado ahí.

Fraude. Los ataques de fraude lanzan peticiones de OTP que jamás se van a validar. Cuando el tráfico fraudulento supera las capas de detección, esos intentos sin convertir penalizan al proveedor que los cursa. «Si se cuela, el fraude no convierte», explica Hugo. «Enviamos tráfico pero nunca hay checks, y la conversión global de esos proveedores cae». El mejor clasificado se lleva el golpe primero. Su nota se hunde. El tráfico pasa al siguiente. Y el ataque lo sigue.

En un artículo previo de esta serie técnica contamos cómo Prelude detecta y mitiga el fraude automatizado por agentes.

Filtros por Sender ID. Prelude registra identificadores de remitente para enviar SMS con el nombre de cada marca. Pero algunas operadoras bloquean nombres sospechosos; cuando pasa, las métricas globales no lo reflejan. 

Un cliente usaba un término comercial muy genérico en su marca. Ciertas operadoras lo tenían en lista negra para frenar casos de phishing. Sus mensajes caían al 100 % en esas redes, pero las estadísticas globales del proveedor parecían sanas: esa ruta afectada era solo una fracción del tráfico total.

«Solo afectaba a un par de operadoras, a nivel global era invisible», dice Hugo. «El proveedor parecía rendir bien porque otros clientes pasaban, y el cliente parecía estar bien en ese país porque otras operadoras entregaban. Solo lo ves al aislar ese cliente con esa operadora concreta: ahí no hay caída, hay un muro». 

Baselines por cliente. Hay clientes con menor conversión estructural sin culpa del proveedor; depende de su producto. Un banco pidiendo autenticación convierte muy distinto a un e-commerce cerrando un carrito. «En una misma ruta hay variación», apunta Hugo. «Entre dos clientes en el mismo país y proveedor puede haber un 10 % de diferencia». Un gap de 10 puntos en la misma ruta no por la entrega, sino por el comportamiento del usuario. La métrica evaluaba al cliente, no a la red.

El balance en los tres casos: la media compartida no distinguía si un proveedor rendía mal o si solo procesaba tráfico con peor conversión inherente.

Hacia un modelo más inteligente

Intento 1: Limitar el peso del cliente

La primera idea fue topar el impacto de cada cuenta en la nota compartida. Si un cliente copa la mitad del tráfico de un país, se limita su peso.

Pronto mostró sus límites. «Tirábamos demasiada información», dice Hugo. «En países donde dos clientes concentran casi todo el tráfico, si limitas sus datos, la estadística global pierde precisión por falta de muestra».

El tope protegía la media sobre el papel. En la práctica obligaba a descartar la mayoría del tráfico, y una nota basada en una muestra reducida es tan engañosa como una basada en datos sesgados. Un problema sustituyó al otro.

Intento 2: Rankings aislados por cliente

El siguiente paso fue crear un modelo propio para cada gran cliente, entrenado solo con sus métricas.

Hubo mejoras claras. «Al aislar sus datos detectamos las operadoras que fallaban por el bloqueo de registro», detalla Hugo. «El sistema empezó a usar alternativas de inmediato». Aislar datos sacó a la luz el bloqueo de Sender ID.

Pero penalizó a las cuentas pequeñas. «El modelo exige volumen para acertar», explica Hugo, «y si un cliente tiene poco tráfico, la muestra no da confianza estadística. Terminábamos eligiendo los proveedores erróneos».

Dilema claro: los datos por cliente dan precisión pero restan volumen. Los datos compartidos dan volumen pero restan precisión.

El sistema actual: balancear datos y probabilidad

Un cliente nuevo se apoya en los datos colectivos y va dando peso a los suyos conforme escala. El tráfico ya no va a un solo ganador: se reparte entre proveedores según su probabilidad real de ser la mejor opción.

«Diseñamos una fórmula para aprovechar métricas globales», apunta Hugo. «A más tráfico, más datos propios y más peso tienen en el scoring, sin perder la referencia global. Es un modelo híbrido: cuanto más volumen generas, más mandan tus métricas».

La transición es fluida y continua; no hay saltos bruscos de un modelo a otro.

Hugo lo ilustra así: «Llega un e-commerce nuevo. Su conversión base será más baja y de entrada no tiene tráfico. No podemos fiarnos de sus métricas. Arrancamos con los datos globales y, según sume volumen, equilibramos el peso entre la media del sistema y sus propios datos».

La ponderación se rige por confianza estadística, no por tramos arbitrarios. «Con diez envíos diarios un proveedor no ofrece fiabilidad estadística», resume Hugo. «La certeza del dato es baja. Ahora calculamos esa confianza matemáticamente para elegir operador. A mayor volumen de datos, mayor certeza sobre su rendimiento real». 

«Con clientes pequeños seguimos apoyándonos en métricas globales», concluye Hugo. «Así el sistema responde igual de bien a cualquier escala».

El valor real para el cliente

El beneficio directo no es un salto masivo de métricas: es resiliencia operativa.

«En el día a día no notarás un gran salto», admite Hugo. «Quizá medio punto más de conversión. La diferencia real salta cuando hay un incidente técnico en un proveedor, un bloqueo de Sender ID o un pico de fraude no detectado. El sistema se adapta solo».

La caída de un proveedor en agosto lo demostró. Con el sistema clásico y el nuevo corriendo en paralelo, el contraste fue evidente. «Un proveedor dejó de entregar mensajes por completo», recuerda Hugo, «y el nuevo motor reaccionó mucho mejor. Cambió de ruta al instante y mantuvo estable la conversión durante toda la incidencia».

Antes, esa estabilidad exigía actuar a mano. «En la primera versión monitorizábamos y veíamos el fallo, pero el arbitraje no reaccionaba bien. Teníamos que cortar rutas manualmente para proteger al cliente. Hoy el sistema lo resuelve solo».

El siguiente reto: aislar la intención

Queda un frente abierto: cada producto tiene una tasa base de conversión distinta, con independencia de las redes que use.

«Cada vertical es un mundo», explica Hugo. «Una fintech no convierte igual que un e-commerce. Por eso medimos la base de cada cliente: para evaluar el impacto real del proveedor sin que el caso de uso distorsione el análisis».

El objetivo: calcular la base de cada cliente, restarla de los datos observados y comparar a los proveedores solo por lo que depende de ellos. «No es solo tráfico», insiste Hugo. «Es cómo interactúa el usuario en la app: eso condiciona el flujo de login y su conversión».

Seguimos en ello. La arquitectura para resolverlo ya está operativa.

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

Esta entrega forma parte de la serie técnica de ingeniería de Prelude. Descubre más en nuestro blog o empieza a integrar Prelude hoy.