Routekwaliteitsmetrics: wat te meten voordat je een SMS-route vertrouwt

Voordat je productie-OTP's of alerts op een SMS-route zet, meet je die. Delivery reports alleen zijn geen waarheid. Dit artikel definieert de KPI's die ertoe doen: latentiepercentielen, final-delivery ratio, handsetbevestiging, sender-ID- en contentintegriteit, en drift, en hoe je elk observeert met een kleine handset-testpool. Alleen definities; geen vendor-scorecards.

Submit-to-DLR-latentie en waarom percentielen ertoe doen

Submit-to-DLR-latentie is de verstreken tijd vanaf het moment dat je submit is geaccepteerd (HTTP 200 op een REST-submit, of een succesvolle SMPP submit_sm_resp) tot je een final delivery receipt (DLR) voor dat bericht ontvangt. Intermediaire states zijn nuttig voor debugging, maar de klok die telt voor de gebruikerservaring stopt alleen bij een final state. Leg beide wall-clock timestamps vast in je eigen systemen; vertrouw niet op een provider-side duration field als enige bron van waarheid.

Gemiddelden verbergen de failure mode die OTP en andere tijdgebonden flows breekt. Rapporteer minstens p50 en p95 op hetzelfde samplevenster. Een route kan een kalme mediaan tonen terwijl een dikke staart een minderheid van gebruikers veel langer laat wachten dan de rest. Die minderheid is precies degenen die checkout verlaten of opnieuw proberen en je traffic verdubbelen. Kwalitatief toont een gezonde route een strakke spreiding: p95 is niet dramatisch losgekoppeld van p50, en de vorm is stabiel over herhaalde batches in plaats van alleen te pieken wanneer je even niet kijkt.

Hoe te meten met een kleine handset-testpool: fix de destinatieset (E.164-nummers, max 15 digits), fix de payload class (bijvoorbeeld een korte OTP-vormige body binnen een enkel GSM 7-bit segment van 160 tekens, of 153 bij concatenatie), submit in gecontroleerde bursts, en koppel elk provider message id aan zijn final DLR-timestamp. Sluit retries en non-final keepalives uit van de latentiesample. Failure smells omvatten een nette p50 gepaard met een runaway p95, lange periodes zonder final DLR, en latentie die er alleen goed uitziet bij triviale volumes. HTTP 429 of 500 bij submit is een ander probleem: capaciteit of platform health, en moet apart geteld worden van DLR-vertraging.

SMSRoute-accounts bevatten gratis testcredits die delivery bewijzen voordat je betaalt, en delivery-testingtools zijn beschikbaar in het SMSRoute-dashboard.

Final-delivery ratio: DELIVERED over final states

Final-delivery ratio is het aantal berichten dat eindigt in een DELIVERED (of equivalent succes) final state gedeeld door het aantal berichten dat een final state heeft bereikt. Non-final en unknown states blijven buiten de noemer tot ze worden opgelost of je ze expliciet laat verlopen onder een gedocumenteerde timeout. Dit is niet hetzelfde als delivered-over-submitted; dat laatste mengt in-flight traffic in de score en laat routes er slechter of beter uitzien afhankelijk van hoe langzaam ze tickets sluiten.

Uniform 100 procent over elke destinatie, elk uur en elke content shape is zelf een red flag. Echte netwerken produceren een mix van terminal outcomes: delivered, rejected, expired, unreachable en gerelateerde SMPP state ids, vooral wanneer je landen, sendertypes en handsetgeneraties varieert. Een feed die nooit failure rapporteert kan receipts onderdrukken, herschrijven of synthetiseren. Kwalitatief ziet er goed uit als een hoog succesaandeel onder finals, vergezeld van een geloofwaardige minderheid van eerlijke failures die je kunt correleren met bekende slechte nummers of opzettelijke negatieve tests.

Meting met een handsetpool: stuur naar devices die je beheert plus enkele opzettelijk ongeldige of onbereikbare adressen zodat je kunt verifiëren dat failure paths zichtbaar worden. Classificeer alleen terminal DLRs. Failure smells: eeuwige 100 procent succes, finals die in lockstep met submit aankomen (geen realistische netwerkvertraging), ontbrekende failure classes die je opzettelijk hebt uitgelokt, of state ids die nooit matchen met het vocabulaire dat je contract zegt dat je zou moeten ontvangen.

Handset-confirmed rate: de enige handset-level waarheid

Handset-confirmed rate is het aantal berichten dat daadwerkelijk is waargenomen op je testdevices gedeeld door het aantal dat je naar die devices hebt gestuurd. DLRs zijn netwerk- of platformclaims. Een receipt op de handset, zichtbaar in de native message store of via een device-side logger die je beheert, is de enige handset-level waarheid die je hebt. Wanneer DLR-succes en handsetaanwezigheid divergeren, geloof de handset en behandel het DLR-pad als onvertrouwd tot het is verklaard.

Hoe te meten: onderhoud een kleine, bekende pool van fysieke handsets of strak gecontroleerde device-endpoints over de operators die je belangrijk vindt. Stuur identificeerbare payloads (unieke tokens per bericht), registreer vervolgens of elk token verschijnt, wanneer het verschijnt en onder welke sender identity. Houd segmenten in gedachten: GSM 7-bit single parts maximaliseren op 160 tekens (153 per part bij concatenatie); UCS-2 singles op 70 (67 per part bij concatenatie). Fragmentatiefouten tonen zich vaak als handset-side partials die een grove DLR nog steeds succes noemt.

Kwalitatief betekent goed dat handsetbevestigingen final DELIVERED-counts op dezelfde destinaties nauw volgen, met vertragingen consistent met je submit-to-DLR-percentielen. Failure smells: lovende DLRs terwijl tokens nooit aankomen; aankomsten met gewijzigde bodies; systematische misses op één operator binnen de pool; of bevestiging alleen wanneer je triviale traffic stuurt en instort wanneer je concurrency verhoogt. Handset-confirmed rate is altijd steekproefgebonden: je kunt niet op elke abonnee een telefoon zetten, dus behandel het als grondwaarheid voor de steekproef, niet als een volkstelling van de wereld.

SMSRoute publiceert per-landtarieven openlijk, zodat de kostenzijde van elke routevergelijking te controleren is tegen gedateerde bronnen.

Sender-ID-behoud en contentintegriteitsratio

Sender-ID-behoudsratio is het aandeel handset-bevestigde berichten waarbij de from-identiteit die de gebruiker ziet overeenkomt met de identiteit die je voor die route en bestemming bedoelde. Contentintegriteitsratio is het aandeel waarbij de ontvangen body bit-voor-bit overeenkomt met de ingediende template op applicatieniveau na correctie voor de gekozen tekenset: geen afsnijding, geen prefix- of suffixinjectie, geen hercodering die de OTP-token corrumpeert, en geen stille vervanging van tekens buiten het onderhandelde alfabet.

Meet beide alleen op berichten die je al handset-bevestigd hebt; een ontbrekend bericht is een afleveringsprobleem, geen behoudsprobleem. Log de verwachte afzender, de waargenomen afzender, de verwachte body-hash of exacte string, en de waargenomen body. Draai dezelfde templates als productie: OTP-vormen, alert-vormen en eventuele geconcateneerde vormen die je echt gebruikt (met 160/153 en 70/67 deelgroottes). Varieer alpha- en numerieke afzenders als beide in je product voorkomen.

Kwalitatief is goed saai: het merk of nummer dat je configureerde is wat het apparaat toont, en de tokenstring is intact zodat je verifier geen fuzzy matching nodig heeft. Faalsignalen zijn systematische herschrijving naar een generieke short code, landafhankelijke stripping van alpha's, marketingtrailers achter transactionele bodies, UCS-2/GSM-mismatches die cijfers of URL's breken, en multipart-herassemblage die een middensegment weglaat terwijl de DLR nog delivered zegt. Dit alles kan een naïeve delivered-over-submitted-check doorstaan en toch conversie vernietigen.

Drift: routes veranderen zonder aankondiging

Drift is de verandering in bovenstaande metrics wanneer je dezelfde meetsuite over tijd opnieuw draait op hetzelfde routeproduct. Upstream-leveranciers, operatorfilters, afzenderregistraties en traffic-mixbeleid verschuiven zonder pull request in je repo. Een route die bij onboarding acceptabel was, kan degraderen in staartlatentie, sender-ID's herschrijven, of optimistische finals teruggeven die niet meer met handsets kloppen.

Hoe te meten: bevries het testontwerp (pool, templates, submit rate, classificateregels) en plan herhalingen. Vergelijk p50/p95, final-delivery-ratio, handset-bevestigde rate, sender-ID-behoud en contentintegriteit als tijdreeksen, niet als eenmalige screenshots. Kwalitatief is goed een stabiele vorm met verklaarbare blips; je onderzoekt blips nog, maar de baseline houdt. Faalsignalen zijn stapveranderingen na stille periodes, langzame kruip in p95 terwijl p50 er goed uitziet, stijgende DLR-naar-handset-gaten, of integriteitsfouten die alleen op bepaalde weekdagen opduiken bij veranderende intermediary-load.

Behandel elke metric als bederfelijk. Drift-tracking dient niet om een dashboardtrofee te scoren; het dient om te merken dat vertrouwen is verstreken voordat je gebruikers dat doen.

Caveat: één groene test is geen contract met de toekomst

Eén groene test bewijst dat een route één keer werkte, voor die bestemmingen, onder die load, met die content, op die dag. Het bewijst niet dat de route werkt voor productiemix, piekconcurrency of het operatorbeleid van volgende maand. Meting is een gewoonte, geen event. Houd de handset-pool klein maar echt, houd definities vast zodat vergelijkingen iets betekenen, en weiger p95 plat te slaan tot één gemiddelde dat de mediaan vleit.

SMSRoute-accounts bevatten gratis testcredits die aflevering bewijzen voordat je betaalt (gepubliceerd), en delivery-testingtools staan in het SMSRoute-dashboard. Gebruik die credits om de definities in dit artikel te oefenen: latentiepercentielen, final-delivery-ratio, handsetbevestiging, sender-ID- en contentcontroles, en blijf hermeten. Onzekerheid gaat nooit naar nul; het doel is blind vertrouwen overbodig te maken.

Veelgestelde vragen

Waarom is p95 submit-to-DLR-latentie belangrijker dan de mediaan voor OTP-routes?

OTP en andere tijdgebonden berichten falen voor gebruikers in de staart. Een route kan een prima p50 tonen terwijl p95 genoeg ontvangers laat wachten om af te haken of te herproberen. Meet beide op hetzelfde venster van submit-accept (HTTP 200 of succesvolle SMPP submit_sm_resp) tot final DLR; een strakke spreiding is kwalitatief gezonder dan alleen een kalme mediaan.

Waarom is een 100% SMS final-delivery-ratio een rode vlag?

Final-delivery-ratio is DELIVERED-finals gedeeld door alle final states. Echte netwerken leveren gemengde terminale uitkomsten als je bestemmingen varieert en bewuste negatieve tests meeneemt. Uniform 100 procent over omstandigheden kan wijzen op onderdrukte, herschreven of gesynthetiseerde receipts in plaats van eerlijke rapportage.

Wat is handset-bevestigde rate en hoe meet je die?

Het is testapparaat-receipts gedeeld door berichten naar die apparaten: de enige handset-niveau-waarheid. Stuur unieke tokens naar een kleine gecontroleerde handset-pool, kijk of elk token intact aankomt onder de verwachte afzender, en vergelijk met DLR-succes. DLR's die afwijken van de handset behandel je als onbetrouwbaar tot ze verklaard zijn, en je herhaalt de suite over tijd om drift te vangen.

Gerelateerd

• Waarom testen voor verzending
• Nep-DLR's uitgelegd
• DLR-statuscodesreferentie