View a markdown version of this page

Bonnes pratiques du RCS - AWS Messagerie SMS à l'utilisateur final
Design conversationnel et interactifStratégie de suggestionDesign riche en cartes et carrouselBonnes pratiques en matière de médiasTTL et stratégie de repliSurveillance et événementsVariance de rendu entre l'appareil et le clientOpt-out manipulation

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques du RCS

Grâce à la messagerie enrichie RCS, vous pouvez créer des expériences conversationnelles et interactives qui vont au-delà des SMS traditionnels. Cette rubrique fournit des conseils pour concevoir des messages RCS efficaces, notamment en ce qui concerne la stratégie de suggestion, la mise en page des cartes enrichies et des carrousels, l'optimisation des médias, l'expiration des messages, la planification des solutions de secours et la surveillance.

Pour plus de détails sur les fonctionnalités individuelles Configuration des suggestions RCSEnvoi de cartes RCS Rich, voirEnvoi de carrousels RCS,Configuration de l'expiration des messages RCS,Configuration de la solution de secours par SMS ou MMS par message, etÉvénements liés aux messages RCS.

Design conversationnel et interactif

Les messages RCS prennent en charge des éléments interactifs tels que les réponses suggérées, les actions suggérées, les cartes enrichies et les carrousels. Pour utiliser ces fonctionnalités de manière efficace, considérez chaque échange de messages comme faisant partie d'une conversation en cours plutôt que comme une notification unidirectionnelle.

Ouvrir avec contexte et options

Incluez un message d'accueil clair, indiquez ce que l'utilisateur peut faire et suggérez des réponses pour guider l'étape suivante. Cela définit les attentes et réduit les frictions.

Gardez les messages concis

Essayez de ne pas dépasser 300 caractères par message texte. Divisez les informations complexes en plusieurs messages ou utilisez une carte enrichie pour le contenu structuré.

Évitez les impasses

Chaque message doit mener à une étape suivante. Proposez des suggestions de suivi, une option de menu principal ou un chemin vers un agent humain.

Adressez-vous directement à l'utilisateur

Utilisez la deuxième personne. Écrivez « Votre rendez-vous est confirmé » plutôt que « Le rendez-vous a été confirmé ».

Stratégie de suggestion

Les suggestions (réponses et actions) apparaissent sous forme de puces interactives sous votre message. Ils réduisent la saisie, augmentent l'engagement et vous permettent d'acheminer les réponses par le biais de PostbackData valeurs structurées. Pour la liste complète des types de suggestions, voirConfiguration des suggestions RCS.

Rédigez des étiquettes d'action concises

Le Text champ est limité à 25 caractères. Utilisez un langage orienté vers l'action qui indique à l'utilisateur exactement ce qui se passe au toucher.

Exemples d'étiquettes de suggestion
Éviter Préférez
« Option 1 » « Réservez pour le lundi »
« Cliquez ici » « Afficher le statut de la commande »
« Plus d'informations » « Voir le détail des prix »

Offrez 3 à 5 options

Trois suggestions sont idéales pour la plupart des interactions. Vous pouvez inclure jusqu'à 11 suggestions par message (4 par carte riche), mais plus de 5 options à la fois ont tendance à surcharger les utilisateurs. Si vous avez besoin de plus de choix, utilisez un carrousel ou divisez le flux en plusieurs étapes.

Route sur PostbackData

À utiliser PostbackData pour la logique de routage du backend au lieu d'analyser le texte affiché. Cette approche prend en charge la localisation (vous pouvez modifier la visibilité par l'utilisateur Text sans modifier votre routage) et fournit un contexte structuré pour votre application.

Codez l'action, l'entité et le contexte dans la valeur postback. Par exemple :

confirm_order_12345
cancel_appointment_20260615
nav_main_menu

Utilisez des préfixes cohérents (tels quebook_,, confirm_cancel_,nav_) pour simplifier le routage dans votre backend.

Important

Gérez les postbacks périmés avec élégance. Un utilisateur peut choisir une suggestion quelques heures après l'avoir reçue. Vérifiez que l'entité référencée existe toujours et informez l'utilisateur si l'action n'est plus valide.

Design riche en cartes et carrousel

Les cartes enrichies et les carrousels présentent du contenu structuré (images, titres, descriptions et suggestions) dans un format visuel. Pour plus de détails sur la mise en œuvre, reportez-vous Envoi de cartes RCS Rich aux sections etEnvoi de carrousels RCS.

Cartes riches autonomes

  • Utilisez VERTICAL l'orientation pour obtenir le rendu le plus uniforme possible sur tous les appareils.

  • Utilisez la hauteur du TALL support pour donner aux images un espace d'affichage adéquat sur Android et iOS.

  • Veillez à ce que le titre et le texte de description soient concis. Certains clients recadrent le texte au-delà de trois lignes.

  • Les URL figurant dans le texte de description ne fonctionnent pas comme des liens sur tous les clients. Utilisez une action OpenUrl suggérée au lieu d'intégrer des liens dans les descriptions.

  • Incluez une suggestion claire d'appel à l'action par carte. De multiples actions concurrentes réduisent les taux de conversion.

Carrousels

  • Placez l'option recommandée ou la plus pertinente dans la première position de la carte. Les utilisateurs interagissent le plus avec la première carte visible.

  • Utilisez des suggestions externes (au niveau du message) pour les actions de navigation, telles que « Retour au menu » ou « Aide ». Réservez des suggestions au niveau de la carte pour les actions spécifiques à cette carte.

  • Veillez à ce que le contenu des cartes soit plus concis que celui des cartes autonomes, car les cartes carrousel ont moins d'espace vertical.

  • La hauteur du support de la carte carrousel est limitée à SHORT ou MEDIUM (elle n'TALLest pas prise en charge dans les carrousels).

  • Assurez-vous que le support combiné de toutes les cartes reste inférieur à 100 Mo. Optimisez les images avant de les télécharger.

Bonnes pratiques en matière de médias

Les fichiers multimédias (images, vidéos, PDF) améliorent l'engagement des messages, mais ajoutent de la taille de la charge utile et de la variabilité du rendu. Pour les exigences relatives au format et à la taille des fichiers, voirEnvoi de messages RCS enrichis.

  • Compressez les images avant de les télécharger. Utilisez le format JPEG pour les photos et le format PNG pour les graphiques transparents.

  • Conservez les fichiers vidéo à moins de 5 Mo pour une livraison fiable entre les opérateurs et les appareils.

  • Fournissez un ThumbnailUrl pour les messages vidéo et les fichiers volumineux. Les miniatures s'affichent pendant le chargement complet du contenu multimédia et améliorent l'expérience utilisateur en cas de connexions lentes.

  • Les animations GIF sont diffusées sur Android mais s'affichent sous forme de première image statique sur iOS. Ne vous fiez pas aux animations GIF pour transmettre des informations critiques.

  • Hébergez du contenu multimédia sur des URL HTTPS ou dans Amazon S3 (à l'aide d's3://URI). Toutes les URL des médias doivent correspondre au modèle. ^(https://|s3://).+$

TTL et stratégie de repli

La durée de vie (TTL) et la configuration de secours fonctionnent ensemble pour garantir que votre message parvienne à l'utilisateur même en cas d'échec de livraison du RCS. Pour plus de détails sur la mise en œuvre, reportez-vous Configuration de l'expiration des messages RCS aux sections etConfiguration de la solution de secours par SMS ou MMS par message.

Configuration des valeurs TTL

Définissez toujours une TimeToLive valeur pour les contenus sensibles au facteur temps. Associez le TTL à la fenêtre de pertinence du contenu.

Valeurs TTL recommandées par type de contenu
Type de contenu TTL recommandé
One-time mot de passe (OTP) ou code de vérification 30 à 120 secondes
Notification de vente flash Durée jusqu'à la fin de la vente
Rappel de rendez-vous Temps avant le rendez-vous
Mise à jour de livraison 1 à 4 heures
Note

Le minimum de l'API est de 1 seconde, mais un TTL d'au moins 10 secondes est recommandé pour permettre un délai de livraison suffisant. La durée maximale est de 172 800 secondes (48 heures).

Solution de secours par SMS ou MMS

Configurez un FallbackConfiguration pour les messages critiques (OTP, confirmations de commande, alertes de sécurité) afin que le contenu parvienne à l'utilisateur en cas d'échec ou d'expiration de la livraison RCS.

  • Définissez le Channel champ sur SMS ou MMS selon que vous avez besoin ou non d'un support multimédia dans la solution de secours.

  • Conservez les 1 600 caractères maximum (la MessageBody limite de remplacement, qui est inférieure à la limite de texte RCS de 3 072 caractères).

  • Testez la livraison de secours de bout en bout en envoyant à un numéro de téléphone qui ne prend pas en charge le RCS et en vérifiant que le message SMS ou MMS arrive bien.

Surveillance et événements

Utilisez les destinations des événements et les événements de diffusion pour surveiller les performances des messages et optimiser votre stratégie de messagerie. Pour plus de détails sur les types d'événements et leur configuration, consultezÉvénements liés aux messages RCS.

  • Configurez les destinations des événements avant de commencer les envois de production. Cela vous permet de capturer les événements de livraison, de lecture et d'expiration dès le début.

  • Surveillez les taux d'expiration des messages pour déterminer si vos valeurs TTL sont appropriées. Un taux d'expiration élevé indique que le TTL est trop court ou que de nombreux destinataires ne possèdent pas d' RCS-capable appareil.

  • Suivez les reçus de lecture à des fins de comparaison relative (A/B tests) plutôt que sous forme de mesure absolue. Tous les clients ne signalent pas leur état de lecture.

  • Utilisez les événements de confirmation de livraison pour annuler les délais de repli redondants dans la logique de votre application si vous gérez le repli en externe.

Variance de rendu entre l'appareil et le client

Les messages RCS s'affichent différemment selon les clients Android et iOS. Concevez en fonction du plus petit dénominateur commun et testez sur les deux plateformes avant de lancer une campagne.

Différences de rendu entre Android et iOS
Fonctionnalité Android iOS
Images GIF Animé Statique (première image uniquement)
Aperçu des liens sous forme de texte URL n'importe où dans le message L'URL doit être le dernier élément. Il est possible qu'il ne soit pas possible de cliquer sur une URL suivie d'un texte supplémentaire.
Hauteur des supports de cartes Convient aux tailles courtes, moyennes et hautes Affiche toutes les hauteurs verticales de manière identique. Peut ignorer la propriété de hauteur.
Suggestion de commande de puces Conservé tel qu'envoyé Pourrait réorganiser les chips
Persistance de l'action suggérée Les actions en dehors des cartes disparaissent une fois que vous les avez touchées. Les boutons de la carte sont conservés. Tous les boutons (avec ou sans carte) sont conservés après avoir touché le bouton.
Afficher le nom avec les caractères du chemin (/,\,:) Rendu tel qu'enregistré Les caractères peuvent être supprimés par la couche de rendu iOS
Image de bannière de l'agent Visible sur le profil de l'agent Non affiché
Lien vers la politique de confidentialité Visible sur le profil de l'agent Non affiché
Plusieurs contacts par type Toutes les entrées de contact sont visibles Seul le premier contact par type est visible (par ordre de liste)
Médias avec de grandes tailles de texte accessibles Rendu stable Peut recadrer les images lorsque les grandes tailles de texte sont activées
Badge de vérification du transporteur « Vérifié par [Carrier] » ou « Vérifié par Google » Valeurs de badge identiques. Rendu contrôlé par Apple.

Recommandations de conception basées sur ces différences :

  • Utilisez l'orientation VERTICAL de la carte pour une mise en page cohérente.

  • Placez les URL à la fin des messages texte pour garantir l'affichage des aperçus des liens sur iOS.

  • Ne vous fiez pas à l'animation GIF pour communiquer des informations essentielles.

  • Testez l'ordre des suggestions sur les deux plateformes si la séquence est significative pour le flux d'utilisateurs.

Afficher le rendu du nom sur iOS

L'application iOS Messages d'Apple peut supprimer les caractères qui ressemblent à des séparateurs de chemin du système d'exploitation (/,\,:) ou à des séquences d'échappement d'URL du nom de l'agent affiché. Ce comportement est contrôlé au niveau du système d'exploitation et ne peut pas être remplacé par AWS, Google, les opérateurs ou les partenaires de messagerie.

Pour éviter les incohérences entre les noms d'affichage :

  • Utilisez uniquement des caractères alphanumériques, des espaces, des tirets, des points et des signes de ponctuation standard (tels que&,',!) dans votre nom d'affichage.

  • N'utilisez pas de barres obliques, de barres obliques inverses ou de deux-points dans le nom de votre marque.

  • Si le nom de votre marque inclut ces caractères, envisagez une autre représentation (par exemple, utilisez un tiret ou un espace au lieu d'une barre oblique).

  • Vérifiez toujours l'apparence de votre agent sur un appareil de test iOS pendant la phase de test avant de demander le lancement du transporteur. C'est l'un des principaux objectifs des agents de test.

Si vous avez déjà lancé un agent dont le nom d'affichage est concerné et que vous devez le modifier, contactez AWS Support. Les changements de nom d'affichage sur les agents lancés nécessitent une nouvelle approbation du transporteur.

Visibilité du profil de l'agent sur iOS

Certains éléments du profil d'agent visibles sur Android ne sont pas affichés sur iOS :

  • Image de bannière : non affichée sur iOS. Ne vous fiez pas à la bannière pour communiquer des informations critiques sur la marque.

  • Lien vers la politique de confidentialité : Non visible dans la vue du profil de l'agent iOS. Assurez-vous que votre politique de confidentialité est accessible par d'autres moyens (tels que votre site Web ou une action suggérée dans votre message de bienvenue).

  • Contacts multiples : si vous configurez plusieurs numéros de téléphone, e-mails ou sites Web, iOS affiche uniquement la première entrée par type de contact. Placez votre contact principal en premier dans la liste lors de la configuration de votre agent.

Tests sur toutes les plateformes

Le rendu RCS dépend de la version du système d'exploitation, du modèle d'appareil et de la configuration du transporteur du destinataire. Avant de demander le lancement du transporteur :

  • Envoyez des messages de test aux appareils Android et iOS.

  • Vérifiez le nom d'affichage, le logo, la bannière, la description, les actions suggérées, les cartes enrichies et le contenu multimédia sur les deux plateformes.

  • Testez avec différentes tailles de texte et différents paramètres d'accessibilité sur iOS.

  • Vérifiez que les aperçus des liens s'affichent correctement sur les deux plateformes.

La mise en œuvre du RCS par Apple continue d'évoluer. Les comportements peuvent changer avec les mises à jour d'iOS. Surveillez votre expérience de messagerie après la sortie d'iOS et ajustez votre contenu en conséquence.

Opt-out manipulation

Respectez les préférences de désinscription des utilisateurs immédiatement et de manière cohérente sur tous les canaux de messagerie.

  • Respectez les mots clés STOP et UNSUBSCRIBE en cessant tous les messages non essentiels immédiatement après la demande de désinscription.

  • Envoyez une brève confirmation de désinscription qui inclut le nom de votre marque afin que l'utilisateur sache de quel expéditeur il s'est désinscrit.

  • Gérez votre propre base de données de désinscription et synchronisez-la sur tous les canaux (RCS, SMS, MMS) pour empêcher l'envoi sur un canal une fois que l'utilisateur s'est désinscrit sur un autre.

  • Consultez votre équipe juridique pour savoir quels types de messages (tels que les OTP ou les alertes de fraude) peuvent encore être envoyés après une désinscription.

Note

AWS La messagerie destinée aux utilisateurs finaux permet de gérer les listes de désinscription pour les SMS et les MMS. Pour RCS, coordonnez la gestion de votre désinscription avec les listes de désinscription des messages destinés aux utilisateurs AWS finaux et avec vos propres enregistrements au niveau de l'application.