Les classes de trafic ont des exigences incompatibles
Une seule identité d'expéditeur et une seule route, c'est simple, mais les classes qui la partagent ont des délais, des bases légales, des revues de contenu et des définitions de réussite différentes. Si elles partagent une route, le comportement de file d'une campagne affecte un code d'authentification, et une revue de contenu promotionnel touche l'identité qui porte ce code.
Cinq classes méritent d'être séparées : authentification, service, promotion, support et avis opérationnels urgents.
Ce qui doit différer
- Identité d'expéditeur et enregistrement. L'enregistrement 10DLC aux États-Unis comporte un cas d'usage déclaré qui influence le traitement du trafic ; confirmez les détails campagne par campagne avec votre fournisseur.
- Consentement et suppression. Une désinscription marketing n'est pas un blocage global, un blocage global doit être respecté, et la suppression ne doit pas bloquer un code demandé par l'utilisateur.
- Priorité de file et allocation de débit par classe, sinon un gros envoi consomme la capacité des autres.
- Politique de routes. Routes distinctes et, si possible, fournisseurs distincts ; le trafic promotionnel ne bascule jamais vers une route d'authentification.
- Politique de reprise et de délais : un délai utile par classe avec condition d'arrêt, plutôt qu'une répétition sans fin.
- Gouvernance du contenu et des modèles avec identité, identifiant de modèle et statut d'approbation enregistrés.
- Références de surveillance issues de l'historique du programme lui-même, pas de seuils universels.
- Réponse aux incidents par classe : qui est alerté, première action, définition de « résolu ».
Matrice d'isolation
| Dimension | Authentification | Service | Promotion | Support | Urgent |
|---|---|---|---|---|---|
| Identité | Dédiée, enregistrée | Dédiée ou avec le service | Dédiée au marketing | Bidirectionnelle | Dédiée ou service |
| Route | Dédiée, latence d'abord | Partagée seulement avec allocation imposée | Route propre, si possible fournisseur propre | Avec entrant | Dédiée avec repli propre |
| Priorité | La plus haute | Élevée | La plus basse, planifiée | Interactive | Priorité |
| Consentement | Demandé par l'utilisateur | Événement métier | Consentement enregistré | Conversation existante | Nécessité opérationnelle |
| Suppression | Blocages globaux seulement | Blocages globaux seulement | Désinscription marketing et globale | État de la conversation | Blocages globaux seulement |
| Délai | Le flux en cours | L'événement | Fenêtre de campagne, heures calmes | La session | Immédiat, avec escalade |
| Repli | Autre route d'authentification | Route de service | Jamais l'authentification | Route avec entrant | Chemin indépendant |
| Alertes | Distribution de latence et vérification | Mélange des statuts finaux | Throttling, rejets, désinscriptions | Entrant sans réponse | Accusé de réception |
Checklist de migration
- Classer le trafic existant et étiqueter chaque envoi avant tout changement.
- Consigner les références actuelles par programme et par route.
- Enregistrer les nouvelles identités par marché et attendre la confirmation.
- Provisionner des routes distinctes et des allocations de débit.
- Mettre en place files, priorités, délais et conditions d'arrêt par classe.
- Mettre en place la sémantique de suppression par classe et vérifier qu'une désinscription marketing ne bloque pas un code demandé.
- Migrer d'abord la classe la moins risquée, en général le promotionnel.
- Puis le service, et l'authentification en dernier, en gardant l'ancienne route au chaud.
- Séparer les alertes par classe, avec responsable et action.
- Refaire les références et retirer le chemin de repli mixte.
Flowstates vend et exploite des routes, prend en charge le BYOV et les modèles hybrides. L'isolation reste le même travail dans chaque modèle.