Concevoir une matrice de tests SMS : destinations, encodages et types d'expéditeur
Un seul SMS de test qui arrive ne prouve pas le succès de votre campagne. Délivrabilité, expéditeur affiché et intégrité du contenu varient selon le marché de destination, l'encodage, le type d'expéditeur et le libellé. Concevez une matrice pré-envoi sur ces quatre axes, enregistrez les résultats terminal par cellule, priorisez le trafic réellement envoyé, et retestez quand les routes ou modèles changent - avec les crédits de test gratuits SMSRoute et les outils de test de délivrabilité du tableau de bord avant de payer.
Pourquoi un message livré par chance n'est pas un plan de test
Les équipes envoient souvent un SMS vers un terminal familier, le voient arriver et valident l'envoi. Cet échantillon est biaisé : il partage en général le marché local du testeur, un seul chemin d'encodage, une forme d'expéditeur et un texte non représentatif. Opérateurs et routes intermédiaires appliquent des régimes d'ID d'expéditeur, de jeux de caractères et de filtres de contenu différents selon le pays. Un succès sur un chemin ne dit rien des chemins que prendra votre trafic réel.
Une matrice de test traite ces différences comme des facteurs délibérés. Vous définissez des cellules sur les axes qui changent les résultats, envoyez un petit message contrôlé dans chaque cellule pertinente, et notez ce que le terminal affiche vraiment. L'objectif n'est pas une couverture statistique mondiale. C'est une preuve qualitative des combinaisons que vous facturerez - avant le volume, avant le gel des modèles et avant les tickets support.
Les comptes SMSRoute incluent des crédits de test gratuits qui prouvent la délivrabilité avant paiement, et des outils de test de délivrabilité sont disponibles dans le tableau de bord SMSRoute. Utilisez-les pour peupler la matrice ; ne brûlez pas le budget de production en contrôles ad hoc. Gardez des destinations E.164 cohérentes (jusqu'à 15 chiffres), journalisez les résultats API (HTTP 200 versus 429 ou 500) à part des résultats terminal, et traitez les identifiants d'état SMPP du pipeline comme signaux de transport - pas comme substituts de « affiché sur l'appareil ».
Les fiches pays SMSRoute recensent les régimes de sender ID et les classes de jeux de caractères qui définissent l'axe destinations de cette matrice.
Les quatre axes qui changent vraiment les résultats
Le marché de destination est le premier axe. Le régime d'ID d'expéditeur et la classe de jeu de caractères par défaut diffèrent par pays, et souvent par opérateur. Certains marchés acceptent les origines alphanumériques avec peu de friction ; d'autres réécrivent, suppriment ou exigent un traitement type enregistrement pour les identités alphanumériques. Longs codes numériques et shortcodes, s'ils existent, suivent encore d'autres règles. La classe de jeu de caractères compte : un modèle purement GSM-7 peut basculer en UCS-2 dès qu'un caractère non GSM apparaît - fréquent avec noms localisés, symboles monétaires hors GSM ou certaines ponctuations.
L'encodage est le deuxième axe. GSM-7 segmente à 160 caractères en partie simple et 153 par partie en concaténation. UCS-2 segmente à 70 et 67. Le même message peut donc se fragmenter autrement, emprunter d'autres chemins de filtre et se tronquer différemment selon qu'il reste en GSM-7. Testez la forme GSM-7 et la forme UCS-2 si le texte peut quitter l'alphabet GSM - ne supposez pas que la bascule automatique de la passerelle SMS correspond à ce que vos utilisateurs doivent voir.
Le type d'expéditeur est le troisième axe : alphanumérique versus numérique versus shortcode si le marché le permet. Les expéditeurs alphanumériques portent la marque mais sont les plus sensibles au régime. Les numériques se comportent souvent comme des MSISDN ordinaires et peuvent stabiliser l'affichage là où l'alphanumérique est instable. Les shortcodes sont spécifiques au marché et pas toujours disponibles ; ne les incluez que pour les destinations où vous détenez ou utiliserez cette origine. N'inventez jamais un type d'expéditeur que la route ne peut pas émettre.
La variante de contenu est le quatrième axe. Libellé transactionnel (concis, d'identité ou de reçu, peu de marketing) et libellé promotionnel (offres, urgence, appels à l'action) sont filtrés différemment sur bien des marchés. Liens versus sans liens : la présence d'URL change la longueur, la pression d'encodage et l'exposition aux filtres anti-arnaque. Construisez des variantes fidèles à la production - pas un texte de labo aseptisé.
Ce que chaque cellule enregistre
Chaque cellule de matrice lie un marché de destination, un encodage, un type d'expéditeur et une variante de contenu. Pour chaque cellule, notez quatre champs terminal. Premier : délivré sur le terminal oui/non - observé sur un appareil réel de ce marché, pas déduit d'un seul ack de soumission. Deuxième : expéditeur affiché - chaîne ou numéro exact dans la boîte de réception, y compris si une identité alphanumérique a été réécrite en numérique ou libellé générique. Troisième : contenu intact - corps conforme au modèle, fidélité des caractères, réassemblage des segments et intégrité du lien le cas échéant. Quatrième : latence - délai entre soumission acceptée et visibilité terminal, pour comparer p50 et p95 entre cellules plutôt qu'une seule mesure au chronomètre.
À côté des champs terminal, gardez des notes de transport : statut HTTP à la soumission (200, 429, 500), identifiants d'état SMPP exposés par l'intégration, nombre de segments selon 160/153 ou 70/67, et octets exacts envoyés. Séparez « accepté par l'API » de « affiché sur l'appareil ». Une acceptation sans confirmation terminal laisse la cellule incomplète. En cas d'échec, ne changez qu'un axe à la fois au re-test pour isoler le facteur.
Ne revendiquez pas une délivrabilité garantie sur une cellule verte. Un succès signifie que la combinaison a fonctionné sur la route et au moment du test. Les routes changent. Enregistrez horodatage, contexte de route ou de compte, modèle d'appareil si pertinent pour l'affichage, et hash ou libellé de version du modèle pour rattacher les plaintes ultérieures à une cellule connue.
Les fiches pays SMSRoute portent les régimes d'ID d'expéditeur et classes de jeux de caractères qui définissent l'axe destination de cette matrice.
Prioriser les cellules quand le budget est limité
Si les crédits de test sont limités, ne construisez pas le produit cartésien complet de tous les marchés, encodages, expéditeurs et variantes. Priorisez les cellules destination × contenu pour le trafic réellement prévu. Si 90 % du volume est des notifications transactionnelles vers un marché, avec liens dans certains modèles seulement, ces intersections destination-contenu passent en premier. Encodage et type d'expéditeur ne se déploient ensuite qu'à l'intérieur des destinations déjà justifiées.
Ordre pratique : (1) chaque marché de destination actif avec la variante de contenu dominante et le type d'expéditeur à industrialiser ; (2) la même destination avec la variante secondaire si vous mélangez styles transactionnel et promotionnel ; (3) scissions d'encodage là où les modèles peuvent quitter GSM-7 ; (4) types d'expéditeur alternatifs seulement si un plan de repli existe. Ignorez les cellules shortcode sauf si les shortcodes sont dans le périmètre de ce marché.
Un guidage qualitatif vaut mieux que de fausses cibles de couverture. Une matrice fine alignée sur le trafic réel est plus honnête qu'une matrice large remplie de marchés que vous ne messagerez jamais. Préférez une vraie observation terminal par cellule critique à de nombreuses soumissions automatisées sans contrôle d'affichage. Utilisez les crédits de test gratuits SMSRoute pour sécuriser le chemin critique d'abord ; élargissez seulement si une cellule échoue ou qu'un nouveau marché entre au plan.
Exemple concret : Allemagne et Pologne, deux modèles
Prenons une campagne bi-pays Allemagne et Pologne, avec deux modèles : T-txn (style transactionnel, sans lien, texte sûr GSM-7) et T-promo (style promotionnel, lien de suivi, peut introduire des caractères qui forcent UCS-2). Les deux marchés sont des destinations UE où affichage alphanumérique et filtrage sont sensibles à l'opérateur ; traitez le régime d'ID d'expéditeur comme classe d'enregistrement ou de réécriture, sans supposer un passage alphanumérique ouvert. Classe de jeu de caractères prévue : GSM-7 par défaut, repli UCS-2 si des caractères non GSM apparaissent dans noms, sujets ou URL.
Types d'expéditeur dans le périmètre : origine de marque alphanumérique en premier ; repli long code numérique si l'affichage alphanumérique est réécrit ou instable. Shortcodes hors périmètre ici sauf exploitation déjà en place sur le marché. Cellules d'encodage : GSM-7 pour T-txn ; pour T-promo, une tentative GSM-7 si lien et texte restent dans l'alphabet, plus une cellule UCS-2 explicite si caractères ou symboles localisés le forcent. Cellules de contenu : T-txn versus T-promo tels qu'écrits pour la production - pas un texte de labo paraphrasé.
Le tableau ci-dessous est une matrice de conception, pas un journal de résultats. Laissez délivré, expéditeur affiché, contenu intact et latence vides jusqu'aux contrôles terminal. N'inventez pas de succès/échec. Peuplez avec les crédits de test gratuits SMSRoute et les outils de test de délivrabilité du tableau de bord, une soumission contrôlée par cellule, appareils réels sur le marché ou terminaison de destination équivalente sous votre contrôle d'observation.
Après les passages, ne retenez que les cellules avec délivrance terminal, expéditeur affiché acceptable selon vos règles de marque, corps et lien intacts, et latence dans votre tolérance p50/p95. Si l'Allemagne alphanumérique T-promo échoue à l'affichage mais le numérique T-promo réussit, c'est un constat de type d'expéditeur - pas une raison de sauter les cellules Pologne. Ne relancez que les axes modifiés.
| id_cellule | destination | modèle | encodage | type_expéditeur | notes_contenu | livre_terminal | expediteur_affiche | contenu_intact | notes_latence |
|---|---|---|---|---|---|---|---|---|---|
| DE-T-txn-GSM7-alpha | Allemagne | T-txn | GSM-7 | alphanumerique | style transactionnel, sans lien | ||||
| DE-T-txn-GSM7-num | Allemagne | T-txn | GSM-7 | numerique | origine de repli si alpha reecrit | ||||
| DE-T-promo-GSM7-alpha | Allemagne | T-promo | GSM-7 | alphanumerique | style promotionnel, avec lien ; copie compatible GSM | ||||
| DE-T-promo-UCS2-alpha | Allemagne | T-promo | UCS-2 | alphanumerique | meme intention promo ; caracteres non-GSM presents | ||||
| PL-T-txn-GSM7-alpha | Pologne | T-txn | GSM-7 | alphanumerique | style transactionnel, sans lien | ||||
| PL-T-txn-GSM7-num | Pologne | T-txn | GSM-7 | numerique | origine de repli si alpha reecrit | ||||
| PL-T-promo-GSM7-alpha | Pologne | T-promo | GSM-7 | alphanumérique | style promotionnel, avec lien ; texte compatible GSM | ||||
| PL-T-promo-UCS2-alpha | Pologne | T-promo | UCS-2 | alphanumérique | même intention promo ; caractères non GSM présents |
Déclencheurs de re-test et bouclage
Une matrice complétée vieillit. Re-testez quand la route ou le chemin amont change, quand vous ajoutez un nouveau marché de destination, quand les plaintes ou rapports de non-distribution grimpent pour un modèle précédemment validé, ou quand vous réécrivez un modèle au point de changer la classe d'encodage, la présence de liens ou le ton (style transactionnel versus style promotionnel). Les évolutions du régime Sender-ID sur un marché (nouvelles attentes d'enregistrement, nouveau comportement de réécriture) sont aussi des déclencheurs même si votre texte est inchangé.
Lors du re-test, rejouez d'abord les cellules destination × contenu concernées, puis les variantes d'encodage et de type d'expéditeur qui comptaient auparavant. Comparez l'expéditeur affiché et l'intégrité du contenu au journal précédent, pas seulement la livraison binaire. Surveillez à nouveau les limites de segments : une petite modification du texte peut faire franchir à un message GSM-7 la limite 160/153 ou basculer GSM-7 en UCS-2 à 70/67, modifiant l'expérience utilisateur et l'exposition aux filtres.
Conservez la matrice comme artefact vivant à côté de votre dépôt de modèles. Versionnez les modèles, notez quels runs de crédits test SMSRoute correspondent à quel cell_id, et exigez une validation confirmée sur terminal avant de débloquer les expéditeurs et corps de production pour le volume. L'incertitude demeure : la terminaison mobile varie selon l'opérateur et le moment, mais une matrice disciplinée remplace la superstition par des contrôles documentés et reproductibles sur les axes qui changent réellement les résultats.
Questions fréquentes
- Que doit inclure une matrice de test SMS pré-envoi ?
- Définissez les cellules sur quatre axes : marché de destination (régime Sender-ID et classe de jeu de caractères), encodage (GSM-7 versus UCS-2, en tenant compte des limites de segments 160/153 et 70/67), type d'expéditeur (alphanumérique, numérique, shortcode si disponible), et variante de contenu (style transactionnel versus style promotionnel, liens versus sans liens). Par cellule, enregistrez la livraison sur terminal oui/non, l'expéditeur affiché, l'intégrité du contenu et la latence (y compris p50/p95 quand vous avez assez d'échantillons), plus les notes de transport comme HTTP 200/429/500.
- Quelles cellules de matrice de test SMS prioriser avec un petit budget ?
- Priorisez les cellules destination × contenu pour le trafic que vous enverrez réellement, avec le type d'expéditeur que vous comptez mettre en production. Ajoutez des splits d'encodage là où le texte peut quitter GSM-7, et des types d'expéditeur alternatifs seulement s'ils sont de vrais replis. Ignorez les marchés et shortcodes hors périmètre. Utilisez les crédits test gratuits SMSRoute et les outils de test de livraison du tableau de bord pour valider ce chemin critique avant une exploration plus large.
- Quand re-tester la livraison SMS après la matrice initiale ?
- Re-testez après un changement de route, de nouveaux marchés de destination, des pics de plaintes ou de non-livraison, et des réécritures de modèles qui altèrent l'encodage, les liens ou le ton promotionnel versus transactionnel. Re-testez aussi quand le comportement du régime Sender-ID change sur un marché. Rejouez d'abord les cellules destination × contenu concernées et confirmez l'affichage sur terminal, pas seulement l'acceptation API.