Cette page a été traduite automatiquement et peut contenir des inexactitudes. Pour signaler une erreur de traduction, utilisez le module de commentaires en bas de la table des matières, à droite de la page.

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, assurez-vous de sélectionner Web Browser dans le champ Send To lors de la création de votre Campaign de messages in-app ou de votre Canvas.

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

Cela dépend. Étant donné que les messages in-app sont distribués au démarrage de la session, si l’appareil parvient à télécharger le payload avant de passer hors ligne, le message in-app peut toujours s’afficher hors connexion. Si le payload n’est pas téléchargé, le message in-app ne s’affiche pas.

Si un utilisateur dispose déjà d’un payload de message in-app sur son appareil et que l’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 l’expiration a été modifiée 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 campagne de messages in-app ?

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

Comme solution de contournement pour envoyer des messages in-app pendant une plage horaire spécifique, utilisez l’exemple de code Liquid suivant. Cela permet d’interrompre le message si le message in-app est affiché après 19 h 59 ou avant 8 h dans le fuseau horaire spécifié.

{% 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 réception de la Campaign en activant la rééligibilité dans les Contrôles de réception (Autoriser les utilisateurs à redevenir éligibles à la réception de la Campaign). 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 Canvas pour le comportement des Campaigns, y compris la relation entre la rééligibilité et la réception des messages.

Si la rééligibilité est désactivée, les utilisateurs ne recevront généralement plus cette même Campaign après l’avoir reçue, sur la seule base des 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 (comme l’autorisation de réentrer dans le Canvas) et de la configuration de votre étape, et pas uniquement des contrôles de réception de la Campaign.

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

L’éligibilité à un message in-app est calculée au moment de la distribution. Si un message in-app est planifié pour être envoyé à 7 h, l’éligibilité est vérifiée pour ce message in-app à 7 h.

Lorsque le message in-app s’affiche, l’éligibilité dépend du moment où le message in-app est téléchargé et déclenché.

Pourquoi ma Campaign de messages in-app archivée continue-t-elle à 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 Campaign de messages in-app était active.

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

Pourquoi ne vois-je pas d’ouvertures pour les messages in-app ?

Les messages in-app n’utilisent pas d’indicateur Ouvertures. Braze enregistre les Impressions lorsque le message devient visible à l’écran et les Clics lorsque les utilisateurs interagissent avec le corps du message ou les boutons. Si un export ou un rapport multicanal inclut des lignes de messages in-app, comparez les Impressions et les Clics au lieu des ouvertures de type e-mail. Pour les définitions, consultez Rapports sur les messages in-app.

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

Oui, mais un seul message in-app peut s’afficher par occurrence d’un événement déclencheur. Si plusieurs Campaigns de messages in-app partagent le même déclencheur (par exemple, le démarrage de session), seul le message ayant la priorité la plus élevée s’affiche à chaque occurrence de ce déclencheur. Pour les déclencheurs de démarrage de session, cela signifie qu’un seul message peut s’afficher par session, et la prochaine occasion de montrer un autre message éligible sera la session suivante.

Lorsque plusieurs messages partagent le même niveau de priorité, le message créé le plus récemment s’affiche en premier. Pour les déclencheurs de démarrage de session, le message suivant le plus récent s’affiche lors d’une session ultérieure ; pour les autres types de déclencheurs, le message suivant le plus récent s’affiche la prochaine fois que cet événement déclencheur se produit, ce qui peut être au cours de la même session ou d’une session ultérieure.

Pour contrôler l’ordre d’affichage au sein d’un groupe de priorité, accédez aux paramètres de réception de l’une des Campaigns et sélectionnez Set exact priority, puis glissez-déposez les Campaigns 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 section Rapports sur les messages in-app pour savoir comment les impressions et les clics sont enregistrés en fonction des actions de l’utilisateur. Pour des exemples spécifiques aux messages plein écran créés avec l’éditeur traditionnel, reportez-vous à la section Indicateurs des messages plein écran par action de l’utilisateur.

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

Braze calcule un délai d’expiration d’un jour comme étant 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 en tant que messages in-app modélisés lorsque l’option Réévaluer l’éligibilité de la campagne avant l’affichage est sélectionnée ou si l’une des étiquettes Liquid suivantes est présente dans le message :

canvas_entry_properties
connected_content
Les variables SMS telles que {sms.${*}}
catalog_items
catalog_selection_items
event_properties

Cela signifie qu’au démarrage de la session, l’appareil reçoit le déclencheur de ce message in-app au lieu du message complet. Lorsque l’utilisateur déclenche le message in-app, son appareil effectue 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. Le message peut ne pas être distribué si la logique Liquid met trop de temps à se résoudre.

Comment fonctionne le comportement d’abandon pour les messages in-app ?

Chez Braze, un abandon se produit lorsqu’un utilisateur effectue une action qui le rend éligible à la réception d’un message, mais qu’il ne reçoit pas le message car la logique Liquid le marque comme inéligible. Par exemple :

Sam effectue une action qui devrait déclencher une Campaign par e-mail.
Le corps de l’e-mail contient une logique Liquid qui indique que si un attribut personnalisé de score est inférieur à 50, l’e-mail ne doit pas être envoyé.
Le score de l’attribut personnalisé de Sam est de 20.
Braze reconnaît que Sam ne devrait pas recevoir cet e-mail, et l’e-mail est abandonné.
Un événement d’abandon est enregistré.

Cependant, comme les messages in-app sont un canal de type « pull », les abandons fonctionnent un peu différemment pour eux.

Comportement d’abandon standard des messages in-app

Les messages in-app sont récupérés par l’appareil au démarrage de la session et mis en cache sur l’appareil, de sorte que, quelle que soit la qualité de la connexion Internet, le message peut être délivré instantanément à l’utilisateur. 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émarrage de la session. Les messages sont mis en cache localement et apparaissent lorsque leurs événements déclencheurs définis se produisent (démarrage de session, clic de l’utilisateur sur un bouton qui enregistre un événement personnalisé, ou autre).

En d’autres termes, la logique qui détermine si un message in-app doit être abandonné intervient avant que le déclencheur ne se soit produit. Pour illustrer cela, supposons que Sam, de l’exemple de l’e-mail, est abonné aux notifications push.

Sam démarre une session en lançant une application propulsée par Braze sur son téléphone.
En fonction des 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.
Sam n’a pas effectué d’actions qui déclencheraient ces messages, mais il pourrait recevoir ces messages au cours de la session.
Le Liquid de deux des messages in-app contient des règles qui excluent Sam de la réception du message (par exemple, son attribut personnalisé de score n’étant pas assez élevé).
Sam ne reçoit pas les deux messages in-app qui l’excluent, mais il reçoit les trois autres messages.
Aucun événement d’abandon n’est enregistré.

Braze n’enregistre aucun événement d’abandon dans le cas de Sam car cela ne correspond pas à la définition d’un abandon ; Sam n’a pas effectué d’actions qui déclencheraient 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 devraient pas voir le message.

Comportement d’abandon des messages in-app modélisés

Les messages in-app modélisés forcent le SDK à réévaluer si un message doit s’afficher lorsque l’événement déclencheur se produit. Cela entraîne un comportement d’abandon différent. Pour illustrer, considérez cet exemple :

Sam démarre une session Braze en lançant une application propulsée par Braze sur son téléphone.
Les critères d’audience des Campaigns actives indiquent que Sam pourrait être éligible à un message in-app modélisé, de sorte que les informations de déclenchement sont envoyées à son appareil sans le contenu du message.
Sam sélectionne un bouton qui enregistre un événement personnalisé, déclenchant le message in-app modélisé.
L’appareil de Sam effectue une requête réseau pour récupérer le message in-app.
La logique Liquid du message conduit à un abandon, donc Braze enregistre cela comme un abandon ; Sam a effectué l’action de déclenchement avant cette évaluation.

Comparaison du comportement d’abandon des messages in-app

Ce tableau compare les flux de messages in-app que Sam a expérimentés :

Message in-app	Comportement d’abandon
Standard	Aucun événement d’abandon n’a été enregistré car Sam n’a effectué aucune action qui déclencherait un message. Les messages in-app standard n’enregistrent pas d’abandons car la définition d’un abandon est « n’a pas vu le message malgré l’exécution de l’action de déclenchement ». Comme les messages in-app sont délivrés à l’appareil avant que les actions de déclenchement ne se produisent, il n’est pas pertinent de considérer les messages in-app omis en raison de la logique Liquid.
Modélisé	Un événement d’abandon a été enregistré car Sam a effectué l’action de déclenchement pour déclencher le message in-app modélisé, mais a reçu un abandon lors du traitement Liquid. Les messages in-app modélisés enregistrent les abandons car l’évaluation Liquid se produit après que l’action de déclenchement a été effectuée.

Message in-app

Comportement d’abandon

Standard

Aucun événement d’abandon n’a été enregistré car Sam n’a effectué aucune action qui déclencherait un message.

Les messages in-app standard n’enregistrent pas d’abandons car la définition d’un abandon est « n’a pas vu le message malgré l’exécution de l’action de déclenchement ». Comme les messages in-app sont délivrés à l’appareil avant que les actions de déclenchement ne se produisent, il n’est pas pertinent de considérer les messages in-app omis en raison de la logique Liquid.

Modélisé

Un événement d’abandon a été enregistré car Sam a effectué l’action de déclenchement pour déclencher le message in-app modélisé, mais a reçu un abandon lors du traitement Liquid.

Les messages in-app modélisés enregistrent les abandons car l’évaluation Liquid se produit après que l’action de déclenchement a été effectuée.

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 contenu 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.

Pourquoi y a-t-il un délai avant l’affichage de mon message in-app ?

Les messages in-app standard s’affichent dès que le contenu mis en cache est prêt après l’événement déclencheur. Sur Android et iOS, les images volumineuses ou d’autres ressources hébergées sur un CDN référencées dans le message peuvent ajouter un court délai pendant le téléchargement de ces ressources avant l’apparition du message in-app.

Les messages in-app modélisés et les Campaigns avec l’option Réévaluer l’éligibilité de la campagne avant l’affichage sélectionnée nécessitent une requête réseau supplémentaire après le déclencheur avant l’apparition du message. Cela peut ajouter un court délai (généralement inférieur à 100 ms sur une connexion stable). Pour plus d’informations, consultez 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 délivrés peuvent différer de l’aperçu du tableau de bord lorsque :

Votre intégration applique un style personnalisé ou remplace l’interface utilisateur par défaut des messages in-app sur certaines plateformes
L’aperçu utilise un profil utilisateur test avec des attributs différents de ceux du destinataire
Le contenu modélisé se résout différemment au moment de l’envoi par rapport au mode aperçu

Utilisez Envoyer des messages de test avec un utilisateur test dont le profil correspond à votre audience cible lors de la validation de l’apparence.

Pourquoi un message in-app multi-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 multi-pages, cet arrière-plan s’applique à toutes les pages du message. Pour utiliser des arrière-plans différents par page, utilisez un bloc HTML personnalisé avec du JavaScript pour changer les images entre les pages.

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 flux de test délivre une notification push qui ouvre l’application ou le site où le message in-app s’affiche. Le même chemin de test basé sur les notifications push s’applique sur toute plateforme où les notifications push ne sont pas configurées avec Braze, bien que l’absence de notifications push soit le plus souvent rencontrée sur le web car de nombreuses intégrations mobiles ont déjà les notifications push activées. Utilisez plutôt une Campaign en production vers un Segment de test interne. Pour les étapes, consultez Envoyer des messages de test.

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

Les messages in-app ne nécessitent pas de notifications push pour fonctionner en production. Les messages in-app sont délivrés via le SDK Braze et apparaissent pendant une session active de l’application sans avoir besoin d’une intégration push.

Cependant, les envois de test pour les 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 délivrés via une notification push qui déclenche l’affichage du message in-app. L’utilisateur test doit avoir les notifications push activées et doit appuyer sur 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 de vos déclencheurs de Campaign (tels que le démarrage de session ou les événements personnalisés) sans que les notifications push soient impliquées.

Pourquoi des caractères supplémentaires 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 casser le Liquid et le HTML dans les messages personnalisés.

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

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

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

Le SDK Android de Braze version 37.0.0 et ultérieures appliquent les marges intérieures de fenêtre (window insets) aux messages in-app HTML par défaut, afin que les contrôles restent dans la zone sûre. Si les utilisateurs constatent toujours un chevauchement, effectuez la mise à jour vers 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 le comportement par défaut.

Que dois-je savoir lors de la personnalisation des messages in-app par glisser-déposer ?

L’éditeur par glisser-déposer prend en charge les types d’affichage en fenêtre modale et en plein écran. Vous construisez le contenu à l’intérieur de ces conteneurs à l’aide de blocs éditeur.

Points à retenir :

Liens et deep links : Chaque action au clic dispose d’un champ URL par défaut. Utilisez Liquid dans l’URL pour varier les liens en fonction de l’appareil, du type d’application ou des attributs utilisateur. Sur le conteneur de message, vous pouvez également activer le comportement au clic spécifique à la plateforme pour définir des liens différents par plateforme.
Opacité et arrière-plans : L’opacité du conteneur de message affecte l’ensemble de l’arrière-plan du message. Les blocs individuels peuvent définir leurs propres couleurs d’arrière-plan. Pour un contrôle plus précis, ajoutez du CSS personnalisé dans un bloc de code personnalisé.
Largeur du message : La largeur maximale du conteneur de message ne peut pas être définie en dessous de 325 px dans l’éditeur, ce qui garantit la lisibilité du contenu sur les écrans plus petits. Utilisez du CSS personnalisé si vous avez besoin d’une mise en page plus étroite.
Arrière-plans spécifiques à la plateforme : Un même message utilise la même image d’arrière-plan et les mêmes couleurs sur le web et le mobile. Vous ne pouvez pas définir des arrière-plans différents par plateforme dans l’éditeur.
Messages multi-pages : Les images d’arrière-plan et les actions au clic au niveau du message s’appliquent à toutes les pages d’un message multi-pages. Pour utiliser des images plein écran différentes sur chaque page, ajoutez des boutons qui renvoient vers la page suivante.
Styles au niveau du message : Les styles au niveau du message s’appliquent à l’ensemble du message.
Images d’arrière-plan : Les images d’arrière-plan s’étirent pour s’adapter à la fenêtre modale.

Pour d’autres considérations relatives à 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’est généralement pas une erreur. Elle apparaît souvent lorsque Braze publie un événement interne (tel que NoMatchingTriggerEvent) et qu’aucun écouteur de message in-app ou de Content Cards n’est abonné à ce moment-là.

Si vous voyez ce journal alors que vous vous attendez à ce 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.

New Stuff!