Métriques de qualité de route : quoi mesurer avant de faire confiance à une route SMS
Avant de placer des OTP ou alertes de production sur une route SMS, mesurez-la. Les accusés de réception seuls ne font pas foi. Cet article définit les KPI qui comptent : percentiles de latence, ratio de livraison finale, confirmation handset, intégrité du sender-ID et du contenu, et dérive ; et comment observer chacun avec un petit pool de handsets de test. Définitions uniquement ; pas de tableaux de bord fournisseurs.
Latence submit-to-DLR et pourquoi les percentiles comptent
La latence submit-to-DLR est le temps écoulé entre l'acceptation de votre submit (HTTP 200 sur un submit REST, ou un submit_sm_resp SMPP réussi) et la réception d'un accusé de livraison final (DLR) pour ce message. Les états intermédiaires sont utiles au débogage, mais l'horloge qui compte pour l'expérience utilisateur s'arrête uniquement sur un état final. Enregistrez les deux horodatages absolus dans vos propres systèmes ; ne vous fiez pas uniquement à un champ de durée côté fournisseur.
Les moyennes masquent le mode de défaillance qui casse les OTP et autres flux à contrainte temporelle. Rapportez au moins p50 et p95 sur la même fenêtre d'échantillon. Une route peut afficher une médiane stable tandis qu'une queue épaisse laisse une minorité d'utilisateurs attendre bien plus longtemps que les autres. Cette minorité est précisément celle qui abandonne le checkout ou réessaie et double votre trafic. Qualitativement, une route saine montre une dispersion serrée : le p95 n'est pas dramatiquement éloigné du p50, et la forme est stable sur des lots répétés plutôt que de grimper en flèche seulement quand vous avez le dos tourné.
Comment mesurer avec un petit pool de handsets de test : fixez l'ensemble des destinations (numéros E.164, max 15 chiffres), fixez la classe de payload (par exemple un corps court de type OTP dans un seul segment GSM 7-bit de 160 caractères, ou 153 en concaténé), soumettez par rafales contrôlées, et associez chaque id de message fournisseur à son horodatage DLR final. Excluez les retries et keepalives non finaux de l'échantillon de latence. Signes d'échec : un p50 soigné associé à un p95 incontrôlable, de longues périodes sans aucun DLR final, et une latence qui ne paraît correcte que lorsque le volume est trivial. HTTP 429 ou 500 au submit est un problème différent (capacité ou santé de la plateforme) et doit être comptabilisé séparément du délai DLR.
Les comptes SMSRoute incluent des crédits de test gratuits qui prouvent la livraison avant paiement, et des outils de test de livraison sont disponibles dans le tableau de bord SMSRoute.
Ratio de livraison finale : DELIVERED sur les états finaux
Le ratio de livraison finale est le nombre de messages qui se terminent dans un état final DELIVERED (ou succès équivalent) divisé par le nombre de messages ayant atteint un état final quelconque. Les états non finaux et inconnus restent hors du dénominateur jusqu'à résolution ou expiration explicite sous un timeout documenté. Ce n'est pas la même chose que livré-sur-soumis ; ce dernier mélange le trafic en vol dans le score et fait paraître les routes meilleures ou pires selon la lenteur de clôture des tickets.
Un 100 pour cent uniforme sur chaque destination, chaque heure et chaque forme de contenu est en soi un signal d'alerte. Les vrais réseaux produisent un mélange de résultats terminaux : delivered, rejected, expired, unreachable, et ids d'état SMPP associés, surtout quand vous variez pays, types d'expéditeur et générations de handsets. Un flux qui ne signale jamais d'échec peut supprimer, réécrire ou synthétiser les accusés. Qualitativement, le bon ressemble à une part de succès élevée parmi les finaux, accompagnée d'une minorité crédible d'échecs honnêtes que vous pouvez corréler à des numéros mauvais connus ou des tests négatifs délibérés.
Mesure avec un pool de handsets : envoyez vers des appareils que vous contrôlez plus quelques adresses volontairement invalides ou injoignables pour vérifier que les chemins d'échec apparaissent. Classez uniquement les DLR terminaux. Signes d'échec : succès perpétuel à 100 pour cent, finaux qui arrivent en même temps que le submit (sans délai réseau réaliste), classes d'échec manquantes que vous avez volontairement provoquées, ou ids d'état qui ne correspondent jamais au vocabulaire que votre contrat prévoit.
Taux de confirmation handset : la seule vérité au niveau handset
Le taux de confirmation handset est le nombre de messages réellement observés sur vos appareils de test divisé par le nombre envoyé à ces appareils. Les DLR sont des affirmations réseau ou plateforme. Un accusé sur le handset, visible dans la boîte de messages native ou via un logger côté appareil que vous contrôlez, est la seule vérité au niveau handset dont vous disposez. Quand le succès DLR et la présence handset divergent, croyez le handset et traitez le chemin DLR comme non fiable jusqu'à explication.
Comment mesurer : maintenez un petit pool connu de handsets physiques ou d'endpoints d'appareils étroitement contrôlés sur les opérateurs qui vous intéressent. Envoyez des payloads identifiables (tokens uniques par message), puis enregistrez si chaque token apparaît, quand il apparaît, et sous quelle identité d'expéditeur. Gardez les segments en tête : les parties simples GSM 7-bit plafonnent à 160 caractères (153 par partie en concaténé) ; les simples UCS-2 à 70 (67 par partie en concaténé). Les erreurs de fragmentation apparaissent souvent comme des partiels côté handset qu'un DLR grossier appelle encore succès.
Qualitativement, le bon signifie que les confirmations handset suivent de près les comptes DELIVERED finaux sur les mêmes destinations, avec des délais cohérents avec vos percentiles submit-to-DLR. Signes d'échec : DLR impeccables alors que les tokens n'arrivent jamais ; arrivées avec corps altérés ; manques systématiques sur un opérateur du pool ; ou confirmation seulement quand vous envoyez un trafic trivial et effondrement quand vous augmentez le parallélisme. Le taux de confirmation handset sera toujours borné à l'échantillon : vous ne pouvez pas mettre un téléphone sur chaque abonné, donc traitez-le comme vérité terrain pour l'échantillon, pas un recensement du globe.
SMSRoute publie ouvertement les tarifs par pays, donc le côté coût de toute comparaison de routes est vérifiable contre des sources datées.
| Métrique | Ce que vous comptez | Bon qualitatif | Signe d'échec |
|---|---|---|---|
| Latence submit-to-DLR | Heure d'acceptation jusqu'au DLR final ; rapportez p50 et p95 | Dispersion serrée ; p95 pas largement au-dessus de p50 | Médiane fine, queue terrible ; finaux bloqués |
| Ratio de livraison finale | Finaux DELIVERED / tous les finaux | Succès élevé avec échecs réels crédibles | 100 pour cent uniforme ; pas de classes d'échec |
| Taux de confirmation handset | Accusés appareil / envoyés au pool | Suit le succès DLR sur les mêmes numéros | Succès DLR, handsets silencieux |
| Préservation du Sender-ID | Expéditeur attendu toujours affiché / envoyé | Identité stable sur les opérateurs cibles | Réécritures en short codes ou alphas inconnus |
| Taux d'intégrité du contenu | Modèle non modifié reçu / envoyé | Jeton et libellé intacts de bout en bout | Troncature, injection, dommages de ré-encodage |
| Dérive | Même suite relancée dans le temps | Forme stable d'une mesure à l'autre | Croissance soudaine de la queue ou glissements silencieux des ratios |
Préservation du Sender-ID et taux d'intégrité du contenu
Le taux de préservation du Sender-ID est la part des messages confirmés sur terminal où l'identité d'expéditeur vue par l'utilisateur correspond à l'identité prévue pour cette route et cette destination. Le taux d'intégrité du contenu est la part où le corps reçu correspond bit à bit au modèle soumis au niveau applicatif après prise en compte du jeu de caractères choisi - pas de troncature, pas d'injection de préfixe ou suffixe, pas de ré-encodage qui corrompt le jeton OTP, et pas de remplacement silencieux de caractères hors de l'alphabet négocié.
Mesurez les deux uniquement sur les messages déjà confirmés sur terminal ; un message manquant est un problème de livraison, pas de préservation. Journalisez l'expéditeur attendu, l'expéditeur observé, le hash ou la chaîne exacte du corps attendu, et le corps observé. Exécutez les mêmes modèles qu'en production : formes OTP, formes d'alerte, et toute forme concaténée que vous utilisez réellement (en respectant les tailles de parties 160/153 et 70/67). Variez les expéditeurs alpha et numériques si les deux apparaissent dans votre produit.
Qualitativement, le bon est ennuyeux : la marque ou le numéro configuré est ce que l'appareil affiche, et la chaîne du jeton est intacte pour que votre vérificateur n'ait pas besoin de correspondance floue. Les signes d'échec incluent la réécriture systématique vers un short code générique, la suppression des alphas selon le pays, des bandes marketing ajoutées aux corps transactionnels, des décalages UCS-2/GSM qui cassent les chiffres ou les URL, et un réassemblage multipartite qui perd un segment du milieu alors que le DLR indique toujours délivré. Chacun de ces cas peut passer un contrôle.aïf délivré-sur-soumis et détruire quand même la conversion.
Dérive : les routes changent sans préavis
La dérive est le changement des métriques ci-dessus lorsque vous relancez la même suite de mesures dans le temps sur le même produit de route. Les fournisseurs amont, filtres opérateurs, enregistrements d'expéditeurs et politiques de mix de trafic évoluent sans pull request dans votre dépôt. Une route acceptable à l'onboarding peut se dégrader en latence de queue, commencer à réécrire les Sender-ID, ou renvoyer des finals optimistes qui ne correspondent plus aux terminaux.
Comment mesurer : figez le design de test - pool, modèles, taux de soumission, règles de classification - et planifiez des répétitions. Comparez p50/p95, ratio de livraison finale, taux de confirmation terminal, préservation du Sender-ID et intégrité du contenu en séries temporelles, pas en captures ponctuelles. Qualitativement, le bon est une forme stable avec des pics explicables ; vous enquêtez toujours sur les pics, mais la baseline tient. Les signes d'échec sont des changements par paliers après des périodes calmes, une lente dérive du p95 alors que le p50 paraît correct, des écarts croissants DLR-terminal, ou des échecs d'intégrité qui n'apparaissent que certains jours de la semaine quand la charge des intermédiaires change.
Traitez chaque métrique comme périssable. L'objectif du suivi de dérive n'est pas de produire un trophée de tableau de bord ; c'est de remarquer que la confiance a expiré avant vos utilisateurs.
Mise en garde : un test vert n'est pas un contrat avec l'avenir
Un seul test vert prouve qu'une route a fonctionné une fois, pour ces destinations, sous cette charge, avec ce contenu, ce jour-là. Il ne prouve pas que la route fonctionnera pour le mix de production, la concurrence de pointe ou la politique opérateur du mois prochain. La mesure est une habitude, pas un événement. Gardez le pool de terminaux petit mais réel, figez les définitions pour que les comparaisons aient un sens, et refusez de ramener le p95 à une moyenne unique qui flatte la médiane.
Les comptes SMSRoute incluent des crédits de test gratuits qui prouvent la livraison avant paiement, et des outils de test de livraison sont disponibles dans le tableau de bord SMSRoute. Utilisez ces crédits pour exercer les définitions de cet article - percentiles de latence, ratio de livraison finale, confirmation terminal, contrôles Sender-ID et contenu - puis continuez à re-mesurer. L'incertitude ne tombe jamais à zéro ; l'objectif est de rendre la confiance aveugle inutile.
Questions fréquentes
- Pourquoi la latence p95 soumission-à-DLR est-elle plus importante que la médiane pour les routes OTP ?
- Les OTP et autres messages à contrainte temporelle échouent pour les utilisateurs dans la queue. Une route peut afficher un p50 correct tandis que le p95 laisse assez de destinataires en attente pour qu'ils abandonnent ou réessayent. Mesurez les deux sur la même fenêtre depuis l'acceptation de soumission (HTTP 200 ou submit_sm_resp SMPP réussi) jusqu'au DLR final ; un écart serré est qualitativement plus sain qu'une médiane calme seule.
- Pourquoi un ratio de livraison finale SMS de 100 % est-il un signal d'alerte ?
- Le ratio de livraison finale est les finals DELIVERED divisés par tous les états finaux. Les vrais réseaux produisent des issues terminales mixtes quand vous variez les destinations et incluez des tests négatifs délibérés. Un 100 pour cent uniforme selon les conditions peut indiquer des accusés supprimés, réécrits ou synthétisés plutôt qu'un reporting honnête.
- Qu'est-ce que le taux de confirmation terminal et comment le mesurer ?
- C'est les accusés des appareils de test divisés par les messages envoyés à ces appareils - la seule vérité au niveau terminal. Envoyez des jetons uniques à un petit pool de terminaux contrôlé, observez si chaque jeton arrive intact et sous l'expéditeur attendu, et comparez cela au succès DLR. Les DLR en désaccord avec le terminal doivent être traités comme non fiables jusqu'à explication, et la suite doit être relancée dans le temps pour détecter la dérive.