Fehlerbehebung bei der Live-Journey-Ausführung troubleshooting-execution
In diesem Abschnitt erfahren Sie, wie Sie Fehler bei Journey-Ereignissen beheben und wie Sie prüfen, ob Profile in Ihre Journey eingetreten sind, wie sie diese durchlaufen und ob Nachrichten gesendet werden.
Sie können auch Fehler beheben, bevor Sie eine Journey testen oder veröffentlichen. Auf dieser Seite erfahren Sie mehr dazu.
Auf dieser Seite erfahren Sie, wie Sie Fehler bei eingehenden Aktionen beheben.
Überprüfen, ob Ereignisse ordnungsgemäß gesendet werden checking-that-events-are-properly-sent
Der Ausgangspunkt einer Journey ist stets ein Ereignis. Sie können mithilfe von Tools wie Postman Tests durchführen.
Sie können prüfen, ob der API-Aufruf, den Sie über diese Tools versenden, richtig gesendet wurde oder nicht. Wenn Sie einen Fehler erhalten, bedeutet das, dass es bei Ihrem Aufruf zu einem Fehler kommt. Überprüfen Sie erneut die Payload, die Kopfzeile (insbesondere die Organisations-ID) sowie die Ziel-URL. Sie können Ihren Administrator nach der richtigen URL fragen.
Ereignisse werden von der Quelle nicht direkt an Journeys weitergeleitet. Journeys benötigen dazu stattdessen die Streaming-Aufnahme-APIs von Adobe Experience Platform. Darum können Sie bei Problemen mit Ereignissen die Fehlerbehebung für Streaming-Aufnahme-APIs in der Dokumentation zu Adobe Experience Platform nutzen.
Wenn Ihre Journey den Testmodus nicht aktivieren kann und dabei der Fehler ERR_MODEL_RULES_16 ausgegeben wird, stellen Sie im Falle von Kanalaktionen sicher, dass das verwendete Ereignis einen Identity-Namespace enthält.
Der Identity-Namespace dient dazu, die Testprofile eindeutig zu identifizieren. Wenn beispielsweise die E-Mail-Adresse zur Identifizierung der Testprofile verwendet wird, sollte der Identity-Namespace E-Mail ausgewählt werden. Wenn die eindeutige Kennung die Telefonnummer ist, sollte der Identity-Namespace Telefon ausgewählt werden.
Überprüfen, ob Personen in die Journey eintreten checking-if-people-enter-the-journey
Berichte zu Journey messen den Eintritt von Personen in eine Journey auf Echtzeitbasis.
Wenn Sie das Ereignis erfolgreich versenden, aber keinen Eintritt in die Journey sehen können, bedeutet das, dass es zwischen dem Senden und Empfangen des Ereignisses in der Journey zu Problemen kommt.
Sie können die Fehlerbehebung mit den folgenden Fragen beginnen:
-
Sind Sie sicher, dass sich die Journey, bei der Sie das eingehende Ereignis erwarten, im Testmodus befindet oder live ist?
-
Haben Sie das Ereignis gespeichert, bevor Sie die Payload aus der Payload-Vorschau kopiert haben?
-
Enthält die Payload des Ereignisses eine Ereignis-ID?
-
Haben Sie die richtige URL aufgerufen?
-
Haben Sie die Payload-Struktur der Streaming-Aufnahme-APIs mithilfe der Payload-Strukturvorschau im Ereigniskonfigurationsbereich beachtet? Weitere Informationen finden Sie auf dieser Seite.
-
Haben Sie im Header Ihres Ereignisses die richtigen Schlüssel-Wert-Paare verwendet?
code language-none X-gw-ims-org-id - your organization's ID Content-type - application/json
Überprüfen, wie Personen durch die Journey navigieren checking-how-people-navigate-through-the-journey
Berichte zu Journey messen den Fortschritt von Kontakten innerhalb einer Journey. So können Sie leicht ermitteln, wo und warum eine Person gestoppt wurde.
Prüfen Sie folgende Punkte:
- Ist das Problem auf eine Bedingung zurückzuführen, mit der die Person ausgeschlossen wird? Beispiel: Die Bedingung lautet „Geschlecht = männlich“, während die Person eine Frau ist. Die Prüfung kann von einem Business-Anwender vorgenommen werden, solange die Bedingung nicht zu komplex ist.
- Ist das Problem auf einen Aufruf einer Datenquelle zurückzuführen, die nicht reagiert? Wenn sich die Journey im Test befindet, können diese Informationen in Testmodusprotokollen angezeigt werden. Wenn die Journey live ist, kann ein Administrator direkte Aufrufe an die Datenquelle testen und die erhaltene Antwort überprüfen. Alternativ kann ein Administrator die Journey duplizieren und dann testen.
Überprüfen, ob Nachrichten erfolgreich gesendet werden checking-that-messages-are-sent-successfully
Wenn Personen die Journey zwar richtig durchlaufen, aber nicht die vorgesehenen Nachrichten erhalten, können Sie Folgendes prüfen:
- Journey Optimizer hat die Anfrage zum Senden der Nachricht korrekt berücksichtigt. Ein Business-Anwender kann auf die zu sendende Nachricht zugreifen und prüfen, ob der Zeitpunkt der letzten Ausführung mit der Ausführungszeit Ihrer Journey übereinstimmt. Außerdem kann er die neuesten eingegangenen API-Aufrufe/-Ereignisse prüfen.
- Journey Optimizer hat die Nachricht erfolgreich gesendet. Überprüfen Sie die Journey-Berichte, um sicherzustellen, dass keine Fehler aufgetreten sind.
Bei einer Nachricht, die über eine benutzerdefinierte Aktion gesendet wird, kann während des Journey-Tests nur geprüft werden, ob der Systemaufruf der benutzerdefinierten Aktion zu einem Fehler führt oder nicht. Wenn der Aufruf an das externe System, das mit der benutzerdefinierten Aktion verknüpft ist, nicht zu einem Fehler führt, aber auch nicht zum Senden der Nachricht, sollten Sie das externe System überprüfen.
Informationen zu doppelten Einträgen in Journey-Schrittereignissen duplicate-step-events
Warum sehe ich mehrere Einträge mit derselben Journey-Instanz, demselben Profil, demselben Knoten und denselben Anfrage-IDs?
Beim Abfragen von Daten zu Journey-Schrittereignissen werden Ihnen gelegentlich anscheinend doppelte Protokolleinträge für dieselbe Journey-Ausführung auffallen. Diese Einträge haben identische Werte bei:
profileID– der ProfilidentitätinstanceID– der Journey-InstanzkennungnodeID– dem spezifischen Journey-KnotenrequestID– der Anfragekennung
Diese Einträge weisen jedoch unterschiedliche _id-Werte auf, was der Schlüsselindikator ist, der dieses Szenario von tatsächlicher Datenduplizierung unterscheidet.
Was verursacht dieses Verhalten?
Die Ursache sind automatische Backend-Skalierungsvorgänge (auch als „Rebalancing“ bezeichnet) in der Microservices-Architektur von Adobe Journey Optimizer. In Zeiten von hoher Auslastung oder Systemoptimierung gilt Folgendes:
- Ein Journey-Schrittereignis beginnt mit der Verarbeitung und wird im Datensatz für Journey-Schrittereignisse protokolliert
- Durch einen automatischen Skalierungsvorgang wird die Workload auf verschiedene Dienstinstanzen verteilt
- Dasselbe Ereignis kann von einer anderen Dienstinstanz erneut verarbeitet werden, wodurch ein zweiter Protokolleintrag mit einer anderen
_iderstellt wird
Dies ist ein erwartetes Systemverhalten und funktioniert wie vorgesehen.
Hat dies Auswirkungen auf die Ausführung von Journeys oder den Nachrichtenversand?
Nein. Die Auswirkungen sind auf die Protokollierung beschränkt. Adobe Journey Optimizer verfügt auf der Nachrichtenausführungsebene über integrierte Deduplizierungsmechanismen, die Folgendes sicherstellen:
- An jedes Profil wird nur eine Nachricht (E-Mail, SMS, Push-Benachrichtigung usw.) gesendet
- Aktionen werden nur einmal ausgeführt
- Journey-Ausführung läuft korrekt ab
Sie können dies prüfen, indem Sie den ajo_message_feedback_event_dataset abfragen oder die Aktionsausführungsprotokolle konsultieren. Sie werden sehen, dass trotz der doppelten Journey-Schrittereigniseinträge tatsächlich nur eine Nachricht gesendet wurde.
Wie kann ich diese Fälle in meinen Abfragen erkennen?
Gehen Sie beim Analysieren von Daten zu Journey-Schrittereignissen wie folgt vor:
-
Prüfen Sie das
_id-Feld: Echte Duplikate auf Systemebene würden denselben Wert für_idaufweisen. Unterschiedliche Werte für_idweisen auf separate Protokolleinträge aus dem oben beschriebenen Rebalancing-Szenario hin. -
Prüfen Sie den Nachrichtenversand: Sehen Sie sich auch die Daten zum Nachrichten-Feedback an, um sich zu vergewissern, dass nur eine Nachricht gesendet wurde:
code language-sql SELECT timestamp, _experience.customerJourneyManagement.messageExecution.messageExecutionID, _experience.customerJourneyManagement.messageDeliveryfeedback.feedbackStatus FROM ajo_message_feedback_event_dataset WHERE _experience.customerJourneyManagement.messageExecution.journeyVersionID = '<journeyVersionID>' AND TO_JSON(identityMap) like '%<profileID>%' ORDER BY timestamp DESC; -
Gruppieren Sie nach eindeutigen Kennungen: Verwenden Sie beim Zählen von Ausführungen
_id, um genaue Zahlen zu erhalten:code language-sql SELECT COUNT(DISTINCT _id) as unique_executions FROM journey_step_events WHERE _experience.journeyOrchestration.stepEvents.journeyVersionID = '<journeyVersionID>' AND _experience.journeyOrchestration.stepEvents.profileID = '<profileID>'
Was sollte ich tun, wenn mir das auffällt?
Dies ist ein normales Systemverhalten. Es ist keine Aktion erforderlich. Die Duplikatprotokollierung weist nicht auf ein Problem mit Ihrer Journey-Konfiguration oder dem Nachrichtenversand hin.
Wenn Sie Berichte oder Analysen auf der Grundlage von Journey-Schrittereignissen erstellen:
- Verwenden Sie
_idals Primärschlüssel für die Zählung eindeutiger Ereignisse - Sehen Sie sich bei der Analyse des Nachrichtenversands auch Datensätze mit Nachrichten-Feedback an
- Beachten Sie, dass die Zeitplanungsanalyse Einträge innerhalb weniger Sekunden gruppiert anzeigen kann
Weitere Informationen zum Abfragen von Journey-Schrittereignissen finden Sie unter Beispiele für Abfragen.
Fehlerbehebung bei Diskrepanzen bei Dashboard-Metriken dashboard-metrics
Wenn die im Dashboard Übersicht angezeigten Metriken nicht mit der tatsächlichen Anzahl der Journey auf der Registerkarte Durchsuchen übereinstimmen, überprüfen Sie Folgendes:
- Stellen Sie sicher, dass die betreffenden Journey in den letzten 24 Stunden Traffic hatten, da Journey ohne aktuelle Aktivität aus dem Dashboard ausgeschlossen werden.
- Vergewissern Sie sich, dass Sie über die entsprechenden Zugriffsberechtigungen verfügen, um alle Journey in Ihrem Unternehmen anzuzeigen.
- Warten Sie bis zu 30 Minuten, bis die Metriken aktualisiert sind, nachdem Sie Änderungen an Ihren Journey vorgenommen haben.
Wenn Diskrepanzen bestehen bleiben, wenden Sie sich zur Untersuchung an den Adobe-Support und zeigen Sie Screenshots der Registerkarten Übersicht und Durchsuchen an.