Traffic-Klassen haben unvereinbare Anforderungen
Eine gemeinsame Absenderidentität und Route ist einfach, aber die Klassen darauf haben unterschiedliche Fristen, Rechtsgrundlagen, Inhaltsprüfungen und Erfolgsdefinitionen. Teilen sie eine Route, wirkt das Queue-Verhalten einer Kampagne auf einen Authentifizierungscode, und eine Inhaltsprüfung von Werbetexten trifft die Identität, die diesen Code trägt.
Fünf Klassen lohnen die Trennung: Authentifizierung, Service, Werbung, Support und dringende operative Meldungen.
Was sich unterscheiden muss
- Absenderidentität und Registrierung. Die 10DLC-Registrierung in den USA enthält einen deklarierten Use Case, der die Behandlung beeinflusst; Details sind pro Kampagne mit dem Anbieter zu klären.
- Consent und Suppression. Ein Marketing-Opt-out ist keine globale Sperre, eine globale Sperre ist zu beachten, und Suppression darf keinen angeforderten Code blockieren.
- Queue-Priorität und Durchsatzzuteilung pro Klasse, sonst verbraucht ein großer Versand die Kapazität der übrigen.
- Routenpolitik. Getrennte Routen und möglichst getrennte Anbieter; Werbung fällt niemals auf eine Authentifizierungsroute zurück.
- Retry- und Fristenpolitik: eine nutzbare Frist pro Klasse mit Stoppbedingung statt unbegrenzter Wiederholungen.
- Inhalts- und Template-Governance mit erfasster Identität, Template-ID und Freigabestatus.
- Monitoring-Baselines aus der eigenen Historie des Programms, keine universellen Schwellwerte.
- Incident Response pro Klasse: wer alarmiert wird, erste Maßnahme, Definition von "gelöst".
Isolationsmatrix
| Dimension | Authentifizierung | Service | Werbung | Support | Dringend |
|---|---|---|---|---|---|
| Identität | Dediziert, registriert | Dediziert oder mit Service geteilt | Dediziert für Marketing | Zwei-Wege-fähig | Dediziert oder Service |
| Route | Dediziert, Latenz zuerst | Nur mit erzwungener Zuteilung geteilt | Eigene Route, möglichst eigener Anbieter | Mit Inbound | Dediziert mit eigenem Fallback |
| Priorität | Höchste | Hoch | Niedrigste, geplant | Interaktiv | Vorrangig |
| Consent | Vom Nutzer angefordert | Geschäftsereignis | Erfasster Consent | Bestehende Konversation | Operative Notwendigkeit |
| Suppression | Nur globale Sperren | Nur globale Sperren | Marketing-Opt-out plus global | Konversationsstatus | Nur globale Sperren |
| Frist | Der laufende Flow | Das Ereignis | Kampagnenfenster, Ruhezeiten | Session | Sofort, mit Eskalation |
| Failover | Andere Authentifizierungsroute | Serviceroute | Nie Authentifizierung | Route mit Inbound | Unabhängiger Pfad |
| Alerting | Latenzverteilung und Verifizierung | Endstatus-Mix pro Route | Throttling, Ablehnungen, Opt-outs | Unbeantworteter Inbound | Bestätigung |
Migrations-Checkliste
- Bestehenden Traffic klassifizieren und jede Sendung markieren, bevor etwas geändert wird.
- Aktuelle Baselines pro Programm und Route festhalten.
- Neue Identitäten pro Markt registrieren und Bestätigung abwarten.
- Getrennte Routen und Durchsatzzuteilungen bereitstellen.
- Queues, Prioritäten, Fristen und Stoppbedingungen pro Klasse umsetzen.
- Suppression-Semantik pro Klasse umsetzen und prüfen, dass ein Marketing-Opt-out keinen angeforderten Code blockiert.
- Zuerst die risikoärmste Klasse migrieren, meist Werbung.
- Dann Service, zuletzt Authentifizierung, mit warmgehaltener alter Route.
- Alerting pro Klasse trennen, mit Owner und Aktion.
- Neu baselinen und den gemischten Fallback-Pfad entfernen.
Flowstates verkauft und betreibt Routen, unterstützt BYOV und hybride Modelle. Die Isolation bleibt in jedem Modell dieselbe Arbeit.