Le taux de livraison répond à la mauvaise question
Un accusé de livraison décrit ce que le réseau a rapporté sur un message. La question métier est différente : l'utilisateur a-t-il terminé la vérification pendant qu'il était encore dans le flux ? Ces deux chiffres peuvent évoluer en sens opposés, et seul le second est un résultat.
Le modèle ci-dessous ne contient aucune valeur cible. Chaque seuil digne d'alerte provient de l'historique récent propre au programme, par route et par destination.
Les métriques de résultat
Achèvement de la vérification. Sur les sessions d'authentification où un code a été émis, la part où la vérification a réussi. C'est le chiffre principal ; segmentez avant toute conclusion.
Achèvement au premier essai et comportement de renvoi. Un taux de renvoi croissant sur une route apparaît généralement avant la chute du taux d'achèvement.
Émission en double. Sessions où plusieurs codes valides ont été émis, et sessions où l'utilisateur a saisi un code déjà remplacé. Deux échecs auto-infligés, corrigibles dans le code.
Codes périmés ou hors ordre. Des comptages élevés pointent vers la latence, pas vers les utilisateurs.
Boucles de nouvelle tentative. Sessions où l'utilisateur redemande un code sans jamais aboutir, et abandons.
Les distributions de latence
- Émission à acceptation — votre pile plus l'ingestion du fournisseur.
- Soumission à statut final — fournisseur, réseau de destination, opérateur.
- Émission à vérification — inclut l'humain ; détermine si votre expiration est réaliste.
Comparez la troisième distribution à l'expiration configurée et à votre politique de sécurité, plutôt que de copier une valeur par défaut.
Les ventilations qui localisent un problème
Fournisseur et route, pays et opérateur, identité d'expéditeur et template, plateforme et version d'app, classe de trafic et parcours, heure de la journée. Surveillez l'écart entre livraison rapportée et vérification par route, et séparez les erreurs applicatives des erreurs utilisateur.
Motifs canoniques d'échec
| Groupe | Exemples | Responsable |
|---|---|---|
| Application | format de destination invalide, template manquant, erreur d'endpoint | Votre ingénierie |
| Politique | limite de débit atteinte, destination supprimée, expéditeur non enregistré | Vos opérations |
| Fournisseur | route rejetée, throttled, erreur de soumission, pas de statut final | Gestion fournisseur |
| Réseau de destination | filtré, expéditeur bloqué, rejet réseau | Fournisseur plus escalade opérateur |
| Destinataire | injoignable, abonné absent, état du terminal | Non actionnable par message |
| Inconnu | statut non retourné dans le délai | À investiguer comme problème de qualité des données |
Conservez le statut et le code brut du fournisseur à côté du canonique.
Coût et abus
Coût par vérification réussie, pas par message. Vélocité des demandes par numéro, compte et réseau ; concentrations vers des destinations inhabituelles ou coûteuses ; demandes qui n'aboutissent jamais à une vérification.
Corréler les enregistrements sans journaliser le code
Cinq types d'enregistrements doivent être joints : la session d'authentification, l'émission de l'OTP, chaque tentative de message, chaque mise à jour de statut, et le résultat de vérification, via un identifiant de corrélation unique. Le code lui-même n'entre jamais dans cette traçabilité.
Schéma de mesure
auth_session, otp_issuance, message_attempt, message_status, verification
Table de diagnostic
| Observation | Cause probable | Première vérification |
|---|---|---|
| Livraison forte, vérification en baisse sur une route | Livraison tardive ou contenu non fiable | Distributions soumission-statut final et émission-vérification |
| Renvois en hausse, achèvement stable | Messages tardifs mais dans la fenêtre | Queue de la distribution par opérateur |
| Renvois en hausse, achèvement en baisse, un pays | Filtrage ou problème d'enregistrement | Motifs réseau de destination ; état d'enregistrement |
| Tentatives avec code expiré en hausse | Expiration trop courte ou latence en hausse | Émission-vérification contre l'expiration configurée |
| Tentatives avec code remplacé en hausse | Plusieurs codes valides par session | Émissions par session ; déduplication au niveau session |
| Échecs avec codes valides et à temps | Défaut applicatif | Types d'échec par version d'app |
| Statuts finaux manquants sur une route | Lacune de reporting fournisseur | Part sans statut final par fournisseur |
| Coût par vérification en hausse | Renvois ou abus | Demandes par vérification aboutie |
Alerting
Alertez sur les écarts par rapport à la ligne de base propre au programme, pour cette route et cette destination. Chaque alerte nomme un responsable et une action : escalader au fournisseur, changer de route, mettre en pause une campagne, ou ouvrir un défaut applicatif.