Questions fréquemment posées

Cet article fournit des réponses à certaines questions fréquemment posées sur les messages in-app.

Qu’est-ce qu’un message dans le navigateur et en quoi diffère-t-il d’un message in-app ?

Les messages dans le navigateur sont des messages in-app envoyés aux navigateurs web. Pour créer un message dans le navigateur, veillez à sélectionner Navigateur web dans le champ Envoyer à lors de la création de votre Campaign de message in-app ou de votre Canvas.

Un message in-app s’affiche-t-il si l’appareil est hors ligne ?

Cela dépend. Les messages in-app étant distribués au démarrage de la session, si l’appareil a pu télécharger le payload avant de passer hors ligne, le message in-app peut tout de même s’afficher hors ligne. Si le payload n’a pas été téléchargé, le message in-app ne s’affiche pas.

Si un utilisateur a déjà le payload d’un message in-app sur son appareil et que la date d’expiration du message est modifiée, l’expiration est-elle mise à jour sur son appareil ?

Lorsqu’un utilisateur démarre une session, Braze vérifie si des modifications ont été apportées aux messages in-app auxquels il est éligible et les met à jour en conséquence. Ainsi, si la date d’expiration a changé et que l’utilisateur enregistre une session, le message in-app est envoyé à l’appareil avec les informations mises à jour.

Comment configurer les heures calmes pour une Campaign de messages in-app ?

La fonctionnalité Heures calmes n’est pas disponible pour les Campaigns de messages in-app. Elle sert à empêcher l’envoi de messages à vos utilisateurs pendant certaines heures. Pour les Campaigns de messages in-app, vos utilisateurs reçoivent des messages in-app uniquement s’ils sont actifs dans l’application.

Pour contourner cette limite et envoyer des messages in-app pendant une plage horaire précise, utilisez l’exemple de code Liquid suivant. Il permet d’interrompre le message si le message in-app s’affiche après 19 h 59 ou avant 8 h dans le fuseau horaire indiqué.

1
2
3
4
5

{% assign time = 'now' | time_zone: ${time_zone} %}{% assign hour = time | date: '%H' | plus: 0 %}
{% if hour > 19 or hour < 8 %}
{% abort_message("Outside allowed time window") %}
{% endif %}
MESSAGE HERE

Les utilisateurs peuvent-ils recevoir à nouveau un message in-app après l’avoir fermé ?

Campaigns

Pour les Campaigns de messages in-app, vous pouvez permettre aux utilisateurs de redevenir éligibles à la Campaign en activant la rééligibilité dans les Contrôles de distribution (Autoriser les utilisateurs à redevenir éligibles pour recevoir la campagne). Le délai avant qu’ils puissent la recevoir à nouveau dépend de la fenêtre de rééligibilité que vous définissez et de la manière dont Braze a enregistré l’envoi précédent. Consultez Rééligibilité pour les Campaigns et les Canvas pour en savoir plus sur le comportement des Campaigns, notamment sur le lien entre la rééligibilité et la réception des messages.

Si la rééligibilité est désactivée, les utilisateurs qui ont déjà reçu cette Campaign ne la recevront généralement pas à nouveau, même s’ils remplissent toujours les critères de qualification.

Canvas

Pour les messages in-app envoyés depuis un Canvas, la possibilité pour un utilisateur de revoir le message dépend des contrôles d’entrée du Canvas (par exemple, l’autorisation pour les utilisateurs de rentrer à nouveau dans le Canvas) et de la configuration de vos étapes, et pas uniquement des contrôles de distribution de la Campaign.

Quand l’éligibilité à un message in-app est-elle calculée ?

Campaigns

Pour les Campaigns de messages in-app, Braze vérifie si un utilisateur fait partie de votre audience cible au moment où son appareil télécharge les messages in-app. Cela se produit généralement au début de la session. L’appareil stocke les messages éligibles et affiche chacun d’eux lorsque son déclencheur se produit, même plus tard dans la session.

Pour les Campaigns dont l’heure de début est programmée, Braze envoie aussi le message aux appareils qui démarrent une session jusqu’à une heure avant cette heure de début. Le message est ainsi prêt à s’afficher à temps. Par exemple, un utilisateur qui démarre une session à 6 h 30 reçoit une Campaign qui commence à 7 h. Braze vérifie son éligibilité à 6 h 30, et le message s’affiche lorsque son déclencheur se produit après 7 h.

Éligibilité en cours de session

Les utilisateurs qui deviennent éligibles en cours de session reçoivent le message au début de leur session suivante.

Pour vérifier à nouveau l’éligibilité juste avant l’affichage du message, sélectionnez Réévaluer l’éligibilité à la campagne avant l’affichage. Si l’utilisateur ne remplit plus les conditions, le message ne s’affiche pas. Ce paramètre n’envoie pas le message aux utilisateurs devenus éligibles après le début de leur session. Pour en savoir plus, consultez Choisir les utilisateurs à cibler.

Canvas

Pour les messages in-app d’un Canvas, Braze vérifie l’audience de l’étape lorsque l’utilisateur atteint cette étape. Le message est ensuite téléchargé au début de la session suivante de l’utilisateur.

Pourquoi ma campagne de messages in-app archivée continue-t-elle de générer des impressions de messages in-app ?

Cela peut se produire pour les utilisateurs qui remplissaient les critères du segment lorsque la campagne de messages in-app était active.

Pour éviter cela, sélectionnez Réévaluer l’éligibilité à la campagne avant l’affichage lors de la configuration de votre campagne.

Pourquoi les messages in-app n’affichent-ils pas d’ouvertures ?

Les messages in-app n’utilisent pas d’indicateur Ouvertures. Braze enregistre des Impressions lorsque le message s’affiche à l’écran, et des Clics lorsque les utilisateurs interagissent avec le corps du message ou ses boutons. Si un export ou un rapport multicanal contient des lignes de messages in-app, comparez les Impressions et les Clics plutôt que les ouvertures, propres aux e-mails. Pour consulter les définitions, reportez-vous à la section Rapports sur les messages in-app.

Plusieurs messages in-app peuvent-ils s’afficher au cours d’une même session ?

Oui, mais un seul message in-app peut s’afficher à chaque occurrence d’un événement déclencheur. Si plusieurs Campaigns de messages in-app partagent le même déclencheur (par exemple, le début de session), seul le message dont la priorité est la plus élevée s’affiche à chaque fois que ce déclencheur se produit. Pour les déclencheurs de début de session, cela signifie qu’un seul message peut s’afficher par session : un autre message éligible ne pourra s’afficher qu’à la session suivante.

Lorsque plusieurs messages ont le même niveau de priorité, le message créé le plus récemment s’affiche en premier. Pour les déclencheurs de début de session, le message suivant le plus récent s’affiche lors d’une session ultérieure. Pour les autres types de déclencheurs, il s’affiche la prochaine fois que l’événement déclencheur se produit, que ce soit au cours de la même session ou d’une session ultérieure.

Pour contrôler l’ordre d’affichage au sein d’un compartiment de priorité, accédez aux paramètres de livraison de l’une des Campaigns et sélectionnez Set Exact Priority, puis faites glisser les Campaigns pour les placer dans l’ordre souhaité. Pour plus de détails, consultez Choisir une priorité.

Comment les impressions et les clics des messages in-app sont-ils enregistrés ?

Consultez la page Rapports sur les messages in-app pour savoir comment les impressions et les clics sont enregistrés en fonction des actions des utilisateurs. Pour des exemples propres aux messages plein écran créés avec l’éditeur traditionnel, reportez-vous à Indicateurs des messages plein écran par action utilisateur.

Comment Braze calcule-t-il l’expiration d’un message in-app définie sur « après 1 jour(s) » ?

Braze calcule une durée d’expiration d’un jour comme correspondant à 24 heures après le moment où les utilisateurs deviennent éligibles à la réception d’un message.

Que sont les messages in-app modélisés ?

Les messages in-app sont distribués sous forme de messages in-app modélisés lorsque l’option Réévaluer l’éligibilité à la campagne avant l’affichage est sélectionnée, ou si l’une des étiquettes Liquid suivantes figure dans le message :

• canvas_entry_properties
• connected_content
• Variables SMS telles que {sms.${*}}
• catalog_items
• catalog_selection_items
• event_properties

Braze utilise également la distribution modélisée pour les Campaigns de messages in-app inactives (des Campaigns toujours actives, mais qui n’envoient plus de messages ou ne sont plus nécessaires). Ces Campaigns continuent de suivre les règles d’audience et de déclenchement que vous avez configurées.

Braze peut aussi recourir à la distribution modélisée pour préserver les performances de l’application. Si la préparation du contenu Liquid retarde la réponse de session de plus de quelques secondes, Braze reporte le traitement restant. Ces messages sont alors rendus au moment de leur déclenchement.

Concrètement, au démarrage de la session, l’appareil reçoit le déclencheur du message in-app plutôt que le message complet. Lorsque l’utilisateur déclenche le message in-app, son appareil envoie une requête réseau pour récupérer le message réel.

Remarque

Le message n’est pas distribué si l’appareil n’a pas accès à Internet. Il peut également ne pas être distribué si la résolution de la logique Liquid prend trop de temps.

Pour réduire la quantité de Liquid que Braze traite au démarrage de la session, consultez la section Optimiser les performances des messages in-app.

Comment fonctionne l’abandon pour les messages in-app ?

Chez Braze, un abandon se produit lorsqu’un utilisateur effectue une action qui le rend éligible à un message, mais qu’il ne le reçoit pas parce que la logique Liquid de ce message le rend inéligible. Par exemple :

1. Sam effectue une action censée déclencher une Campaign par e-mail.
2. Le corps de l’e-mail contient une logique Liquid indiquant de ne pas envoyer l’e-mail si l’attribut personnalisé « score » est inférieur à 50.
3. L’attribut personnalisé « score » de Sam est de 20.
4. Braze détermine que Sam ne doit pas recevoir cet e-mail, et l’envoi est abandonné.
5. Un événement d’abandon est enregistré.

Cependant, comme les messages in-app relèvent d’un canal de type « pull », l’abandon fonctionne un peu différemment pour eux.

Abandon des messages in-app standard

Les messages in-app sont récupérés par l’appareil au début de la session et mis en cache sur celui-ci : quelle que soit la qualité de la connexion Internet, le message peut ainsi s’afficher instantanément. Par exemple, si un utilisateur reçoit cinq messages in-app au cours de sa session, il les reçoit tous les cinq au début de la session. Les messages sont mis en cache localement et s’affichent lorsque leurs événements déclencheurs définis se produisent (début de session, clic sur un bouton qui enregistre un événement personnalisé, etc.).

Autrement dit, la logique qui détermine si un message in-app doit être abandonné s’exécute avant que le déclencheur ne se produise. Pour illustrer ce point, imaginons que Sam, notre utilisateur de l’exemple de l’e-mail, soit abonné aux notifications push.

1. Sam démarre une session en lançant une application équipée de Braze sur son téléphone.
2. D’après les critères d’audience des Campaigns actives dans l’espace de travail, Sam pourrait être éligible à cinq Campaigns différentes. Les cinq sont récupérées sur son téléphone et mises en cache.
3. Sam n’a pas effectué d’action susceptible de déclencher ces messages, mais pourrait les recevoir au cours de la session.
4. Le Liquid de deux des messages in-app contient des règles qui excluent Sam (par exemple, son attribut personnalisé « score » n’est pas assez élevé).
5. Sam ne reçoit pas les deux messages in-app qui l’excluent, mais reçoit les trois autres.
6. Aucun événement d’abandon n’est enregistré.

Braze n’enregistre aucun événement d’abandon dans le cas de Sam, car la situation ne correspond pas à la définition d’un abandon : Sam n’a pas effectué d’action susceptible de déclencher les messages. Pour les messages in-app, les utilisateurs n’effectuent jamais réellement le déclencheur avant que Braze ne détermine qu’ils ne doivent pas voir le message.

Abandon des messages in-app modélisés

Les messages in-app modélisés obligent le SDK à réévaluer si un message doit s’afficher au moment où l’événement déclencheur se produit. L’abandon fonctionne donc différemment. Prenons l’exemple suivant :

1. Sam démarre une session Braze en lançant une application équipée de Braze sur son téléphone.
2. Les critères d’audience des Campaigns actives indiquent que Sam pourrait être éligible à un message in-app modélisé : les informations de déclenchement sont donc envoyées sur son appareil, sans le payload du message.
3. Sam sélectionne un bouton qui enregistre un événement personnalisé, ce qui déclenche le message in-app modélisé.
4. L’appareil de Sam envoie une requête réseau pour récupérer le message in-app.
5. La logique Liquid du message entraîne un abandon, et Braze l’enregistre comme tel : Sam a effectué l’action de déclenchement avant cette évaluation.

Comparaison des comportements d’abandon des messages in-app

Ce tableau compare les deux parcours de messages in-app vécus par Sam :

Quand le contenu connecté s’exécute-t-il pour les messages in-app ?

Pour les messages in-app modélisés, le contenu connecté et les autres étiquettes Liquid sont résolus lorsque l’événement déclencheur se produit et que l’appareil demande le payload du message, et non lorsque l’utilisateur clique sur un bouton à l’intérieur du message. Chaque récupération modélisée peut inclure des appels de contenu connecté pour cet affichage.

Si votre HTML fait référence à des données REST renvoyées par le contenu connecté, ces données sont disponibles pour la session au cours de laquelle le message a été modélisé. Plusieurs boutons peuvent faire référence à la même réponse de contenu connecté sans déclencher d’appels supplémentaires au clic.

Quel est le délai maximal après un déclencheur pour les Campaigns de messages in-app ?

Les Campaigns de messages in-app peuvent retarder la distribution jusqu’à deux heures (7 200 secondes) après l’événement déclencheur. Les options de délai sont Immédiatement et Après un délai. Pour une attente plus longue, ajoutez une étape Délai avant une étape de message in-app dans un Canvas. Pour configurer le délai, consultez la section Livraison par événement.

Pourquoi mon message in-app s’affiche-t-il avec un délai ?

Les messages in-app standard s’affichent dès que le payload mis en cache est prêt après l’événement déclencheur. Sur Android et iOS, les images volumineuses ou les autres ressources hébergées sur un CDN et référencées dans le message peuvent entraîner un léger délai, le temps que ces ressources finissent de se télécharger avant l’affichage du message in-app.

Les messages in-app modélisés et les Campaigns pour lesquelles l’option Réévaluer l’éligibilité à la campagne avant l’affichage est sélectionnée nécessitent une requête réseau supplémentaire après le déclencheur, avant l’affichage du message. Cela peut ajouter un léger délai (généralement moins de 100 ms avec une connexion stable). Pour plus d’informations, consultez la section Choisir les utilisateurs à cibler.

Pourquoi mon message in-app est-il différent de l’aperçu du tableau de bord ?

Les messages in-app distribués peuvent différer de l’aperçu du tableau de bord dans les cas suivants :

• Votre intégration applique un style personnalisé ou remplace l’interface par défaut des messages in-app sur certaines plateformes
• L’aperçu utilise un profil d’utilisateur test dont les attributs diffèrent de ceux du destinataire
• Le contenu modélisé est résolu différemment au moment de l’envoi qu’en mode aperçu

Pour valider l’apparence, utilisez la fonction Envoyer des messages de test avec un utilisateur test dont le profil correspond à votre audience cible.

Pourquoi un message in-app de plusieurs pages utilise-t-il le même arrière-plan sur chaque page ?

Lorsque l’option Image d’arrière-plan est activée sur une page d’un message in-app de plusieurs pages, cet arrière-plan s’applique à toutes les pages du message. Pour utiliser un arrière-plan différent sur chaque page, utilisez un bloc HTML personnalisé avec du JavaScript afin d’alterner les images d’une page à l’autre.

Comment tester les messages in-app web ?

Les envois de test de messages in-app web nécessitent que les notifications push soient activées sur l’appareil de test, car le processus de test envoie une notification push qui ouvre l’application ou le site où s’affiche le message in-app. Ce même processus de test basé sur les notifications push s’applique à toute plateforme sur laquelle les notifications push ne sont pas configurées avec Braze, mais l’absence de notifications push se rencontre le plus souvent sur le web, car de nombreuses intégrations mobiles les ont déjà activées. Utilisez plutôt une Campaign en ligne ciblant un segment de test interne. Pour connaître les étapes, consultez Envoyer des messages de test.

Les messages in-app nécessitent-ils une intégration des notifications push ?

Les messages in-app n’ont pas besoin des notifications push pour fonctionner en production. Ils sont distribués via le SDK de Braze et s’affichent pendant une session active de l’application, sans intégration des notifications push.

En revanche, les envois de test de messages in-app nécessitent que les notifications push soient activées sur vos appareils de test. En effet, les messages in-app de test sont distribués via une notification push qui déclenche l’affichage du message in-app. L’utilisateur test doit avoir activé les notifications push et toucher la notification push de test pour voir le message in-app.

Pour les Campaigns en production, les utilisateurs voient les messages in-app en fonction des déclencheurs de vos Campaigns (comme le début de session ou des événements personnalisés), sans intervention des notifications push.

Pourquoi des caractères superflus ou non rendus apparaissent-ils dans mon message in-app ?

Copier du texte depuis une autre application (comme un traitement de texte ou une page web) peut insérer des caractères invisibles ou non imprimables dans le corps de votre message. Ces caractères peuvent apparaître sous forme de symboles parasites ou perturber le Liquid et le HTML dans les messages personnalisés.

Pour corriger ces caractères parasites ou non rendus, saisissez à nouveau le texte concerné dans l’éditeur de Braze, ou supprimez directement les caractères indésirables plutôt que de sélectionner et remplacer uniquement le texte visible. Pour les messages HTML personnalisés contenant des caractères spéciaux, ajoutez <meta charset="UTF-8"> dans la balise <head> de votre HTML. Pour plus de détails, consultez la section Encodage des caractères.

Pourquoi le bouton de fermeture est-il masqué sur les messages in-app HTML en plein écran sur Android ?

Sur les appareils dotés d’un affichage bord à bord (y compris Android 15 et versions ultérieures), les messages in-app HTML en plein écran peuvent s’afficher derrière la barre d’état du système et masquer un contrôle de fermeture situé en haut de la mise en page.

À partir de la version 37.0.0, le SDK Android de Braze applique par défaut les encarts de fenêtre aux messages in-app HTML afin que les contrôles restent dans la zone de sécurité. Si les utilisateurs constatent toujours un chevauchement, passez à la dernière version du SDK Android de Braze.

Sur les versions antérieures du SDK, les développeurs pouvaient activer BrazeConfig.setIsHtmlInAppMessageApplyWindowInsetsEnabled(true) avant que ce comportement ne devienne la valeur par défaut.

Que faut-il savoir pour personnaliser les messages in-app par glisser-déposer ?

L’éditeur par glisser-déposer prend en charge les types d’affichage modal et plein écran. Vous créez le contenu à l’intérieur de ces conteneurs à l’aide de blocs éditeur.

Gardez les points suivants à l’esprit :

• Liens et deep links : Par défaut, chaque action au clic dispose d’un seul champ URL. Utilisez Liquid dans l’URL pour adapter les liens selon l’appareil, le type d’application ou les attributs de l’utilisateur. Dans le Conteneur de message, vous pouvez aussi activer un comportement au clic propre à chaque plateforme pour définir des liens différents selon la plateforme.
• Opacité et arrière-plans : L’opacité du conteneur de message s’applique à l’ensemble de l’arrière-plan du message. Chaque bloc peut définir sa propre couleur d’arrière-plan. Pour un contrôle plus précis, ajoutez du CSS personnalisé dans un bloc Code personnalisé.
• Largeur du message : Dans l’éditeur, la largeur maximale du Conteneur de message ne peut pas être inférieure à 325 px, afin que le contenu reste lisible sur les petits écrans. Utilisez du CSS personnalisé si vous avez besoin d’une mise en page plus étroite.
• Arrière-plans par plateforme : Un même message utilise la même image d’arrière-plan et les mêmes couleurs sur le web et sur mobile. Vous ne pouvez pas définir d’arrière-plans différents par plateforme dans l’éditeur.
• Messages de plusieurs pages : Les images d’arrière-plan et les actions au clic définies au niveau du message s’appliquent à toutes les pages d’un message de plusieurs pages. Pour utiliser une image complète différente sur chaque page, ajoutez des boutons qui renvoient vers la page suivante.
• Styles au niveau du message : Les styles définis au niveau du message s’appliquent à l’ensemble du message.
• Images d’arrière-plan : Les images d’arrière-plan sont étirées pour s’adapter à la fenêtre modale.

Pour découvrir d’autres points à prendre en compte concernant l’éditeur, consultez le guide de préparation des messages in-app.

Que signifie « Event was published, but no subscribers were found » dans les journaux du SDK Android ?

Cette ligne de journal n’indique généralement pas une erreur. Elle apparaît souvent lorsque Braze publie un événement interne (comme NoMatchingTriggerEvent) et qu’aucun écouteur de message in-app ou de Content Card n’est abonné à ce moment-là.

Si ce journal s’affiche alors que vous attendez qu’un événement personnalisé déclenche un message in-app, vérifiez que l’événement est bien enregistré, que l’utilisateur fait partie de l’audience de la Campaign ou du Canvas, et que les Content Cards sont synchronisées lorsque le message en dépend.