Wenn ein user, der eine Nachricht erhalten sollte, diese nicht bekommen hat, kann es mehrere Gründe geben. Diese Fehlerbehebung hilft Ihnen, das Problem zu finden.
Hinweis: Die Behebung von Zustellproblemen, die das Aufrufen von Intercom JavaScript API-Methoden (wie Intercom('shutdown')) beinhalten, erfordert Zugriff auf den Code Ihrer App. Beziehen Sie bei Bedarf Ihr Entwicklungsteam ein.
Verstehen Sie zunächst, wie jede Nachricht zugestellt wird
Wir senden einmalige Nachrichten sofort (es sei denn, Sie haben eine geplant). Das bedeutet, dass wir alle users suchen, die Ihren Filtern entsprechen, und die Nachricht sofort senden, sobald wir sie finden.
Für laufende Nachrichten prüfen wir einmal pro Stunde, wer berechtigt ist, Ihre Nachrichten zu erhalten.
Für Serien gilt: Wann immer ein Kunde sich in Ihrer App anmeldet oder Ihre Website besucht und von Intercom verfolgt wird, tritt er in jede Serie ein, bei der er die Eintrittsregeln für einen Pfad erfüllt.
Wenn sie sich nicht angemeldet haben, werden die Eintrittsregeln einmal pro Stunde für alle überprüft, die eintreten sollten. Regelblöcke in der Mitte eines Pfads (wenn der Kunde die Serie bereits betreten hat) werden etwa alle 15 Minuten überprüft.
Für In-App-Nachrichten (Chats, Beiträge usw.) liefern wir nur aus, wenn ein user online ist, um sie zu empfangen. Wir senden In-App-Nachrichten nur, wenn users „pingen“, also online sind und Ihre App uns Updates über sie sendet. Der Wert „Zuletzt gesehen“ zeigt an, wann der user zuletzt auf Ihrer Seite verfügbar war, um eine Nachricht zu erhalten. Wenn Ihre mobile App den webbasierten Messenger verwendet (anstatt des nativen iOS- oder Android-SDK), erzeugt sie nur Web-Pings – keine iOS- oder Android-Pings. Das bedeutet, dass die Einstellung „Zeige zuerst auf“ nur iOS niemals passt und In-App-Nachrichten nicht erscheinen. Fügen Sie Web in der Einstellung „Zeige zuerst auf“ hinzu, damit Nachrichten mit dem webbasierten Messenger in Ihrer mobilen App übereinstimmen können.
Nachrichten mit einer Push-Benachrichtigung werden sofort gesendet.
Ist die Messenger-Sitzung des users noch aktiv?
Bei In-App-Nachrichten wird die Zustellung durch die Messenger-Sitzung gesteuert, nicht durch den Anmeldestatus des users in der Host-App. Wenn ein user über Intercom('boot') mit einem gültigen JWT identifiziert wird, wird ein Sitzungscookie mit einer Standarddauer von 7 Tagen erstellt. Diese Sitzung bleibt bestehen, auch wenn sich der user aus Ihrer App abmeldet – bis Sie explizit Intercom('shutdown') aufrufen.
Das bedeutet, dass ein user, der sich aus Ihrer App abgemeldet hat, beim nächsten Laden des Messengers weiterhin In-App-Nachrichten erhalten kann, wenn sein Sitzungscookie noch nicht abgelaufen ist.
Wichtig: Zielgruppenbedingungen werden jedes Mal überprüft, wenn der Messenger geladen wird, nicht beim Logout. Ausschlussfilter funktionieren also, aber nur, wenn der Messenger tatsächlich startet, während die Sitzung aktiv ist.
Um die Zustellung an users zu verhindern, die sich abgemeldet oder ausgeschlossen haben:
Rufen Sie
Intercom('shutdown')in Ihrem Logout-Event-Handler auf. Dies löscht das Sitzungscookie sofort und startet eine neue anonyme Sitzung für den nächsten Besucher auf diesem Gerät.Fügen Sie jeden Ausschlussstatus im Zielgruppenfilter der Nachricht ein (z. B.
excluded_user is not true). Bedingungen werden bei jedem Laden des Messengers neu bewertet, sodass die Zustellung verhindert wird, auch wenn eine Sitzung technisch noch aktiv ist.Optional können Sie die maximale Sitzungsdauer unter Einstellungen > Channels > Messenger > Halten Sie Ihren Messenger sicher reduzieren, um die Sitzungsdauer Ihrer App anzupassen.
Hinweis: Dieses Verhalten gilt nur für identifizierte users. Anonyme Besucher verwenden eine separate, cookie-basierte Sitzung, die von der JWT-basierten Sitzungsdauer nicht betroffen ist.
Blockiert die Messenger-Sicherheit die Zustellung an angemeldete users?
Wenn die Messenger-Sicherheit in Ihrem Workspace aktiviert ist, werden Chat-Nachrichten an angemeldete users nur zugestellt, wenn beim Messenger-Start ein gültiges Sicherheitstoken übergeben wird. Fehlt das Token oder ist es ungültig, wird der Messenger auf dieser Seite nicht sicher gestartet – es wird kein Ping gesendet, die letzten Seitenaufrufe des users bleiben leer, und In-App-Chat-Nachrichten können nicht zugestellt werden, selbst wenn der user aktiv auf der Seite ist.
So prüfen Sie: Überprüfen Sie unter Einstellungen > Channels > Messenger > Sicherheit, welche Ihrer Produktionsdomains die Sicherheitsprüfung bestehen. Eine Domain, die als „nicht bereit“ angezeigt wird, sendet keine gültigen Tokens mit den Pings, und der angemeldete Messenger auf dieser Domain startet nicht sicher. Bestätigen Sie mit Ihren Entwicklern, dass ein frisches JWT (oder Identity Verification Hash, falls Sie die ältere Methode verwenden) serverseitig generiert und beim Messenger-Start für diese Domain übergeben wird. Siehe Authentifizierung von users im Messenger mit JSON Web Tokens (JWTs) für Einrichtungsschritte.
Diese Sicherheitsprüfung gilt nur für die angemeldete Installation, bei der der Messenger mit bekannter Identität (user_id/E-Mail) startet. Leads, die über eine anonyme Marketing-Site-Installation erreicht werden, unterliegen dieser Prüfung nicht und können In-App-Chat-Nachrichten erhalten, solange der Messenger auf ihrer Seite geladen ist – dieselbe sitzungsbasierte Zustellregel wie oben beschrieben, ohne erforderliches Token.
Beantworten Sie als Nächstes diese Fragen
Wenn Sie immer noch nicht herausgefunden haben, warum Ihre Nachricht nicht gesendet wird, müssen Sie die folgenden Fragen beantworten:
Senden Sie die Nachricht an ein großes Publikum?
Nachrichten an ein großes Publikum können etwas Zeit zur Verarbeitung benötigen. Wenn Sie eine Nachricht live schalten, prüfen wir alle Nachrichtenfilter und sehen, welche Ihrer users diese erfüllen. Je größer die Nachricht, desto länger kann die Verarbeitung dauern.
Entsprechen users den von Ihnen festgelegten Filtern?
In Intercom ist alle Nachrichtenübermittlung triggerbasiert. Mit anderen Worten, Empfänger müssen die Filter erfüllen, die Sie für eine Nachricht festgelegt haben, bevor sie berechtigt sind, diese zu erhalten. Beispiele für Filter sind „Vor weniger als 30 Tagen angemeldet“ und „Plan ist lite“.
Wenn Sie Filter zu einer Nachricht hinzufügen, werden diese zu den Kriterien, die Intercom verwendet, um die Berechtigung eines users für die Nachricht zu prüfen. Zum Beispiel würde eine Nachricht mit den oben genannten Filtern so aussehen:
Derzeit entspricht kein user diesen Filtern, daher erhält niemand die Nachricht. Da es sich jedoch um eine laufende Nachricht handelt, prüft Intercom jede Stunde, wer diese Filter erfüllt, und sendet die Nachricht an alle users, die dies tun.
Wenn users die Filter dieser Nachricht erfüllen, werden sie auf der rechten Seite des Fensters angezeigt. So sieht die Nachricht aus, wenn Personen die Filter erfüllen:
Hat sich dieser user abgemeldet?
Wenn sich ein user von E-Mail-Nachrichten Ihrer App abgemeldet hat, erhält er keine Massen-E-Mails mehr von Ihnen. Er kann jedoch weiterhin In-App-Nachrichten und E-Mails erhalten, die nur an ihn gesendet werden, aber keine manuellen oder automatischen E-Mail-Nachrichten.
Ist die Nachricht zurückgekommen?
Wenn Intercom versucht, eine Nachricht an einen Empfänger zu senden und ein permanenter Fehler auftritt, auch bekannt als Hard Bounce, versuchen wir nicht erneut, E-Mails an diesen Empfänger zu senden. Dies ist wichtig, da wiederholte Zustellversuche an Hard-Bounce-Adressen Ihre Versandreputation und die Zustellbarkeit in den Posteingang schädigen können.
Hat dieser user die Nachricht als Spam markiert?
Ebenso können Sie einem Empfänger keine weiteren E-Mails aus Ihrer Intercom-App senden, wenn er eine Ihrer E-Mails als Spam markiert hat.
Users, die abgemeldet, zurückgekommen oder die Ihre Nachrichten als Spam markiert haben, werden automatisch aus der Zielgruppe von Massen-Nachrichten entfernt. Wenn Sie versuchen, eine Nachricht an jemanden zu senden, der zuvor zurückgekommen ist oder sich beschwert hat, wird Intercom die Zustellung nicht versuchen.
Bestimmte Adressen sind nicht für Marketing-E-Mails vorgesehen und gelten automatisch als nicht berechtigt, E-Mails zu erhalten. Beispiele sind abuse@- und postmaster@-Adressen.
Wenn Sie versuchen, eine Nachricht zu senden und alle Empfänger nicht berechtigt sind, sie zu erhalten, sehen Sie möglicherweise die Meldung: „Wir bereiten diese E-Mail vor und sie wird in Kürze gesendet.“
Hinweis: Wenn das Attribut „Als Spam markiert“ eines users oder Leads auf „true“ steht, Sie aber eine schriftliche oder mündliche Zustimmung von ihm haben, wieder E-Mails von Ihnen zu erhalten, wenden Sie sich an unser Support-Team, das Ihnen bei der Aktualisierung des users helfen kann. Es ist wichtig, dass Sie zuerst die Zustimmung des users/Leads einholen, da das Versenden von E-Mails an Personen, die Ihre E-Mails weiterhin als Spam markieren, Ihre Versandreputation schädigen und die Wahrscheinlichkeit erhöhen kann, dass Ihre E-Mails im Spam-Filter der Kunden landen.
Haben Sie Ihre Nachricht so geplant, dass sie innerhalb eines Zustellfensters gesendet wird?
Wenn Sie Ihre Nachrichten so geplant haben, dass sie zu einer bestimmten Zeit oder innerhalb eines Zustellfensters gesendet werden, kann dies die Zustellung verzögern. Zum Beispiel möchten Sie vielleicht eine Nachricht um 9 Uhr in einer anderen Zeitzone senden, während Sie schlafen – dafür können Sie eine Nachricht planen.
Sie können auch Zustellfenster einrichten, die die Zustellzeiten von Nachrichten beeinflussen können. Wenn Sie ein Zustellfenster von 9 bis 17 Uhr haben, wird die Nachricht innerhalb dieses Zeitfensters in der Zeitzone des Empfängers zugestellt. Wenn wir die Zeitzone des Empfängers nicht kennen, verwenden wir die Zeitzone der App.
Hinweis: Nachrichten mit Zustellfenstern werden nach der Zeitzone des Empfängers gesendet, nicht nach der des Absenders, es sei denn, es sind keine Standortdaten für den Empfänger verfügbar. In diesem Fall verwenden wir die Zeitzone der App.