Si un user qui aurait dû recevoir un message ne l’a pas fait, plusieurs raisons peuvent expliquer cela. Ce guide de dépannage vous aidera à identifier le problème.
Note : résoudre les problèmes de livraison impliquant l’appel des méthodes Intercom JavaScript API (comme Intercom('shutdown')) nécessite un accès au code de votre app, impliquez votre équipe de développement si besoin.
Comprenez d’abord comment chaque message est livré
Nous envoyons les messages ponctuels immédiatement (sauf si vous en avez programmé un). Cela signifie que nous recherchons tous les users correspondant à vos filtres, et nous l’envoyons dès que nous les trouvons.
Pour les messages continus, nous vérifions une fois par heure qui est devenu éligible à recevoir vos messages.
Pour les séries, chaque fois qu’un client se connecte à votre app ou visite votre site web et est suivi par Intercom, il entre dans toute série où il correspond aux règles d’entrée d’un chemin.
S’ils ne se sont pas connectés, les règles d’entrée sont vérifiées une fois par heure pour toute personne devant entrer. Les blocs de règles au milieu d’un chemin (quand le client est déjà entré dans la série) sont vérifiés environ toutes les 15 minutes.
Pour les messages in-app (chats, posts, etc.), nous ne livrons que lorsque un user est en ligne pour les recevoir. Nous ne faisons correspondre et n’envoyons les messages in-app que lorsque les users « pinguent », c’est-à-dire quand ils sont en ligne et que votre app nous envoie des mises à jour à leur sujet. La valeur « Dernière connexion » vous indique quand le user était disponible pour recevoir un message. Si votre app mobile utilise le Messenger web (plutôt que le SDK natif iOS ou Android), elle ne génère que des pings web — pas iOS ou Android. Cela signifie que définir « Afficher d’abord sur » uniquement sur iOS ne correspondra jamais, et les messages in-app n’apparaîtront pas. Incluez Web dans le paramètre « Afficher d’abord sur » pour que les messages correspondent au Messenger web intégré dans votre app mobile.
Les messages avec une notification push associée sont envoyés immédiatement.
La session Messenger du user est-elle toujours active ?
Pour les messages in-app, la livraison est contrôlée par la session Messenger, pas par le statut de connexion du user dans l’app hôte. Lorsqu’un user est identifié via Intercom('boot') avec un JWT valide, un cookie de session est créé avec une durée par défaut de 7 jours. Cette session persiste même après la déconnexion du user de votre app — jusqu’à ce que vous appeliez explicitement Intercom('shutdown').
Cela signifie qu’un user déconnecté de votre app peut encore recevoir des messages in-app la prochaine fois que le Messenger se charge, si son cookie de session n’a pas expiré.
Important : Les conditions d’audience sont vérifiées à chaque chargement du Messenger, pas à la déconnexion. Les filtres d’exclusion fonctionnent donc, mais seulement si le Messenger démarre effectivement pendant que la session est active.
Pour empêcher la livraison aux users déconnectés ou exclus :
Appelez
Intercom('shutdown')dans votre gestionnaire d’événement de déconnexion. Cela efface immédiatement le cookie de session et démarre une nouvelle session anonyme pour le prochain visiteur sur cet appareil.Incluez tout statut d’exclusion dans le filtre d’audience du message (par exemple
excluded_user is not true). Les conditions sont réévaluées à chaque chargement du Messenger, ce qui empêche la livraison même si une session est encore techniquement active.Optionnellement, réduisez la durée maximale de session dans Paramètres > Canaux > Messenger > Gardez votre Messenger sécurisé pour correspondre à la durée de session de votre app.
Note : Ce comportement s’applique uniquement aux users identifiés. Les visiteurs anonymes utilisent une session distincte basée sur les cookies, non affectée par la persistance de session basée sur JWT.
La sécurité Messenger bloque-t-elle la livraison aux users connectés ?
Lorsque la sécurité Messenger est activée sur votre espace de travail, les messages de chat aux users connectés ne sont livrés que si un jeton de sécurité valide est fourni lors de l’appel de démarrage du Messenger. Si le jeton est manquant ou invalide, le Messenger ne termine pas un démarrage sécurisé sur cette page — aucun ping n’est envoyé, les pages récentes du user restent vides, et les messages de chat in-app ne peuvent pas être livrés, même si le user est actif sur la page.
Comment vérifier : Dans Paramètres > Canaux > Messenger > Sécurité, vérifiez quels domaines de production passent la vérification de sécurité. Un domaine affiché comme « non prêt » signifie que les pings de ce domaine ne portent pas de jeton valide, et le Messenger connecté sur ce domaine ne termine pas un démarrage sécurisé. Confirmez avec vos développeurs qu’un JWT récent (ou un hash de vérification d’identité, si vous utilisez l’ancienne méthode) est généré côté serveur et passé à l’appel de démarrage du Messenger pour ce domaine exact. Voir Authentification des users dans le Messenger avec JSON web tokens (JWTs) pour les étapes de configuration.
Cette vérification de sécurité s’applique uniquement à l’installation connectée, où le Messenger démarre avec une identité connue (user_id/email). Les Leads atteints via une installation anonyme sur le site marketing ne sont pas soumis à cette vérification et peuvent recevoir des messages de chat in-app tant que le Messenger est chargé sur leur page — la même règle de livraison basée sur la session décrite ci-dessus, sans jeton requis.
Ensuite, répondez à ces questions
Si vous n’avez toujours pas compris pourquoi votre message ne s’envoie pas, vous devrez répondre aux questions suivantes :
Envoyez-vous le message à un large public ?
Les messages destinés à un large public peuvent prendre un certain temps à être traités. Lorsque vous publiez un message, nous vérifions tous les filtres du message et voyons quels users correspondent. Plus le message est important, plus ce traitement peut prendre du temps.
Les users correspondent-ils aux filtres que vous avez définis ?
Dans Intercom, tous les messages sont déclenchés. En d’autres termes, les destinataires doivent correspondre aux filtres que vous avez définis sur un message avant d’être éligibles à le recevoir. Des exemples de filtres seraient « Inscrit il y a moins de 30 jours » et « Plan est lite »
Lorsque vous ajoutez des filtres à un message, ceux-ci deviennent les critères qu’Intercom utilise pour vérifier l’éligibilité des users au message. Par exemple, si vous avez un message configuré avec les filtres ci-dessus, cela ressemblerait à ceci :
Actuellement, aucun user ne correspond à ces filtres, donc personne ne recevra le message. Cependant, comme c’est un message continu, Intercom vérifiera chaque heure qui correspond à ces filtres et enverra le message aux users qui le font.
Si des users correspondent aux filtres de ce message, ils apparaîtront à droite de la fenêtre. Voici à quoi ressemble le message quand des personnes correspondent aux filtres :
Ce user s’est-il désabonné ?
Si un user s’est désabonné des messages email de votre app, il ne recevra plus d’emails groupés de votre part. Il peut toujours recevoir des messages in-app et des emails envoyés uniquement à lui, mais il ne recevra aucun message email manuel ou automatique.
Le message a-t-il rebondi ?
Si Intercom tente d’envoyer un message à un destinataire et qu’il y a une erreur permanente, aussi appelée rebond dur, nous ne tenterons plus d’envoyer d’emails à ce destinataire. C’est dangereux de continuer à tenter la livraison à des adresses en rebond dur, cela peut nuire à votre réputation d’expéditeur et à la capacité d’acheminer les messages vers la boîte de réception.
Ce user a-t-il marqué le message comme spam ?
De même, si un destinataire marque un de vos emails comme spam, vous ne pourrez plus lui envoyer d’emails depuis votre app Intercom.
Les users désabonnés, en rebond ou ayant marqué vos messages comme spam seront automatiquement retirés de l’audience des messages groupés. Si vous essayez d’envoyer un message à quelqu’un qui a déjà rebondi ou s’est plaint, Intercom ne tentera pas la livraison.
Certaines adresses ne sont pas destinées à recevoir des emails marketing et sont automatiquement jugées inéligibles. Par exemple, les adresses abuse@ et postmaster@.
Si vous essayez d’envoyer un message et que tous les destinataires sont inéligibles, vous pourriez voir un message disant : « nous préparons cet email et il commencera à être envoyé sous peu. »
Note : Si l’attribut « marqué comme spam » d’un user ou lead est « true » mais que vous avez obtenu leur consentement écrit ou verbal pour recevoir à nouveau vos emails, contactez notre équipe support qui peut vous aider à mettre à jour le user. Il est important d’obtenir d’abord le consentement du user/lead, car envoyer des emails à des personnes qui continuent de marquer vos emails comme spam peut nuire à votre réputation d’expéditeur et augmenter la probabilité que vos emails soient dirigés vers les filtres anti-spam des clients.
Avez-vous programmé l’envoi de votre message dans une fenêtre de livraison ?
Si vous avez programmé vos messages pour qu’ils soient envoyés à un certain moment ou dans une fenêtre de livraison, cela peut retarder la livraison. Par exemple, vous pouvez vouloir publier un message à 9h dans un autre fuseau horaire pendant que vous dormez — vous pouvez programmer un message pour cela.
Vous pouvez aussi configurer des fenêtres de livraison, qui peuvent affecter les heures de livraison des messages. Si vous avez un message avec une fenêtre de livraison de 9h à 17h, il sera livré quand il tombe dans cette plage horaire dans le fuseau horaire du destinataire. Si nous ne connaissons pas le fuseau horaire du destinataire, nous utiliserons celui de l’app.
Note : Les messages avec fenêtres de livraison sont envoyés selon le fuseau horaire du destinataire, pas celui de l’expéditeur, sauf s’il n’y a pas de données de localisation pour le destinataire, auquel cas nous utilisons le fuseau horaire de l’app.