Eine akzeptierte SMS kann trotzdem fehlschlagen – wegen einer ungültigen Nummer, eines nicht erreichbaren Geräts oder eines Netzwerkproblems. Nachrichtendatensatz, Zustellevent und zurückgegebener Fehler helfen, diese Ergebnisse von Filtering zu unterscheiden.
Wie untersuche ich einen vermuteten Filter?
Sie vergleichen den Nachrichtendatensatz mit seinen SMS-Ereignissen. Das Ereignis beschreibt das Ergebnis; der Fehler und die Anbieterdetails helfen, es zu erklären.
| Event | Was das Event aussagt |
|---|---|
sms.rejected | Die Verarbeitung oder ein nachgelagerter Provider hat die akzeptierte Nachricht abgelehnt. |
sms.failed | Ein permanenter Fehler wurde gemeldet. |
sms.undelivered | Ein behebbarer Fehler wurde gemeldet, z. B. ein nicht erreichbarer Teilnehmer oder ein Netzwerkproblem. |
sms.expired | Der Provider hat einen Ablauf gemeldet. |
Kein Event allein beweist Filtering. Im Zustellbestätigungs-Mapping von Bird wird ein Provider-Grund carrier_rejected zu content_rejected. Ein nicht zugeordneter Grund wird zu unknown, was eine Untersuchung erfordert und eine unabhängige Ursache haben kann. Der Status einer Zustellbestätigung bestimmt das Event unabhängig vom Grund, sodass eine Carrier-Ablehnung mit verschiedenen Fehler-Events auftreten kann.
Der Fehlerkatalog definiert blocked_by_carrier und sender_unregistered. Ihr Fehlen schließt eine Filterung nicht aus: Bird ordnet carrier_rejected dem Wert content_rejected und nicht zugeordnete Ursachen dem Wert unknown zu. Prüfen Sie den tatsächlich zurückgegebenen Code, bewahren Sie unbekannte Werte auf und behalten Sie die Anbieterdetails.
Welche Details sollte ich speichern?
Speichern Sie Nachrichten-ID, Absender, Ziel, Sendezeitpunkt, Event-Typ, normalisierten error.code, Beschreibung und carrier_error_code. Gruppieren Sie Fehler nach Ziel, Absender und Nachrichtentyp; ein einzelner Fehler liefert weniger Belege als eine Veränderung, die eine konsistente Gruppe von Sendungen betrifft.
Der normalisierte Code ist das stabile Feld für die Verarbeitung in Ihrer Anwendung. Die Beschreibung ist Diagnosetext – parsen Sie sie nicht als festen Vertrag. carrier_error_code enthält den detaillierteren Code des Sendeproviders, sofern vorhanden; es ist nicht garantiert, dass es sich um den eigenen Code eines Mobilfunk-Carriers handelt. Das Feld kann leer sein, wenn der Provider keinen Code liefert oder wenn der Fehler vor der Provider-Übergabe auftritt.
Zum Beispiel weist content_rejected auf die gemeldete Ablehnung hin, invalid_destination auf die Empfängernummer und provider_unavailable auf das Netzwerk- oder Kapazitätsergebnis. unknown lässt die Ursache ungeklärt. Teilen Sie die Nachrichten-ID und den verfügbaren Provider-Code dem Support mit, wenn diese Details den Fehler nicht erklären.
Verhindert die Registrierung meines Absenders Filtering?
Die Registrierung erfüllt das jeweilige Absenderprogramm; sie garantiert keine Zustellung. Der Absender muss auch für das Ziel berechtigt sein, und Nachricht sowie Traffic müssen die jeweiligen Anforderungen erfüllen.
Für US-A2P-Messaging mit lokalen Nummern prüfen Sie die vollständige 10DLC-Registrierung: Brand, Campaign und Nummernverknüpfung. Eine genehmigte Brand oder Campaign verknüpft nicht automatisch jede Nummer, die Ihnen gehört. Toll-Free- und Short-Code-Programme haben andere Anforderungen. Andere Zielländer können eine Absendernamen-Registrierung erfordern.
Nutzen Sie SMS-Ziele, um die Absenderwahl zu planen, und bestätigen Sie dann die geltenden Anforderungen und den Registrierungsstatus Ihres Workspace vor dem Launch. Ein Länder-Guide ist eine Referenz-Momentaufnahme, kein Nachweis, dass Ihr Absender genehmigt ist.
Was sollte ich bei einem Opt-out-Fehler tun?
Bewahren Sie die Präferenz. Ein Versand an ein Bird-gesperrtes Absender-Empfänger-Paar wird an der API mit E12077 abgelehnt; diese Ablehnung erzeugt keine Nachricht und kein Nachrichten-Event. Ein nachgelagerter Report von recipient_opted_out ist etwas anderes: Er ist ein Ergebnis für eine akzeptierte Nachricht und veranlasst Bird, eine Suppression für das Paar anzulegen.
Unterstützte Abmelde-Schlüsselwörter können Sperren für Absender-Empfänger-Paare erzeugen. Sperrereignisse auf Paarebene bilden nicht jede Workspace-Präferenz oder jede beim Kundendienst eingegangene Anfrage ab. Berücksichtigen Sie diese weitergehenden Präferenzen bei der Zielgruppenauswahl. Wechseln Sie nicht den Absender, um eine Abmeldung zu umgehen.
Was sollte ich vor einem erneuten Versuch prüfen?
- Absenderbereitschaft. Bestätigen Sie den Absendertyp, die Registrierung und den Zielzugang, die für diesen Traffic erforderlich sind.
- Einwilligung und Relevanz. Bestätigen Sie, dass die Person diesem Zweck zugestimmt hat und diese Einwilligung nicht widerrufen hat.
- Inhalt und Links. Identifizieren Sie das Unternehmen eindeutig, verwenden Sie geeignete Links und prüfen Sie die Inhaltsanforderungen des Ziellandes. Ein Linkwechsel allein kann keine Zustellberechtigung herstellen.
- Traffic und Timing. Vergleichen Sie die fehlgeschlagenen Sendungen mit Ihrem normalen Muster, dem Queueing und den Limits der Route. Das wiederholte Einreichen desselben abgelehnten Inhalts kann Kosten verursachen, ohne die Ursache zu beheben.
- Der gemeldete Fehler. Untersuchen Sie permanente Ablehnungen, bevor Sie erneut senden. Bei einer mehrdeutigen API-Antwort verwenden Sie den ursprünglichen Idempotenzschlüssel innerhalb seines Replay-Fensters; machen Sie aus Unsicherheit nicht automatisch eine zweite Anfrage.
Das SMS-Routing wendet vor der Übergabe an den Mobilfunkanbieter Zielkontrollen an. Eine SMS-Integration verfolgt jede angenommene Anfrage anhand ihres Nachrichtendatensatzes und ihrer Zustellereignisse.
Kurz gesagt
Eine fehlgeschlagene Zustellung ist ein Ausgangspunkt für die Untersuchung.
Das Ereignis, der normalisierte Fehler und die Anbieterdetails beschreiben den Fehlerfall. Eine unbekannte Ursache beweist keine Filterung durch den Mobilfunkanbieter.
Registrierung ist eine Anforderung, keine Zustellgarantie.
Prüfen Sie Absender, Ziel, Inhalt, Einwilligung und Traffic-Muster, bevor Sie entscheiden, was Sie ändern.
Ein Opt-out ist eine Präferenz, die es zu bewahren gilt.
Unterscheiden Sie eine API-Ablehnung für ein gesperrtes Absender-Empfänger-Paar von einem nachgelagerten Opt-out-Report, und respektieren Sie den vollen Umfang der Anfrage der Person.
Bewahren Sie die Belege zusammen mit der Nachricht auf.
Speichern Sie Nachrichten-ID, Ziel, Absender, Zeitpunkt, Event und Fehlerdetails, damit Sie ein Muster untersuchen oder einen aussagekräftigen Supportfall eröffnen können.