Sur cette page : Découvrez les bonnes pratiques pour réduire les coûts des SMS dans Adobe Journey Optimizer en maintenant les messages courts, en évitant les caractères spéciaux et l’encodage UCS-2, et en vérifiant le nombre de caractères avant l’envoi.
Les SMS sont généralement facturés par les fournisseurs sur la base d’une limite de 160 caractères par message. L’envoi de SMS peut générer des coûts supplémentaires si les messages sont divisés en plusieurs parties.
Suivez ces instructions pour optimiser votre stratégie d’envoi de messages et réduire les dépenses.
Rester concis keep-messages-short
Journey Optimizer autorise jusqu’à 1 500 caractères dans le corps d’un SMS. Un avertissement s’affiche lorsque vous dépassez cette limite et les messages au-delà de ce seuil déclenchent une erreur.
La plupart des fournisseurs de SMS prennent en charge le codage GSM 7 bits, qui permet à un SMS de contenir jusqu’à 160 caractères. Les messages qui dépassent cette longueur sont automatiquement partagés en plusieurs parties de SMS (concaténation) :
- Moins de 160 caractères : 1 partie de SMS
- Entre 161 et 306 caractères : 2 parties de SMS
- Entre 307 et 459 caractères : 3 parties de SMS
Pour réduire les coûts rédigez des messages contenant moins de 160 caractères afin qu’ils soient facturés comme une seule partie de SMS.
Par exemple, un message de 1 600 caractères consomme 10 crédits SMS, même s’il apparaît comme un message unique dans Journey Optimizer.
Éviter les caractères spéciaux qui augmentent la longueur avoid-special-characters
Certains caractères, tels que | ^ € { } [ ] ~ \, comptent pour deux caractères dans le codage GSM. En utilisant ces caractères dans votre message, vous risquez de dépasser plus rapidement la limite de 160 caractères.
Éviter le codage UCS-2 prevent-ucs2-encoding
Si le message contient des caractères non GSM, tels que du texte en chinois ou en arabe, des symboles de marque déposée ou des retours à la ligne causés par des outils de mise en forme avancée, le message sera codé par le fournisseur à l’aide d’UCS-2, qui ne prend en charge que 70 caractères par SMS.
L’utilisation du codage UCS-2 peut augmenter le nombre de caractères et, par conséquent, avoir un impact sur la facturation des messages par votre fournisseur de services.
Par exemple, un message Unicode de 200 caractères sera envoyé en 3 parties de SMS.
Bonnes pratiques de création authoring-best-practices
Rédigez le SMS final directement dans Journey Optimizer ou collez-le à partir d’applications en texte brut.
Évitez d’utiliser des applications en texte enrichi, car elles peuvent introduire des caractères masqués ou des sauts de ligne qui déclenchent l’utilisation du codage UCS-2, ce qui peut augmenter à la fois le nombre de parties de SMS et les coûts associés.
Vérifier le nombre de caractères avant l’envoi check-character-count
Utilisez des applications en texte brut ou une méthode de simulation dans Simuler du contenu pour vérifier le nombre de caractères.
Lorsque Journey Optimizer affiche le nombre de caractères, espaces compris, lors de la simulation du contenu, tenez compte des points suivants :
-
Il n’inclut pas les caractères générés par la personnalisation dynamique ni certains caractères spéciaux.
-
Le comptage x/1500 sert d’indicateur visuel de la limite technique de la payload, et non de la limite par message, par exemple la limite de 160 caractères du codage GSM 7 bits.
-
Adobe prend en charge le codage UTF-8 dans l’éditeur, qui diffère du codage GSM-7.
Présentation du reporting understanding-reporting
Le reporting de Journey Optimizer compte l’ensemble du message comme un envoi, indépendamment des parties de SMS.
Le reporting du fournisseur reflète le nombre de parties de SMS réellement envoyées. Vous devez le consulter afin de vérifier la facturation et tout éventuel dépassement. Si Adobe est votre fournisseur de SMS via Sinch, vous recevrez ce rapport de facturation séparément tous les mois.
Considérations relatives à la personnalisation personalization-considerations
La personnalisation dynamique peut augmenter la longueur d’un message. Par exemple, le fait de remplacer une variable par un long prénom peut ajouter des caractères supplémentaires.
Ressources supplémentaires additional-resources
Consultez les caractères pris en charge et les règles de codage dans le guide Sinch de prise en charge des caractères.
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page explains best practices to reduce SMS costs in Journey Optimizer by keeping messages short, avoiding special characters and UCS-2 encoding, and checking character counts before sending.
Intents:
- Keep SMS messages short to be billed as a single SMS part
- Avoid special characters that increase message length in GSM encoding
- Prevent UCS-2 encoding that reduces the per-SMS character allowance
- Check the character count before sending using Simulate content
- Interpret the difference between Journey Optimizer reporting and provider reporting
Glossary:
- GSM 7-bit encoding: Encoding supported by most SMS providers where a single SMS can contain up to 160 characters (product-specific)
- UCS-2 encoding: Encoding applied by the provider when a message includes non-GSM characters; it supports only 70 characters per SMS (product-specific)
- Concatenation: The automatic splitting of a message that exceeds 160 characters into multiple SMS parts (product-specific)
- Simulate content: The feature whose simulation methods let you verify character counts before sending (product-specific)
- x/1500 count: The visual indicator of the technical payload limit, not the per-message limit (product-specific)
- Journey Optimizer reporting: Reporting that counts the full message as one send, regardless of SMS parts (product-specific)
- Provider reporting: Reporting that reflects the actual number of SMS message parts used for delivery (product-specific)
Guardrails:
- Journey Optimizer allows up to 1,500 characters in an SMS message body; a warning appears when you exceed this limit, and messages beyond this threshold trigger an error (hard limit — enforced with an error).
- SMS messages are typically billed by providers based on a 160-character limit per message; GSM 7-bit encoding allows up to 160 characters per single SMS, and messages exceeding this length are automatically split into multiple SMS parts.
- Concatenation part counts: less than 160 characters is 1 SMS part; 161-306 characters is 2 SMS parts; 307-459 characters is 3 SMS parts.
- Special characters such as
| ^ € { } [ ] ~ \are counted as two characters in GSM encoding, so they reach the 160-character limit more quickly. - Non-GSM characters cause UCS-2 encoding, which supports only 70 characters per SMS.
- The x/1500 count is the technical payload limit, not the per-message limit (for example, the 160-character GSM 7-bit limit), and it does not include characters from dynamic personalization or certain special characters.
- Adobe supports UTF-8 encoding in the editor, which differs from GSM 7-bit encoding.
Terminology:
- Canonical name: SMS cost optimization — Acronym: n/a — variants: SMS cost best practices
- Do not confuse: “Journey Optimizer reporting” (counts the full message as one send regardless of SMS parts) ≠ “Provider reporting” (reflects the actual number of SMS parts used for delivery)
- Do not confuse: “x/1500 count” (technical payload limit) ≠ “160-character limit” (GSM 7-bit per-message billing limit)
- Do not confuse: “GSM 7-bit encoding” (160 characters per SMS) ≠ “UCS-2 encoding” (70 characters per SMS) ≠ “UTF-8 encoding” (supported in the editor)
FAQ:
- Q: What is the maximum SMS length in Journey Optimizer? — Up to 1,500 characters in the SMS message body; a warning appears when you exceed this limit, and messages beyond this threshold trigger an error.
- Q: Why is my single message billed as multiple SMS? — GSM 7-bit encoding allows up to 160 characters per SMS part, so longer messages are automatically split (concatenation) into multiple parts, and a 1,600-character message could consume 10 SMS credits even though it appears as a single message.
- Q: How do special characters affect message length? — Characters such as
| ^ € { } [ ] ~ \are counted as two characters in GSM encoding, so they reach the 160-character limit more quickly. - Q: What triggers UCS-2 encoding and why does it matter? — Non-GSM characters such as Chinese or Arabic text, trademark symbols, or hard returns from rich-formatting tools trigger UCS-2 encoding, which supports only 70 characters per SMS and can increase billing.
- Q: How can I check the character count before sending? — Use plain-text applications or either simulation method in Simulate content; note that the displayed count does not include characters from dynamic personalization or certain special characters.
- Q: Why do the Journey Optimizer and provider reports differ? — Journey Optimizer reporting counts the full message as one send regardless of SMS parts, while provider reporting reflects the actual number of SMS parts used for delivery.