Ablehnungen von A2P-SMS untersuchen, ohne Daten offenzulegen oder voreilige Schlüsse zu ziehen
Ein praxisorientierter Leitfaden, um Ablehnungen einzugrenzen, aussagekräftige Stichproben auszuwählen, Datensätze abzugleichen und Hypothesen zu dokumentieren, ohne Hinweise mit bestätigten Ursachen zu verwechseln.
Eine Ablehnung ist ein beobachteter Status, keine vollständige Diagnose
Ein als „Abgelehnt“ gekennzeichneter Datensatz zeigt an, dass das meldende System der Nachricht diesen Status zugewiesen hat. Für sich allein lässt sich daraus nicht unbedingt ableiten, welche Komponente die Nachricht abgelehnt hat, an welcher Stelle dies geschah oder was die endgültige Ursache war. Die Kennzeichnung und der zugehörige Code sind Hinweise für die Untersuchung, aber keine abschließende Erklärung.
Es empfiehlt sich, drei Ebenen auseinanderzuhalten: das von einer Anwendung oder Plattform gemeldete Ergebnis, die beim Anbieter oder in der Route erfasste Antwort und die bestätigte Zustellung auf dem Gerät. Ein DLR ist eine Statusmeldung; es sollte nicht automatisch als unabhängiger Nachweis dafür dargestellt werden, dass die Nachricht auf dem Endgerät angezeigt wurde. Lässt sich dieser letzte Schritt anhand der Belege nicht bestätigen, sollte die verbleibende Unsicherheit dokumentiert werden.
- Technische Ablehnung: Eine Antwort oder ein Status weist darauf hin, dass der Versand nicht angenommen oder in einer bestimmten Phase nicht fortgesetzt wurde. Prüfen Sie, welches System die Antwort erzeugt hat und zu welcher Anfrage sie gehört.
- Inhaltsfilterung: Dies kann eine Hypothese sein, wenn Datensätze oder der Anbieter darauf hindeuten. Nehmen Sie sie nicht allein deshalb als erwiesen an, weil sie zu einer abgelehnten Nachricht passt.
- Ungewisses Ergebnis: Lässt sich anhand der Datensätze nicht zwischen Ablehnung, ausstehendem Status und Zustellbestätigung unterscheiden, halten Sie diese Unterscheidung fest und machen Sie aus der Unsicherheit keine Ursache.
Legen Sie die Fragestellung fest und begrenzen Sie den Datenabruf
Formulieren Sie vor der Abfrage von Datensätzen, welche Entscheidung die Untersuchung unterstützen soll. Beispiele: feststellen, ob eine Zunahme der Ablehnungen auf ein bestimmtes Ziel konzentriert ist, eine betroffene Vorlage mit einer legitimen Vorlage vergleichen oder prüfen, ob eine Anbieterantwort mit dem Plattformstatus übereinstimmt. Eine konkrete Fragestellung verhindert, dass vollständige Verläufe erhoben werden, die für die Analyse keinen Mehrwert bieten.
Legen Sie im Voraus den Zeitraum, die relevanten Ziele und Absender, die einbezogenen Nachrichtenarten sowie die Kriterien fest, nach denen ein Ereignis in den Untersuchungsumfang fällt. Wenn Sie Zeiträume vor und nach einer Änderung vergleichen, notieren Sie die jeweiligen Daten und die vorgenommenen Änderungen. Leiten Sie nicht allein daraus eine Kausalität ab, dass zwei Ereignisse im selben Zeitraum auftraten.
- Beginnen Sie mit einer begrenzten Abfrage abgelehnter Ereignisse und erweitern Sie sie nur, wenn die Belege eine offene Frage hinterlassen.
- Trennen Sie OTP-, Transaktions- und legitime Marketingnachrichten, wenn sich ihre Abläufe, Vorlagen oder Versandbedingungen unterscheiden.
- Dokumentieren Sie, wer die Untersuchung angefordert hat, welchen Zweck sie verfolgt, welchen Zeitraum sie abdeckt und wer auf die Daten zugreifen darf.
Erstellen Sie eine aussagekräftige Stichprobe und dokumentieren Sie die Auswahl
Eine Liste auffälliger Fälle kann bei der Diagnose eines Vorfalls helfen, belegt aber nicht, dass das Muster häufig auftritt. Um ein Problem zu untersuchen, schichten Sie die Datensätze nach relevanten Merkmalen: Ziel, gegebenenfalls Mobilfunkanbieter, Absender, Vorlage oder Nachrichtenart sowie Zeitraum. Vergleichen Sie gleichwertige Gruppen und halten Sie fest, wie viele Ereignisse in jede Gruppe aufgenommen wurden.
Aus den verfügbaren Belegen lässt sich keine universelle Stichprobengröße ableiten, die Repräsentativität garantiert. Wenn Sie eine deskriptive Stichprobe benötigen, erläutern Sie das Auswahlkriterium und dessen Grenzen. Sie können eine systematische Auswahl durch konkrete Fälle ergänzen, die unterschiedliche Antworten zeigen. Kennzeichnen Sie diese jedoch als Beispiele und nicht als Maß für die Häufigkeit.
- Legen Sie zunächst die Gruppen fest, die den beobachteten Unterschied erklären könnten. Fassen Sie Ziele oder Absender nicht zusammen, ohne ihre Vergleichbarkeit zu prüfen.
- Beziehen Sie Ereignisse aus verschiedenen Teilen des Zeitraums ein, wenn Sie eine Veränderung erkennen möchten, und dokumentieren Sie die Auswahlmethode.
- Halten Sie den Nenner fest: Geben Sie, sofern verfügbar, das geprüfte Volumen je Gruppe an und übertragen Sie Ergebnisse aus einer kleinen Stichprobe nicht auf den gesamten Nachrichtenverkehr.
- Wenn die Plattform nach Status und Ursachencode filtern kann, nutzen Sie diese Filter, um Datensätze zu finden. Der Code bleibt ein Hinweis, der abgeglichen werden muss.
Gleichen Sie Datensätze mit den erforderlichen Feldern ab, statt standardmäßig den vollständigen Inhalt zu verwenden
Um Belege miteinander zu vergleichen, müssen Sie das Ereignis aus der Anwendung mit dem Plattformdatensatz und, sofern relevant, mit der Antwort des Anbieters verknüpfen können. Welche Felder verfügbar sind, hängt von der Integration ab. Daher lässt sich kein universelles Mindestdatenschema für alle Systeme angeben. Wählen Sie nur die Kennungen und Metadaten aus, die für die Beantwortung der Fragestellung erforderlich sind.
Prüfen Sie zunächst, ob sich die Datensätze über eine Nachrichten- oder Anfragekennung und einen Zeitstempel abgleichen lassen. Ergänzen Sie nur die Merkmale, die für die Eingrenzung des Falls erforderlich sind, etwa Ziel, Absender, Nachrichtenart, gemeldeter Status, Ursachencode und Quellsystem. Klären Sie die Bedeutung jedes Feldes anhand der Dokumentation der Plattform oder des Anbieters.
- Exportieren Sie nicht den vollständigen Nachrichtentext, wenn ein Verweis auf die Vorlage, eine Kategorie oder eine Versionsangabe genügt.
- Wenn eine Inhaltsprüfung erforderlich ist, beschränken Sie den Zugriff auf die begründete Teilmenge und nehmen Sie den Inhalt nicht in allgemeine Berichte auf.
- Behandeln Sie ähnlich benannte Felder nicht als gleichbedeutend: Prüfen Sie, ob sie eine Anfrage, einen Versand, eine Antwort oder einen späteren Status bezeichnen.
Verringern Sie die Datenexposition und dokumentieren Sie den Zugriff
Nachrichtendatensätze können personenbezogene Daten oder betriebliche Informationen enthalten, die schützenswert sind. Für die Untersuchung sollten nur die Daten erhoben werden, die für den Zweck unbedingt erforderlich sind. Beschränken Sie den Zugriff und dokumentieren Sie die geltenden Kriterien für Aufbewahrung und Löschung in Ihrer Organisation. Der konkrete Zeitraum hängt von den einschlägigen Verpflichtungen und Richtlinien ab; eine einheitliche Frist für alle Fälle lässt sich nicht empfehlen.
Verwenden Sie, sofern praktikabel, in Analysenotizen Ersatzkennungen und bewahren Sie Arbeitsmaterial getrennt von Daten auf, mit denen sich eine Person identifizieren lässt. Kopieren Sie Datensätze nicht in Kanäle oder Dokumente, auf die mehr Personen als nötig zugreifen können. Wenn gesetzliche oder vertragliche Verpflichtungen die Aufbewahrung bestimmter Informationen erfordern, folgen Sie dem geltenden Verfahren und dokumentieren Sie diesen Bedarf.
- Legen Sie Zweck und zugriffsberechtigten Personenkreis fest, bevor Sie einen Datenexport weitergeben.
- Dokumentieren Sie, was exportiert wurde, wer darauf zugegriffen hat und wann die Aufbewahrung gemäß den geltenden Richtlinien und Verpflichtungen überprüft werden muss.
- Maskieren oder entfernen Sie Felder, die für den Abgleich und die Analyse des Musters nicht erforderlich sind.
Gleichen Sie Datensätze ab und behandeln Sie Hypothesen getrennt
Verfolgen Sie ein Ereignis so weit wie möglich durch Ihre Systeme: von der Anfrage der Anwendung über die Annahme oder Antwort der Plattform bis zum vom Anbieter gemeldeten Status. Prüfen Sie, ob Kennungen und Zeitangaben zum selben Versand gehören, und bewahren Sie die ursprünglichen Antworten zusammen mit der Angabe ihres Quellsystems auf. Unterschiede zwischen Datensätzen können auf eine Lücke in der Beobachtbarkeit, eine Integrationsabweichung oder eine Erklärung hinweisen, die noch geprüft werden muss. Für sich allein klären sie die Ursache jedoch nicht.
Wenden Sie sich mit einer begrenzten Auswahl abgleichbarer Beispiele und einer konkreten Frage an den Anbieter. Bitten Sie um Erläuterung der Bedeutung des Codes und der Stelle, an der die Antwort erzeugt wurde. Solange keine ausreichende Bestätigung vorliegt, beschreiben Sie den Befund als Hypothese oder beobachtete Abweichung, nicht als erwiesene Tatsache.
- Beobachteter Hinweis: „In der Stichprobe erscheinen diese Ereignisse auf der Plattform als abgelehnt.“
- Hypothese: „Das Muster könnte mit der vom Anbieter gemeldeten Antwort zusammenhängen; Ursprung und Bedeutung müssen noch bestätigt werden.“
- Bestätigte Schlussfolgerung: Verwenden Sie diese Einstufung nur, wenn übereinstimmende Datensätze und die erforderliche Validierung die Erklärung stützen.
- Kann der Anbieter oder die Plattform den Empfang auf dem Endgerät nicht bestätigen, halten Sie dies ausdrücklich fest.
Dokumentieren Sie Tests, Grenzen und Maßnahmen
Ein hilfreicher Bericht ermöglicht es anderen, nachzuvollziehen, was geprüft wurde und was weiterhin unbekannt ist. Halten Sie Fragestellung, Umfang, Auswahlmethode, Datenquellen, Definitionen der Statuswerte und Ergebnisse je Gruppe fest. Unterscheiden Sie zwischen Beobachtung, Hypothese, durchgeführtem Test und Schlussfolgerung. Geben Sie außerdem an, welche Belege die Interpretation ändern könnten.
Deutet die Analyse auf ein Integrationsproblem oder eine Compliance-Verpflichtung hin, beheben Sie den betreffenden Aspekt und überprüfen Sie das Ergebnis mit den autorisierten Kontrollen. Verändern Sie legitime Nachrichten nicht, um Filter zu umgehen. Wird eine Filterung vermutet, bitten Sie den Anbieter um eine Erklärung und prüfen Sie die einschlägigen Compliance-Anforderungen sowie die Konfiguration, bevor Sie den Ablauf ändern.
- Geben Sie Zeitraum sowie Ein- und Ausschlusskriterien an, ohne unnötige Inhalte oder Kennungen zu veröffentlichen.
- Notieren Sie Codes und Statuswerte wortgetreu und nennen Sie das meldende System. Leiten Sie daraus keine unbestätigten Ursachen ab.
- Dokumentieren Sie vereinbarte Maßnahmen, Verantwortliche und die für den Abschluss der Untersuchung erforderlichen Belege.
- Bewerten Sie die Stichprobe neu, wenn sich das Muster nach Ziel, Absender, Nachrichtenart oder Zeitraum verändert.
Häufige Fragen
Zeigt der Status „Abgelehnt“, wer die SMS blockiert hat?
Nicht unbedingt. Er bezeichnet den Status, den das anzeigende System meldet. Der Ursachencode kann bei der Untersuchung helfen. Seine Bedeutung muss jedoch geprüft und mit anderen Datensätzen abgeglichen werden, um den Ort und die Ursache zu bestimmen.
Bestätigt ein DLR, dass die Nachricht das Telefon erreicht hat?
Das sollte nicht automatisch angenommen werden. Ein DLR ist eine Statusmeldung. Die verfügbaren Belege bestätigen möglicherweise nicht unabhängig, dass die Nachricht auf dem Endgerät empfangen oder angezeigt wurde. Dokumentieren Sie, welches System die Meldung ausgegeben hat und welche Unsicherheit bleibt.
Wie groß sollte die Stichprobe sein?
Es gibt keine universelle, für alle Fälle belegte Stichprobengröße. Legen Sie Gruppen und Auswahlkriterien fest, halten Sie das geprüfte Volumen fest und verallgemeinern Sie die Ergebnisse nicht auf den gesamten Nachrichtenverkehr, wenn die Stichprobe begrenzt oder nicht repräsentativ ist.
Sollte ich den vollständigen Text jeder Nachricht speichern?
Nicht standardmäßig. Bewahren Sie Inhalte nur dann auf, wenn sie zur Beantwortung der Fragestellung nötig sind, und beschränken Sie den Zugriff. Wenn es ausreicht, verwenden Sie einen Verweis auf die Vorlage oder eine Kategorie und minimieren Sie die übrigen Daten.
Sollte ich den Text ändern, um eine Ablehnung zu vermeiden?
Ändern Sie legitime Nachrichten nicht mit dem Ziel, Filter zu umgehen. Wird ein Filterproblem vermutet, prüfen Sie die Hypothese mit dem Anbieter und kontrollieren Sie die betreffende Compliance sowie die Integration.
Verwendete Quellen
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA network resourcesGSMA
- Comprender los mensajes rechazadosSinch Support
- Estudio del servicio de mensajes cortos Aplicación a Persona (A2P)Instituto Federal de Telecomunicaciones (IFT)