Die Zustellrate beantwortet die falsche Frage
Ein DLR beschreibt, was das Netz über eine Nachricht gemeldet hat. Die geschäftliche Frage ist, ob der Nutzer die Verifizierung im laufenden Flow abgeschlossen hat. Beide Zahlen können in verschiedene Richtungen laufen.
Dieses Modell enthält keine Zielwerte. Jeder Schwellwert entsteht aus der eigenen Historie des Programms pro Route und Ziel.
Ergebniskennzahlen
Abgeschlossene Verifizierung je Session mit ausgegebenem Code; Abschluss im ersten Versuch und Resend-Verhalten; doppelte Ausgabe und Nutzung überholter Codes; abgelaufene oder verspätete Codes; Retry-Schleifen und Abbrüche.
Latenzverteilungen
Ausgabe bis Annahme (eigener Stack plus Anbieteraufnahme), Übermittlung bis Endstatus (Anbieter, Zielnetz, Netzbetreiber) und Ausgabe bis Verifizierung (inklusive Mensch). Die dritte Verteilung zeigt, ob die konfigurierte Gültigkeitsdauer realistisch ist, und definiert die nutzbare Frist.
Aufschlüsselungen
Anbieter und Route, Land und Netzbetreiber, Absenderidentität und Template, Plattform und App-Version, Traffic-Klasse und Journey, Tageszeit. Beobachten Sie die Lücke zwischen gemeldeter Zustellung und Verifizierung pro Route und trennen Sie Anwendungsfehler von Nutzerfehlern.
Kanonische Fehlergründe
Gruppieren Sie Anbietercodes nach Zuständigkeit: Anwendung, Policy, Anbieter, Zielnetz, Empfänger, unbekannt. Rohstatus und Rohcode bleiben erhalten.
Kosten und Missbrauch
Kosten pro erfolgreicher Verifizierung statt pro Nachricht. Beobachten Sie Anfragegeschwindigkeit pro Nummer, Konto und Netz, Konzentration auf ungewöhnliche oder teure Ziele und Anfragen ohne Verifizierung.
Korrelieren ohne den Code zu loggen
Fünf Datensätze werden verknüpft: Authentifizierungs-Session, Ausgabe, Nachrichtenversuche, Statusmeldungen und Verifizierungsergebnis, über eine Korrelations-ID, die beim Ausgabeentscheid entsteht. Der Code selbst gehört nie in Logs, Analytics oder Supportmasken.
Messschema
auth_session, otp_issuance, message_attempt, message_status, verification
Diagnosetabelle
| Beobachtung | Wahrscheinliche Ursache | Erste Prüfung |
|---|---|---|
| Zustellung stabil, Verifizierung fällt auf einer Route | Verspätete Zustellung oder wenig vertrauenswürdiger Inhalt | Verteilungen Übermittlung–Endstatus und Ausgabe–Verifizierung |
| Mehr Resends, Abschluss stabil | Nachrichten spät, aber im Fenster | Tail pro Netzbetreiber |
| Mehr Resends, geringerer Abschluss in einem Land | Filterung oder Registrierungsproblem | Zielnetz-Fehlergründe und Registrierungsstatus |
| Mehr Versuche mit abgelaufenem Code | Gültigkeit zu kurz oder Latenz gestiegen | Ausgabe–Verifizierung gegen Gültigkeit |
| Mehr Versuche mit überholtem Code | Mehrere gültige Codes pro Session | Ausgaben pro Session, Deduplizierung |
| Fehler trotz gültiger, rechtzeitiger Codes | Anwendungsdefekt | Fehlerarten pro App-Version |
| Fehlende Endstatus auf einer Route | Lücke im Anbieter-Reporting | Anteil ohne Endstatus pro Anbieter |
| Kosten pro Verifizierung steigen | Resends oder Missbrauch | Anfragen pro abgeschlossene Verifizierung |
Alerting
Alarmieren Sie auf Abweichung von der eigenen Baseline dieser Route und dieses Ziels. Jeder Alert nennt Owner und Aktion: Anbieter eskalieren, Route wechseln, Kampagne pausieren oder Defekt aufnehmen.