La tasa de entrega responde a la pregunta equivocada
Un DLR describe lo que la red reportó del mensaje. La pregunta del negocio es otra: ¿completó el usuario la verificación mientras seguía en el flujo? Ambos números pueden moverse en direcciones opuestas y solo el segundo es un resultado.
Este modelo no contiene valores objetivo. Cada umbral que merece alerta sale del histórico reciente del propio programa, por ruta y destino.
Métricas de resultado
- Verificación completada sobre las sesiones en que se emitió un código.
- Completado en el primer intento y comportamiento de reenvío: el reenvío suele subir antes de que caiga el completado.
- Emisión duplicada: sesiones con más de un código válido, o códigos superados que el usuario introduce.
- Códigos caducados o desordenados: apuntan a latencia, no a los usuarios.
- Bucles de reintento: sesiones con múltiples solicitudes sin completar y abandonos.
Distribuciones de latencia
- Emisión a aceptación: tu stack más la ingestión del proveedor.
- Envío a estado final: proveedor, red de destino y operador.
- Emisión a verificación: incluye al usuario y determina si tu expiración es realista.
Compara la tercera distribución con la expiración configurada y con tu política de seguridad, en lugar de heredar un valor por defecto. Lo mismo define el plazo útil tras el cual otro intento ya no ayuda.
Desgloses que localizan el problema
Proveedor y ruta, país y operador, identidad de remitente y plantilla, plataforma y versión de app, clase de tráfico y recorrido, hora del día. Vigila la brecha entre entrega reportada y verificación por ruta, y separa errores de aplicación de errores de usuario en el endpoint de verificación.
Razones canónicas de fallo
Agrupa los códigos de proveedor por responsable: aplicación, política, proveedor, red de destino, destinatario y desconocido. Conserva el estado y código brutos junto al canónico.
Coste y abuso
Coste por verificación exitosa, no por mensaje. Vigila velocidad de solicitudes por número, cuenta y red, concentraciones hacia destinos inusuales o caros, y solicitudes que nunca acaban en verificación.
Correlacionar sin registrar el código
Se unen cinco tipos de registro: sesión de autenticación, emisión, intentos de mensaje, estados y resultado de verificación, mediante un identificador de correlación creado al decidir emitir. El código nunca forma parte de ese rastro: guarda solo lo necesario para validarlo.
Esquema de medición
auth_session, otp_issuance, message_attempt, message_status, verification
Con esos cinco registros —y ningún valor de código— se derivan todas las métricas anteriores.
Tabla de diagnóstico
| Observación | Causa probable | Primera comprobación |
|---|---|---|
| Entrega alta y verificación baja en una ruta | Entrega tardía o contenido poco fiable | Distribución de envío a estado final y de emisión a verificación |
| Suben reenvíos, completado estable | Mensajes tardíos dentro de la ventana | Cola de la distribución por operador |
| Suben reenvíos y baja completado en un país | Filtrado o problema de registro | Razones de red de destino y estado del registro |
| Suben intentos con código caducado | Expiración corta o más latencia | Emisión a verificación frente a la expiración |
| Suben intentos con código superado | Varios códigos válidos por sesión | Emisiones por sesión; deduplicación por sesión |
| Fallos con códigos válidos y a tiempo | Defecto de aplicación | Tipos de fallo por versión de app |
| Faltan estados finales en una ruta | Reporte incompleto del proveedor | Proporción sin estado final por proveedor |
| Sube el coste por verificación | Reenvíos o abuso | Solicitudes por verificación completada |
Alertas
Alerta por desviación frente a la línea base del propio programa en esa ruta y destino. Cada alerta necesita responsable y acción: escalar al proveedor, cambiar de ruta, pausar una campaña o abrir un defecto.