Jemand, der auf einen Code wartet, erlebt Warteschlange, Zustellung, Lesen und Eingabe als eine einzige Verzögerung. Trennen Sie diese Intervalle, bevor Sie entscheiden, ob eine langsame Registrierung die Nachrichtenzustellung oder den gesamten Verifizierungsablauf betrifft.
Welche Zeitstempel sollte ich erfassen?
Erfassen Sie die Verify-Lifecycle-Events über eine Webhook-Subscription. Speichern Sie deren Payload-Zeitstempel.
Die Event-Payloads identifizieren diese Phasen:
| Event | Zeitstempel | Was er erfasst |
|---|---|---|
verify.verification.created | created_at | Die Verifizierung wurde erstellt |
verify.attempt.sent | sent_at | Bird hat einen Bestätigungscode an einen Kanal übergeben |
verify.attempt.delivered | delivered_at | Der Kanal hat die Zustellung gemeldet |
verify.attempt.undelivered | failed_at | Dieser Bestätigungscode-Versuch ist fehlgeschlagen |
verify.verification.verified | verified_at | Der Empfänger hat den richtigen Code eingegeben |
verify.verification.failed | failed_at | Der Zustellplan konnte keinen Code zustellen |
Speichern Sie den Event-Typ zusammen mit jedem Zeitstempel. Die beiden failed_at-Felder beschreiben unterschiedliche Geltungsbereiche: einen Versuch und den Zustellplan der Verifizierung.
Deduplizieren Sie Zustellungen mit webhook-id, das ein Event identifiziert und über Retries hinweg stabil bleibt. Verwenden Sie timestamp aus dem Payload zum Sortieren der Events, da sich die Zustellreihenfolge ändern kann.
Welches Intervall beantwortet meine Frage?
Verwenden Sie Sent-to-Delivered für die gemeldete Zustellzeit. Verwenden Sie Created-to-Verified für die abgeschlossene Verifizierungszeit.
| Intervall | Was es umfasst |
|---|---|
created_at bis sent_at | Zeit, bevor der Kanal einen Bestätigungscode angenommen hat, einschließlich möglicher früherer Kanalfehler |
sent_at bis delivered_at | Verarbeitung nach Kanalannahme und das gemeldete Zustellintervall |
created_at bis verified_at | Die gesamte Wartezeit, einschließlich Lesen und Eingeben des Codes |
Ein Sent-Zeitstempel markiert nicht immer die Carrier-Übergabe. Bei SMS nimmt der Kanal von Bird den Versuch an, bevor die nachgelagerte SMS-Pipeline ihn an den Carrier übergibt.
Zustellberichte sind indikativ. Carrier und Mailbox-Provider unterscheiden sich darin, was sie bestätigen und wie schnell sie es melden.
Vergleichen Sie denselben Kanal und Markt über die Zeit. Unterschiede zwischen Ländern können Meldekonventionen ebenso widerspiegeln wie die Zustellgeschwindigkeit.
Ein Verified-Event bestätigt, dass der Code empfangen und verwendet wurde. Sein Intervall misst den Abschluss, nicht nur die Nachrichtenzustellung.
Wie ordne ich Events zu, wenn Codes erneut gesendet werden?
Gruppieren Sie Events nach verification_id, Kanal und Empfängeradresse. Schließen Sie Paare aus, die mehrdeutig bleiben.
Die öffentlichen Events von Verify enthalten keinen Versuchsbezeichner. Ein Resend oder Kanalwechsel erzeugt einen weiteren Versuch unter demselben Verifizierungsbezeichner.
Ein Sent-Event und sein Delivered-Event haben unterschiedliche webhook-id-Werte. Dieser Header dedupliziert Events. Er verbindet nicht die Phasen eines Versuchs.
Die Zeitstempelreihenfolge kann einfache Abfolgen trennen. Wiederholte Sendungen an dieselbe Adresse auf demselben Kanal können sich überlappen. Allein die Reihenfolge beweist nicht, welche Zustellung zugehört.
Markieren Sie solche Stichproben als mehrdeutig, statt eine exakte Versuchslatenz zuzuweisen. Das Created-to-Verified-Intervall der Verifizierung bleibt eine eigene Messung.
Ein nicht verfügbarer oder eingeschränkter Kanal kann ohne Sent-Event fehlschlagen. Setzen Sie sent_at voraus, bevor Sie ein Sent-to-Delivered-Intervall berechnen.
Warum können meine Werte vom Dashboard abweichen?
Das Dashboard kann ein anderes Intervall messen. Es kann auch andere Versuche enthalten als Ihr Event-Bericht.
Das Dashboard misst die Zeit von der Versuchserstellung bis zur Auflösung für qualifizierende, berechnete und zugestellte Versuche. Es schließt korrigierte Zustellungs-Timeouts aus dieser Latenzstichprobe aus, weil deren Auflösungszeiten keine gemessenen Zustellungen sind.
Sein Berichtsfenster verwendet den Abrechnungszeitpunkt. Ein eventbasierter Bericht, der den Sendezeitpunkt verwendet, kann daher eine andere Menge von Versuchen enthalten.
Die gespeicherte Latenz spiegelt den Zustellstatus zum Zeitpunkt des Abrechnungsabrufs wider. Ein späteres Zustellupdate kann diese Stichprobe unverändert lassen.
Ein Perzentil ist null, wenn keine qualifizierenden Stichproben vorhanden sind. Bewahren Sie diese Unterscheidung, statt null anzuzeigen, was sofortige Zustellung implizieren würde.
Vergleichen Sie dasselbe Berichtsfenster, bevor Sie eine Abweichung untersuchen. Verwenden Sie Webhook-Events, wenn Ihre Anwendung ein eigenes Intervall und eine eigene Gruppierung benötigt.
Wie sollte ich langsame und fehlende Codes melden?
Melden Sie Laufzeiten zusammen mit nicht zugestellten Versuchen und Verifizierungen, die nicht abgeschlossen wurden.
Ein Latenzbericht, der nur zugestellte Versuche enthält, lässt die Personen aus, deren Codes nie angekommen sind. Führen Sie diese Fehlschläge sichtbar neben der Laufzeitübersicht auf.
Das verify.verification.failed-Event deckt erschöpfte Zustellpläne ab. Ablauf und Erschöpfung von Fehlversuchslimits lösen dieses Event nicht aus, es ist also kein vollständiger Nichtkonvertierungszähler.
Verfolgen Sie Verifizierungserstellung und erfolgreichen Abschluss in Ihrer Anwendung. Halten Sie ungelöste Sitzungen getrennt, statt ihnen eine erfundene Zustelldauer zuzuweisen.
Schlüsseln Sie Versuche nach Kanal und Empfängermarkt auf. Wenn gemeldet, identifizieren carrier und mcc_mnc das zuständige Netz. Beide sind null für E-Mail, WhatsApp und Telegram.
Ein Kanal-Failover kann den verspäteten Code erklären. Prüfen Sie die Versuchsabfolge, bevor Sie die gesamte Verzögerung als Zustellzeit eines einzelnen Kanals behandeln.
Kurz gesagt
Wählen Sie das passende Intervall.
Gemeldete Zustellzeit und abgeschlossene Verifizierungszeit beantworten unterschiedliche Fragen. Die Abschlusszeit umfasst das Lesen und Eingeben des Codes.
Versuche vorsichtig zuordnen.
Events identifizieren die Verifizierung, aber nicht jeden einzelnen Versuch. Wiederholte Sendungen auf demselben Kanal können die Zuordnung mehrdeutig machen.
Fehlschläge neben dem Latenzbericht aufführen.
Erfolgreiche Zustellungen allein schließen Codes aus, die nie angekommen sind. Berichten Sie nicht zugestellte und unvollständige Verifizierungen separat.
Vergleichbaren Traffic vergleichen.
Zustellberichte unterscheiden sich nach Kanal und Markt. Legen Sie Ihr Intervall und Ihre Stichprobenregeln fest, bevor Sie Perzentile vergleichen.