Überprüfung der Erreichbarkeit + Kanal-Fallback

Die geprüften Daten bleiben auf Infrastruktur, die Sie kennen

Die Abo-Tags, die eine Überprüfung der Erreichbarkeit liest, laufen über dieselbe Infrastruktur wie die gesamte Plattform: Pushwoosh ist SOC 2 Type I und ISO 27001:2022 zertifiziert, DSGVO-konform und betreibt eigene Hardware in den USA und in Deutschland, unter dem deutschen Bundesdatenschutzgesetz (BDSG). Vollständige Details finden Sie auf der Seite Datensicherheit.

Die Nachricht kommt trotzdem an

Jemand deaktiviert Push oder meldet sich von einer E-Mail-Liste ab, und die Nachricht, die Sie für ihn gebaut haben, kommt einfach nicht an. Im Versandbericht fällt das nicht auf: Die Kampagne lief, der Zähler stieg, und eine Person hat sie nie gesehen. Ein Betrugsalarm, der nur Push versucht, hat seine Aufgabe nicht erfüllt, wenn Push deaktiviert ist. Ein Update zum Lieferstatus, das nur Push versucht, erreicht einen Kunden mit stummgeschalteten Benachrichtigungen nicht. Überprüfung der Erreichbarkeit fängt das ab, bevor die Nachricht verschickt wird, und leitet den Nutzer auf einen anderen Kanal um, statt dass Sie die Fallback-Logik von Hand bauen.

Was Ihnen die Überprüfung der Erreichbarkeit gibt

Was als erreichbar zählt

Für 2 der 5 Kanäle gibt es eine veröffentlichte Definition von „nicht erreichbar”. Die restliche Tag-Logik ist noch nicht öffentlich dokumentiert.

Das ist ein Abo-Tag, kein Zustellversuch in Echtzeit. Ein als erreichbar markierter Nutzer kann die Nachricht weiter unten in der Kette trotzdem verpassen, wenn sein Gerät offline ist oder die App bis dahin gelöscht wurde. Was dieses Element bietet, das ein allgemeiner Condition-Knoten nicht bietet, ist der Zweig selbst: eine zweckgebaute Erreichbar/Nicht-erreichbar-Verzweigung, die Sie auf die Canvas ziehen und verketten, statt eine generische Bedingung oder einen Warteschritt von Hand an Abo-Daten anzuschließen.

Prüfungen zu einer Kaskade verketten

Leiten Sie den nicht-erreichbar-Zweig einer Push-Prüfung in eine E-Mail-Prüfung, und deren nicht-erreichbar-Zweig in eine SMS- oder WhatsApp-Prüfung. Jeder Schritt grenzt die Zielgruppe auf die Personen ein, die der vorherige Kanal nicht erreicht hat, bis die Nachricht ankommt oder die Kanäle ausgehen.

Kaskade mit In-App abschließen

In-App gehört nicht zu den 5 Kanälen, die dieses Element prüft, ist aber die übliche letzte Station. Eine In-App-Nachricht erreicht jeden, der die App öffnet, unabhängig vom Abo-Status auf jedem anderen Kanal.

Was eine Journey wirklich omnichannel macht

Omnichannel bedeutet mehr, als 5 Kanäle in den Einstellungen aufzulisten. Es bedeutet, dass die Journey pro Person erkennt, wann ein Kanal geschlossen ist, und reagiert, bevor der Versand still scheitert. Genau das liefert die Überprüfung der Erreichbarkeit dem Customer Journey Builder: einen Weg, um einen geschlossenen Kanal zu umgehen, statt nur die vorhandenen Kanäle aufzulisten.

Wo sich das Element bewährt

Eine Prüfung unter den Kanälen, die sie absichert

Gebaut für die Kanäle, zwischen denen sie ausweicht

Eine Kaskade ist nur so gut wie die Kanäle dahinter: Mobile Push als erster Versuch, E-Mail als Fallback, SMS oder WhatsApp zum Abschluss.

Condition Split sieht ähnlich aus: ein Knoten, mehrere Zweige, einmal ausgewertet. Der Unterschied liegt darin, was gelesen wird: ein Segment, Tag oder Event-Wert, der bereits auf dem Profil liegt, gegenüber der Frage, ob ein Kanal offen ist. Beide liegen im Customer Journey Builder, auf derselben Canvas wie jedes andere Flow-Control-Element.

So funktioniert’s

Gut zu wissen

FAQ

Erreichen Sie jeden über den Kanal, der gerade offen ist

Verketten Sie eine Überprüfung der Erreichbarkeit für jeden Kanal, den eine Nachricht nutzen könnte, und behandeln Sie einen geschlossenen Kanal nicht länger als Sackgasse.

Weitere Produkte entdecken