Skip to content

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 campagne ou Canvas de messages in-app.

Un message in-app s’affichera-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, l’appareil est en mesure de télécharger le payload avant de passer hors ligne, et le message in-app peut toujours s’afficher hors ligne. Si le payload n’est pas téléchargé, le message in-app ne s’affichera pas.

Si un utilisateur a déjà un payload de message in-app sur son appareil et que l’expiration du message est modifiée, l’expiration sera-t-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 changé et qu’il 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é des 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 ne recevront des messages in-app que s’ils sont actifs dans l’application.

Comme solution de contournement pour envoyer des messages in-app à un moment précis, utilisez l’exemple de code Liquid suivant. Cela permet d’annuler le message si le message in-app est affiché après 19 h 59 ou avant 8 h dans le fuseau horaire spécifié.

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 campagnes de messages in-app, vous pouvez permettre aux utilisateurs de redevenir éligibles à la réception de la campagne en activant la rééligibilité dans les Contrôles de l’envoi (Allow users to become re-eligible to receive campaign). La rapidité avec laquelle ils peuvent le 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 campagnes et Canvas pour le comportement des campagnes, y compris la relation entre la rééligibilité et la réception du message.

Si la rééligibilité est désactivée, les utilisateurs ne recevront généralement plus cette même campagne 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 le fait d’autoriser les utilisateurs à réintégrer le Canvas) et de la configuration de votre étape, et pas uniquement des contrôles de distribution de la campagne.

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.

Une fois le message in-app affiché, l’éligibilité dépendra du moment où le message in-app est téléchargé et déclenché.

Pourquoi ma campagne 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 campagne de messages in-app était active.

Pour éviter cela, lors de la configuration de votre campagne, sélectionnez Re-evaluate campaign eligibility before displaying.

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 campagnes 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 d’afficher un autre message éligible est 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 niveau de priorité, accédez aux paramètres de distribution de l’une des campagnes et sélectionnez Set Exact Priority, puis glissez-déposez les campagnes dans l’ordre souhaité. Pour plus de détails, consultez Choisir une priorité.

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 24 heures après que les utilisateurs sont devenus é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 Re-evaluate campaign eligibility before displaying est sélectionné ou si l’une des étiquettes Liquid suivantes existe dans le message :

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

Cela signifie que lors du 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.

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

Chez Braze, une annulation 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 parce que sa logique Liquid le marque comme inéligible. Par exemple :

  1. Sam effectue une action qui devrait déclencher une campagne par e-mail.
  2. Le corps de l’e-mail contient une logique Liquid qui stipule que si un score d’attribut personnalisé est inférieur à 50, ne pas envoyer cet e-mail.
  3. Le score d’attribut personnalisé de Sam est de 20.
  4. Braze reconnaît que Sam ne devrait pas recevoir cet e-mail, et l’e-mail est annulé.
  5. Un événement d’annulation est enregistré.

Cependant, étant donné que les messages in-app sont un canal de type « pull », les annulations fonctionnent un peu différemment pour eux.

Comportement d’annulation 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 distribué 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 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 annulé se produit 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.

  1. Sam démarre une session en lançant une application propulsée par Braze sur son téléphone.
  2. En fonction des critères d’audience des campagnes actives dans l’espace de travail, Sam pourrait être éligible à cinq campagnes 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’actions qui déclencheraient ces messages, mais il pourrait recevoir ces messages au cours de la session.
  4. La logique Liquid de deux des messages in-app contient des règles qui excluent Sam de la réception du message (comme son attribut personnalisé de score n’étant pas assez élevé).
  5. Sam ne reçoit pas les deux messages in-app qui l’excluent, mais il reçoit les trois autres messages.
  6. Aucun événement d’annulation n’est enregistré.

Braze n’enregistre aucun événement d’annulation dans le cas de Sam car cela ne correspond pas à la définition d’une annulation ; 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’annulation 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’annulation différent. Pour illustrer, considérez cet exemple :

  1. Sam démarre une session Braze en lançant une application propulsée par Braze sur son téléphone.
  2. Les critères d’audience des campagnes 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 payload du message.
  3. Sam sélectionne un bouton qui enregistre un événement personnalisé, déclenchant le message in-app modélisé.
  4. L’appareil de Sam effectue une requête réseau pour récupérer le message in-app.
  5. La logique Liquid du message conduit à une annulation, donc Braze enregistre cela comme une annulation ; Sam a effectué l’action de déclenchement avant cette évaluation.

Comparaison du comportement d’annulation des messages in-app

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