Assurez-vous que vos règles d'audience ou de page sont configurées avec la logique correcte. Par exemple, si vous combinez plusieurs règles négatives (« is not », « does not contain »), vous voudrez presque toujours les séparer avec 'AND', et non 'OR'. Et si vous utilisez un filtre d'égalité "URL is", assurez-vous d'avoir inclus l'URL complète, y compris la partie https:// et les éventuels slashs finaux. Vous pouvez trouver plus de conseils sur la configuration efficace de vos filtres ici.

Did the user receive it on the correct page initially, then navigate to a different page after? Due to 'follow page' behavior, if an in-app message isn't engaged with (clicked on or closed), it persists as the user navigates to other pages — including pages explicitly excluded from your URL rules — until they engage with it. Try checking the user's "Recent page views" on their profile page and compare the timestamps to the message receipt timestamp.

Si vous venez de mettre le message en ligne, notez que les personnes de l'audience devront se connecter et déclencher l'événement après sa mise en ligne pour le recevoir. Il ne s'enverra pas si elles ont déclenché l'événement avant la mise en ligne. Vous pouvez mettre l'événement dans les règles d'Audience au lieu des Triggers pour capturer les événements passés.

Avez-vous associé un déclencheur d'événement à une règle d'audience basée sur le même événement ? Lorsque vous combinez déclencheurs et règles, les règles de ciblage doivent avoir été satisfaites au moment du déclenchement de l'événement, car le déclencheur d'événement ne mettra pas à jour l'utilisateur instantanément dans la même requête. Par exemple, si vous voulez envoyer un message uniquement la première fois qu'un utilisateur déclenche l'événement purchased-item et pas pour les achats suivants, vous utiliseriez un compte de 0 (c.-à-d. users qui n'ont jamais déclenché l'événement auparavant) car il ne passera pas à 1 avant la requête suivante.

Avez-vous besoin d'un déclencheur d'événement, ou pourriez-vous le cibler comme une règle d'audience ? La section « Triggers » (When to send / Where to send) est optionnelle, donc vous n'avez pas besoin d'inclure un événement pour chaque message, sauf si vous devez garantir qu'il ne s'envoie que lorsqu'un user effectue une action spécifique.

L'utilisateur a-t-il d'autres messages en attente envoyés en même temps ? Plusieurs messages s'afficheront comme un badge rouge sur l'icône du Messenger, afin qu'ils ne soient pas submergés par trop de pop-ups à la fois. Vous pouvez vérifier le « Recent content » sur la page de profil de l'utilisateur pour voir quels messages il a reçus à la même période.

Le contenu de votre Chat ou Post est-il défini sur « Sent as: Badge » ? Ceux-ci s'enverront toujours en tant que notification badge, à moins que vous ne changiez en « Snippet » ou « Show the full message ».

Le Post a-t-il été modifié, et envoyé à l'origine en tant que « Snippet » ou « Badge » aux users avant le changement ?

L'utilisateur avait-il d'autres messages en attente au moment où le Post a été envoyé ? Si plusieurs messages tentent de s'envoyer en même temps, le Post s'enverra comme une notification badge rouge à la place, afin qu'ils puissent voir d'abord leurs messages prioritaires. Ils devront ouvrir la notification dans leur Messenger pour qu'elle soit comptabilisée comme une « Ouverture » dans les statistiques du message.

En général, le taux d'ouverture pour les Posts envoyés en intégralité devrait être supérieur à 90 %, et souvent supérieur à 95 %. Mais si l'utilisateur avait d'autres messages en attente, ou s'il navigue hors d'une page dans le court intervalle entre l'envoi du message et son affichage automatique, le message peut ne pas être marqué comme ouvert.

Si vous constatez un taux d'ouverture nettement inférieur à 90 %, essayez de recevoir le Post en tant qu'utilisateur final sur votre site et ouvrez la console de votre navigateur pour capturer les erreurs sur la page. Dans certaines circonstances, une erreur de page pourrait empêcher le Post de s'afficher correctement.

A-t-il un type d'audience « Fixed » ? Les messages Fixed ne peuvent pas être remis en ligne une fois arrêtés, car ils n'envoient qu'aux users qui correspondent à un moment donné, et ce moment est maintenant passé. Vous devrez dupliquer votre message et mettre une nouvelle version en ligne.

Y avait-il une date d'arrêt sur le message ? Si cette date est passée, vous devrez mettre à jour ou supprimer la date d'arrêt pour qu'il puisse renvoyer.

Si le bouton « ▶️ Set live » est grisé, vous pouvez le survoler pour voir une info-bulle expliquant pourquoi il ne peut pas être mis en ligne. Ou modifiez le message pour voir si des erreurs rouges apparaissent dans l'une des sections, avec une explication de ce qui doit être corrigé.

L'ont-ils réellement reçu avant qu'il ne soit mis en pause, mais ne l'ont-ils pas engagé (cliqué ou fermé) de sorte qu'il soit resté affiché lors de leur prochaine visite sur votre plateforme ? Vous pouvez vérifier le « Recent content » sur la page de profil de l'utilisateur pour voir l'horodatage de la réception du message, et le comparer au moment où le message a été mis en pause.

Si vous remarquez cela dans le Help Desk lorsqu'un utilisateur répond au message sortant, vérifiez l'horodatage de l'envoi du message sortant (en bas du premier message), car il pourrait répondre à un message qu'il a reçu il y a quelque temps.

Avez-vous plusieurs messages similaires en cours ? Il est possible qu'ils aient reçu un message ressemblant qui n'est pas en pause. Vous pouvez cliquer sur le message qu'ils ont reçu depuis le « Recent content » sur la page de profil de l'utilisateur pour confirmer quel message sortant c'était.

L'utilisateur s'est-il connecté depuis que le message est en ligne ? Les users devront réellement se connecter pour recevoir un message intégré. Vous pouvez vérifier la valeur « Last seen » sur la page de profil de l'utilisateur pour voir quand il a été en ligne pour la dernière fois.

S'agit-il d'un message fixe/statique ? Les users matchent pour les messages fixes au moment de leur mise en ligne, donc un utilisateur qui correspond maintenant n'a peut-être pas correspondu au moment où il a été initialement envoyé.

Y a-t-il un déclencheur d'événement ou une règle d'URL ? Les users devront déclencher l'événement ou visiter l'URL après la mise en ligne, ainsi que correspondre aux règles d'audience, pour le recevoir. Ils peuvent apparaître dans l'aperçu d'audience s'ils correspondent aux règles d'audience, mais cela ne prend pas en compte s'ils visiteront l'URL ou déclencheront l'événement requis pour le recevoir.

Quels canaux ciblez-vous sous « Show first on » dans la section contenu ? S'il est réglé sur « Show first on web » mais que l'utilisateur est uniquement actif sur mobile, il ne recevra pas le message tant qu'il ne visitera pas le web.

Le message a-t-il une date de début ou de fin, et l'utilisateur a-t-il été en ligne après la date de début et avant la date de fin ?

Le message a-t-il des heures de planification personnalisées pour n'envoyer qu'à certains moments ? Notez que les messages intégrés sont envoyés dans le fuseau horaire de l'utilisateur final, ils auront donc dû être en ligne pendant ces heures programmées dans leur fuseau horaire.

Vous pouvez également utiliser l'outil de correspondance de message pour déterminer pourquoi un utilisateur n'est pas éligible à recevoir votre message.

Chats, Posts et Banners

Surveys

Product Tours