Wenn eine ausgehende Nachricht gesendet wird, muss ein Kunde für die Nachricht zugeordnet werden, aber ein Gespräch muss auch in unserem Codebase erstellt werden, bevor die Nachricht etwas ist, das Ihre customers tatsächlich sehen können.
In diesem Kontext bedeutet create conversation, dass aus Sicht des Kunden die Nachricht/das Gespräch bereit ist, empfangen zu werden/ihnen gesendet wurde (Chats oder Post: Nachricht wurde in Echtzeit gesendet oder die Nachricht ist bereit für sie, wenn sie das nächste Mal online sind; Email/Push: Nachricht wurde an den Kunden gesendet).
Wenn wir das Gespräch erstellen, wird das Attribut last contacted at für den Kunden aktualisiert.
Aufschlüsselung von Matching + Versand basierend auf dem Kanal
Nachrichtenkanal | Dynamische Nachricht? | Feste Nachricht? |
In-App (Massenversand) | Matching + create conversation, wenn der user/lead/visitor einen ping sendet | Matching, wenn die Nachricht erstmals live geschaltet wird -> Erstellen einer ausstehenden Zustellung, während wir darauf warten, dass der user online kommt -> create conversation, wenn der user einen ping sendet |
Chat (1:1) | N/A - kann keine 1:1 dynamische Nachricht senden. | Matching, wenn die Nachricht erstmals live geschaltet wird + create conversation sofort. |
In-App mit Push-Benachrichtigung | Matching, Push-Benachrichtigung senden und create conversation sofort, wenn die Nachricht erstmals live geschaltet wird oder während der stündlichen Prüfungen. Chat oder Post mit Push, die durch Ping ausgelöst werden, sehen users, die gleichzeitig die Push-Benachrichtigung und In-App erhalten (unabhängig davon, ob es sich um eine Massen- oder 1:1-Nachricht handelt). Hinweis: Für Series führen wir alle 15 Minuten Prüfungen durch. | Matching, wenn die Nachricht erstmals live geschaltet wird, sofort eine Push-Benachrichtigung senden und create conversation sofort. |
Email / Push (ohne Zeitfenster für Planung) | Matching und create conversation, wenn die Nachricht erstmals live geschaltet wird, wenn ein neuer user/lead erstellt wird und in den ersten zwei Stunden einen Ping sendet, oder während der stündlichen Fan-Outs, die wir durchführen. Hinweis: Für Series führen wir alle 15 Minuten Prüfungen durch. | Matching, wenn die Nachricht erstmals live geschaltet wird, und create conversation sofort. |
Email / Push (außerhalb des Zeitfensters für Planung) | Matching nur während des Zeitfensters für Planung, wenn die Nachricht erstmals live geschaltet wird, wenn ein neuer user/lead erstellt wird und in den ersten zwei Stunden einen Ping sendet, oder während der stündlichen Fan-Outs. Mit dem neuen Nachrichtenzuordnungssystem ordnen wir users nicht mehr zu und erstellen keine 'ausstehenden' Datensätze, die im nächsten Zeitfenster gesendet werden. Hinweis: Für Series führen wir alle 15 Minuten Prüfungen durch. | N/A - man kann bei manuellen Nachrichten keine Zeitfenster für Planung haben. |
Nachricht mit Startdatum | Wenn eine Nachricht ein Startdatum hat, wird sie zum Startdatum zugeordnet, nicht wenn sie live geschaltet wird. | Wenn eine Nachricht ein Startdatum hat, wird sie zum Startdatum zugeordnet, nicht wenn sie live geschaltet wird. |
Was passiert, wenn ein Kunde gleichzeitig mehrere In-App-Inhaltstypen zugeordnet bekommt?
Da wir die Anzahl der verfügbaren In-App-Inhaltstypen erweitern, müssen wir mehr darüber nachdenken, wie diese verschiedenen Inhaltstypen miteinander interagieren und welche Priorität sie gegenüber anderen haben.
Früher hatten wir nur konversationelle In-App-Nachrichten (z. B. Chats, Posts, Bot-Nachrichten). Es gab einfache Regeln dafür, was passiert, wenn man mehr als einen dieser Typen gleichzeitig zuordnet, und ein Inhaltstyp musste nie wissen, dass ein anderer Inhaltstyp zugeordnet wurde. Der Messenger selbst war verantwortlich dafür, wie mehrere Benachrichtigungen angezeigt werden, siehe Chats, Posts, Workflows.
Mit der Einführung von Tours (auch Karussells auf Mobilgeräten), Bannern und jetzt Umfragen entwickeln wir Regeln dafür, welche Inhaltstypen ein Kunde gleichzeitig zugeordnet bekommen kann und welche Inhaltstypen ein Kunde zugeordnet bekommen kann, wenn er bereits „aktive“ Inhalte hat.
Es gibt 2 Möglichkeiten, wie wir verschiedene Inhaltstypen priorisieren können:
Beim Matching, wo man einfach einen bestimmten Inhaltstyp nicht zuordnen kann, wenn man auch einen der anderen zuordnet (oder bereits einen „aktiven“ Inhaltstyp hat); oder
Anzeigelogik im Messenger, wenn man mehrere Inhaltstypen zuordnet.
Wenn es auch Zuordnungen für ein...
| Banner | Karussell | Chat | Workflow | Post | Umfrage | Tour |
Banner | 1️⃣ | n/a | ✅ | ✅ | ✅ | ❌ | ✅ |
Karussell | k.A. | 1️⃣ | ✅ | ✅ | ✅ | ✅ | k.A. |
Chat | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Workflow | ✅ | ✅ | ✅ | 1️⃣ | ✅ | ✅ | ✅ |
Beitrag | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Umfrage | ✅ | ❌ | ✅ | ✅ | ✅ | 1️⃣ | ❌ |
Tour | ✅ | k.A. | ✅ | ✅ | ✅ | ✅ | 1️⃣ |
k.A. — Gilt nicht, da diese Inhaltstypen nur entweder im Web oder mobil verfügbar sind.
1️⃣ — Der Kunde kann jeweils nur einen dieser Inhaltstypen auswählen.
❌ — Der Kunde kann einen dieser Inhaltstypen nicht zuordnen, da es Übereinstimmungen für einen anderen Inhaltstyp gibt.
✅ — Der Kunde kann diesen Inhaltstyp unabhängig von den anderen Übereinstimmungen zuordnen.
Wenn eine Nachricht ein Startdatum hat, wird der user dann beim Live-Schalten oder beim Beginn des Startdatums zugeordnet?
Das ist der Zeitpunkt, an dem das Startdatum beginnt.