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 un 'AND', pas un 'OR'. Et si vous utilisez un filtre exact "URL is", vous devez inclure l'URL complète, y compris la partie https:// et les barres obliques finales. Vous pouvez voir plus de conseils pour configurer efficacement vos filtres ici.

L'utilisateur l'a-t-il reçu sur la bonne page au départ, puis a-t-il navigué vers une autre page ? En raison du comportement 'follow page', si un message in-app n'est pas engagé (cliqué ou fermé), il persiste lorsque l'utilisateur navigue vers d'autres pages — y compris celles explicitement exclues de vos règles URL — jusqu'à ce qu'il interagisse avec. Essayez de vérifier les "Recent page views" de l'utilisateur sur sa page de profil et comparez les horodatages avec celui de la réception du message.

Si vous venez de mettre le message en ligne, notez que les personnes dans 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 déclencheurs pour capturer les événements passés.

Avez-vous associé un déclencheur d'événement avec une règle d'audience du même événement ? Lors de la combinaison des déclencheurs et règles, les règles de ciblage doivent être satisfaites au moment du déclenchement de l'événement, car le déclencheur d'événement ne met 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 un événement purchased-item et pas pour les achats suivants, vous utiliseriez un compte de 0 (c’est-à-dire les users qui n'ont jamais déclenché l'événement auparavant) car il ne passera à 1 qu'à la requête suivante.

Avez-vous besoin d'un déclencheur d'événement, ou pouvez-vous le cibler comme une règle d'audience ? La section "Triggers" (Quand envoyer / Où envoyer) est optionnelle, donc vous n'avez pas besoin d'inclure un événement sur chaque message, sauf si vous devez vous assurer qu'il s'envoie uniquement 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'affichent comme un badge rouge sur l'icône Messenger, pour éviter qu'ils soient submergés par trop de pop-ups simultanés. 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 réglé sur "Sent as: Badge" ? Ceux-ci s'enverront toujours comme notification badge, sauf si vous le changez en "Snippet" ou "Show the full message".

Le Post a-t-il été modifié, et initialement envoyé comme "Snippet" ou "Badge" aux users avant le changement ?

L'utilisateur avait-il d'autres messages en attente au moment de l'envoi du Post ? Si plusieurs messages tentent de s'envoyer simultanément, le Post s'enverra comme notification badge rouge à la place, pour 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.

Typiquement, le taux d'ouverture des Posts envoyés en entier devrait être supérieur à 90 %, souvent au-dessus de 95 %. Mais si l'utilisateur avait d'autres messages en attente, ou s'il navigue hors d'une page dans le court laps de temps entre l'envoi du message et son affichage automatique, le message pourrait ne pas être marqué comme ouvert.

Si vous constatez un taux d'ouverture bien 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 certains cas, une erreur de page peut 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 ne s'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 la mettre à jour ou la supprimer pour qu'il puisse s'envoyer à nouveau.

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 les sections, avec une explication de ce qui doit être corrigé.

L'ont-ils réellement reçu avant la mise en pause, mais ne l'ont pas engagé (cliqué ou fermé) donc il est 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 à la mise en pause.

Si vous remarquez cela dans le Help Desk lorsqu'un user 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 reçu il y a un certain temps.

Avez-vous plusieurs messages similaires en cours ? Il est possible qu'ils aient reçu un message similaire qui n'est pas en pause. Vous pouvez cliquer sur le message 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 la mise en ligne ? Les Users doivent se connecter pour recevoir un message in-app. Vous pouvez vérifier la valeur "Last seen" sur la page de profil de l'utilisateur pour voir sa dernière connexion.

Est-ce un message fixed/static ? Les Users correspondent pour les messages fixed au moment de la mise en ligne, donc un user qui correspond aux critères maintenant n'a peut-être pas correspondu au moment de l'envoi initial.

Y a-t-il un déclencheur d'événement ou une règle URL ? Les Users doivent 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, 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 actif uniquement sur mobile, il ne recevra pas le message tant qu'il ne visitera pas sur web.

Le message a-t-il une date de début ou de fin, et l'utilisateur s'est-il connecté après la date de début & 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 in-app s'envoient dans le fuseau horaire de l'utilisateur final, donc ils doivent avoir été en ligne pendant ces heures planifiées dans leur fuseau horaire.

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

Chats, Posts et Banners

Surveys

Product Tours