Un utilisateur qui attend un code perçoit la mise en file d'attente, la livraison, la lecture et la saisie comme un seul délai. Séparez ces intervalles avant de déterminer si une inscription lente reflète la livraison du message ou le flux de vérification dans son ensemble.
Quels horodatages collecter ?
Collectez les événements du cycle de vie Verify via un abonnement webhook. Stockez les horodatages de leur payload.
Les payloads d'événements identifient ces étapes :
| Événement | Horodatage | Ce qu'il enregistre |
|---|---|---|
verify.verification.created | created_at | La vérification a été créée |
verify.attempt.sent | sent_at | Bird a transmis un code de vérification à un canal |
verify.attempt.delivered | delivered_at | Le canal a signalé la livraison |
verify.attempt.undelivered | failed_at | Cette tentative de code de vérification a échoué |
verify.verification.verified | verified_at | Le destinataire a soumis le bon code |
verify.verification.failed | failed_at | Le plan de livraison n'a pas pu livrer de code |
Conservez le type d'événement avec chaque horodatage. Les deux champs failed_at décrivent des portées différentes : une tentative et le plan de livraison de la vérification.
Dédupliquez les livraisons à l'aide de webhook-id, qui identifie un événement et reste stable d'une réessai à l'autre. Utilisez le timestamp du payload pour ordonner les événements, car l'ordre de réception peut varier.
Quel intervalle répond à ma question ?
Utilisez sent-to-delivered pour le délai de livraison signalé. Utilisez created-to-verified pour le délai de vérification complète.
| Intervalle | Ce qu'il inclut |
|---|---|
created_at à sent_at | Délai avant que le canal accepte un code de vérification, incluant potentiellement des échecs de canal antérieurs |
sent_at à delivered_at | Traitement après l'acceptation par le canal et intervalle de livraison signalé |
created_at à verified_at | L'attente complète, incluant la lecture et la saisie du code |
Un horodatage sent ne correspond pas toujours à la soumission à l'opérateur. Pour SMS, le canal de Bird accepte la tentative avant que le pipeline SMS en aval ne la soumette à l'opérateur.
Les accusés de livraison sont indicatifs. Les opérateurs et fournisseurs de messagerie diffèrent dans ce qu'ils confirment et dans la rapidité avec laquelle ils le signalent.
Comparez le même canal et le même marché dans le temps. Les différences entre pays peuvent refléter des conventions de signalement autant que la vitesse de livraison.
Un événement verified confirme que le code a été reçu et utilisé. Son intervalle mesure la complétion plutôt que la livraison du message seule.
Comment apparier les événements quand des codes sont renvoyés ?
Regroupez les événements par verification_id, canal et adresse du destinataire. Excluez les paires qui restent ambiguës.
Les événements publics de Verify ne contiennent pas d'identifiant de tentative. Un renvoi ou un changement de canal crée une autre tentative sous le même identifiant de vérification.
Un événement sent et son événement delivered ont des valeurs webhook-id différentes. Cet en-tête déduplique les événements. Il ne relie pas les étapes d'une tentative.
L'ordre des horodatages peut séparer les séquences simples. Des envois répétés à la même adresse sur le même canal peuvent se chevaucher. L'ordre seul ne prouve pas quelle livraison correspond.
Marquez ces échantillons comme ambigus au lieu de leur attribuer une latence de tentative précise. L'intervalle created-to-verified de la vérification reste une mesure distincte.
Un canal indisponible ou restreint peut échouer sans événement sent. Exigez sent_at avant de calculer un intervalle sent-to-delivered.
Pourquoi mes chiffres peuvent-ils différer du tableau de bord ?
Le tableau de bord peut mesurer un intervalle différent. Il peut aussi inclure des tentatives différentes de celles de votre rapport d'événements.
Le tableau de bord mesure le délai entre la création de la tentative et sa résolution pour les tentatives facturées et livrées éligibles. Il exclut les dépassements de délai de livraison corrigés de cet échantillon de latence, car leurs durées de résolution ne sont pas des livraisons mesurées.
Sa fenêtre de rapport utilise l'heure de facturation. Un rapport basé sur les événements utilisant l'heure d'envoi peut donc inclure un ensemble de tentatives différent.
La latence stockée reflète l'état de livraison au moment de la lecture de la facturation. Une mise à jour de livraison ultérieure peut laisser cet échantillon inchangé.
Un percentile est null quand aucun échantillon éligible n'existe. Préservez cette distinction au lieu d'afficher zéro, ce qui impliquerait une livraison immédiate.
Comparez la même fenêtre de rapport avant d'investiguer un écart. Utilisez les événements webhook quand votre application a besoin de son propre intervalle et regroupement.
Comment signaler les codes lents et manquants ?
Signalez les délais aux côtés des tentatives non livrées et des vérifications qui n'ont pas abouti.
Un rapport de latence contenant uniquement les tentatives livrées omet les personnes dont les codes ne sont jamais arrivés. Gardez ces échecs visibles à côté du résumé des délais.
L'événement verify.verification.failed couvre les plans de livraison épuisés. L'expiration et l'épuisement des tentatives de code incorrect n'émettent pas cet événement : ce n'est donc pas un décompte complet de non-conversion.
Suivez la création de la vérification et sa complétion réussie dans votre application. Conservez les sessions non résolues séparément au lieu de leur attribuer une durée de livraison fictive.
Ventiler les tentatives par canal et marché du destinataire. Quand ils sont signalés, carrier et mcc_mnc identifient le réseau de traitement. Les deux sont null pour l'e-mail, WhatsApp et Telegram.
Un basculement de canal peut expliquer le code tardif d'un utilisateur. Inspectez la séquence des tentatives avant de traiter l'ensemble du délai comme le temps de livraison d'un seul canal.
En bref
Choisissez l'intervalle dont vous avez besoin.
Le délai de livraison signalé et le délai de vérification complète répondent à des questions différentes. La complétion inclut la lecture et la saisie du code.
Appariez les tentatives avec prudence.
Les événements identifient la vérification, mais pas chaque tentative. Des envois répétés sur le même canal peuvent rendre l'appariement ambigu.
Conservez les échecs à côté du rapport de latence.
Les livraisons réussies seules excluent les codes qui ne sont jamais arrivés. Signalez les tentatives non livrées et les vérifications incomplètes séparément.
Comparez du trafic comparable.
Les accusés de livraison diffèrent selon le canal et le marché. Définissez vos règles d'intervalle et d'échantillonnage avant de comparer les percentiles.