Un cliente que espera un código experimenta el encolamiento, la entrega, la lectura y la introducción como un solo retraso. Separa esos intervalos antes de decidir si un registro lento refleja la entrega del mensaje o el flujo de verificación en general.
¿Qué marcas de tiempo debo recopilar?
Recopila los eventos del ciclo de vida de Verify mediante una suscripción de webhook. Almacena las marcas de tiempo de su payload.
Los payloads de eventos identifican estas etapas:
| Evento | Marca de tiempo | Qué registra |
|---|---|---|
verify.verification.created | created_at | Se creó la verificación |
verify.attempt.sent | sent_at | Bird entregó un código de verificación a un canal |
verify.attempt.delivered | delivered_at | El canal reportó la entrega |
verify.attempt.undelivered | failed_at | Ese intento de código de verificación falló |
verify.verification.verified | verified_at | El destinatario envió el código correcto |
verify.verification.failed | failed_at | El plan de entrega no pudo entregar un código |
Conserva el tipo de evento junto a cada marca de tiempo. Los dos campos failed_at describen alcances diferentes: un intento y el plan de entrega de la verificación.
Deduplica entregas usando webhook-id, que identifica un evento y se mantiene estable entre reintentos. Usa timestamp del payload para ordenar eventos, porque el orden de entrega puede cambiar.
¿Qué intervalo responde a mi pregunta?
Usa sent-to-delivered para medir el tiempo de entrega reportado. Usa created-to-verified para medir el tiempo de verificación completada.
| Intervalo | Qué incluye |
|---|---|
created_at a sent_at | Tiempo antes de que el canal aceptara un código de verificación, incluyendo posibles fallos previos del canal |
sent_at a delivered_at | Procesamiento posterior a la aceptación del canal y el intervalo de entrega reportado |
created_at a verified_at | La espera completa, incluyendo leer e introducir el código |
Una marca de tiempo sent no siempre indica el envío al operador. Para SMS, el canal de Bird acepta el intento antes de que la pipeline SMS lo envíe al operador.
Los reportes de entrega son indicativos. Los operadores y proveedores de correo difieren en lo que confirman y en la rapidez con que lo reportan.
Compara el mismo canal y mercado a lo largo del tiempo. Las diferencias entre países pueden reflejar convenciones de reporte además de la velocidad de entrega.
Un evento verified confirma que el código fue recibido y utilizado. Su intervalo mide la finalización, no solo la entrega del mensaje.
¿Cómo emparejo eventos cuando se reenvían códigos?
Agrupa los eventos por verification_id, canal y dirección del destinatario. Excluye los pares que sigan siendo ambiguos.
Los eventos públicos de Verify no contienen un identificador de intento. Un reenvío o cambio de canal crea otro intento bajo el mismo identificador de verificación.
Un evento sent y su evento delivered tienen valores webhook-id diferentes. Ese encabezado deduplica eventos. No une las etapas de un intento.
El orden de las marcas de tiempo puede separar secuencias simples. Los envíos repetidos a la misma dirección por el mismo canal pueden solaparse. El orden por sí solo no demuestra qué entrega corresponde.
Marca esas muestras como ambiguas en lugar de asignarles una latencia de intento precisa. El intervalo created-to-verified de la verificación sigue siendo una medición independiente.
Un canal no disponible o restringido puede fallar sin un evento sent. Exige sent_at antes de calcular un intervalo sent-to-delivered.
¿Por qué mis cifras pueden diferir del dashboard?
El dashboard puede medir un intervalo diferente. También puede incluir intentos distintos a los de tu informe de eventos.
El dashboard mide desde la creación del intento hasta la resolución para los intentos cobrados y entregados que califican. Excluye los tiempos de espera de entrega corregidos de esa muestra de latencia porque sus tiempos de resolución no son entregas medidas.
Su ventana de reporte usa el momento del cobro. Un informe basado en eventos que use el momento de envío puede, por tanto, incluir un conjunto diferente de intentos.
La latencia almacenada refleja el estado de entrega en el momento en que se lee el cobro. Una actualización de entrega posterior puede dejar esa muestra sin cambios.
Un percentil es null cuando no existen muestras que califiquen. Conserva esa distinción en lugar de mostrar cero, lo que implicaría una entrega inmediata.
Compara la misma ventana de reporte antes de investigar una discrepancia. Usa eventos de webhook cuando tu aplicación necesite su propio intervalo y agrupación.
¿Cómo debo reportar códigos lentos y faltantes?
Reporta los tiempos junto con los intentos no entregados y las verificaciones que no se completaron.
Un informe de latencia que solo contenga intentos entregados omite a las personas cuyos códigos nunca llegaron. Mantén esos fallos visibles junto al resumen de tiempos.
El evento verify.verification.failed cubre los planes de entrega agotados. La expiración y el agotamiento de intentos con código incorrecto no emiten ese evento, por lo que no es un conteo completo de no conversión.
Registra la creación y la finalización exitosa de la verificación en tu aplicación. Mantén las sesiones sin resolver separadas en lugar de asignarles una duración de entrega inventada.
Desglosa los intentos por canal y mercado del destinatario. Cuando se reportan, carrier y mcc_mnc identifican la red que gestionó el mensaje. Ambos son null para email, WhatsApp y Telegram.
Un failover de canal puede explicar el código tardío de un cliente. Inspecciona la secuencia de intentos antes de atribuir todo el retraso al tiempo de entrega de un solo canal.
En resumen
Elige el intervalo que necesitas.
El tiempo de entrega reportado y el tiempo de verificación completada responden preguntas distintas. La verificación completada incluye leer e introducir el código.
Empareja los intentos con precaución.
Los eventos identifican la verificación, pero no cada intento. Los envíos repetidos por el mismo canal pueden hacer que el emparejamiento sea ambiguo.
Mantén los fallos junto al informe de latencia.
Las entregas exitosas por sí solas excluyen los códigos que nunca llegaron. Reporta las entregas fallidas y las verificaciones incompletas por separado.
Compara tráfico equivalente.
Los reportes de entrega varían según el canal y el mercado. Registra tu intervalo y tus reglas de muestreo antes de comparar percentiles.