Auf dieser Seite: Vergleichen Sie Journey-Simulation, Journey-Testmodus und Journey-Probelauf. Erfahren Sie, welche Version für Ihre aktuelle Phase beim Erstellen einer Journey geeignet ist – von der schnellen Iteration während des Designs bis hin zur abschließenden Prüfung anhand Ihrer Live-Zielgruppe vor der Markteinführung.
Adobe Journey Optimizer bietet Ihnen drei Möglichkeiten, eine Journey zu validieren, bevor sie live geschaltet wird. Sie sind nicht austauschbar: Jede verwendet eine andere Art von Daten, passt zu einer anderen Stufe Ihres Builds und hat unterschiedliche Folgen in der Praxis. Wenn Sie den Unterschied im Voraus verstehen, können Sie zwei häufige Fehler vermeiden. Der erste besteht darin, Zeit in die Erstellung von Testprofilen zu investieren, wenn eine schnelle Simulation ausreichen würde. Der zweite besteht darin, anzunehmen, dass ein Validierungsschritt vollständig „sicher“ ist, obwohl immer noch echte Posteingänge kontaktiert oder echte ausgehende Aufrufe durchgeführt werden könnten.
Auf dieser Seite wird die Validierung des Journey Flows und der Verzweigungslogik beschrieben. Einen vollständigen Überblick über Test- und Genehmigungsfunktionen – einschließlich Inhaltsvorschau, E-Mail-Rendering und Spam-Prüfungen, A/B-Experimente sowie Genehmigungs-Workflows – finden Sie unter Testen, Validieren und Genehmigen.
Neu bei der Validierung? Beginnen Sie hier quick-pick
Wenn Sie sich nicht sicher sind, welche Methode für Sie geeignet ist, stellen Sie sich folgende Szenarien vor:
- Ich entwerfe meine Journey noch und möchte die Logik einer Verzweigung schnell validieren, ohne Testprofile zu erstellen. → Verwenden Sie die Journey-Simulation.
- Ich möchte den Logikschritt meiner Entwurfs-Journey Schritt für Schritt manuell mithilfe echter (aber designierter) Testprofile validieren. → Verwenden Sie den Journey-Testmodus.
- Ich stehe kurz vor der Veröffentlichung und möchte eine abschließende Überprüfung der erwarteten Volumina für meine tatsächliche Produktionszielgruppe durchführen, ohne irgendjemanden zu kontaktieren. → Verwenden Sie den Journey-Probelauf.
Immer noch nicht sicher oder benötigen Sie weitere Informationen? Lesen Sie weiter – jede Methode wird unten detailliert beschrieben.
Die drei Validierungsmethoden validation-methods
Verwendung: Schnelle Iteration während der Journey-Gestaltung, insbesondere kurz vor Ablauf einer Frist oder beim Testen neuer Verzweigungen oder Pfade. Sie funktioniert auch als kontinuierliche Validierungsmethode, wenn das Erstellen eines geeigneten Testprofils für Ihren Anwendungsfall nicht praktikabel ist.
Die Journey-Simulation validiert Ihre Journey mit temporären simulierten Benutzenden – Sie müssen keine echten Testprofile für Adobe Experience Platform (AEP) erstellen oder auf ihre Propagierung warten. Sie können simulierte Benutzende manuell erstellen oder zulassen, dass KI automatisch die für Ihre Journey erforderlichen Testereignisse erstellt und sie den richtigen simulierten Benutzenden zuordnet, wodurch die Journey in Sekunden ausgelöst wird.
Wichtige Mechaniken:
- Simulierte Benutzende sind keine echten Profile in AEP. Sie können sie auch im Inventar speichern, um sie in zukünftigen Simulationen wiederzuverwenden, anstatt sie jedes Mal von Grund auf neu zu erstellen.
- Ausstiegskriterien, Einverständnisrichtlinien, Frequenz-/Journey-Begrenzung, Opt-out/Unterdrückung und Ruhezeiten werden nicht ausgewertet.
- Benutzerdefinierte Aktionen und externe Aufrufe von Datenquellen führen weiterhin echte ausgehende Aufrufe aus – sie werden nicht simuliert.
| note important |
|---|
| IMPORTANT |
| Simulation sendet echte Nachrichten an die Ausführungsadressen (E-Mail, Telefon, Push-Token), die für die simulierten Benutzenden konfiguriert sind, z. B. Ihre eigene E-Mail-Adresse. Es wird dieselbe Versand-Pipeline wie für die Produktion verwendet. Es werden keine echten Kundinnen und Kunden kontaktiert und keine Live-Profildaten aktualisiert, aber die Nachrichten selbst sind echt. |
Perfekt für: Validieren einer neuen Verzweigung (z. B. zwei neue Entscheidungsrichtlinienpfade) ohne auf die Propagierung von AEP-Testprofilen warten zu müssen.
➡️ Erste Schritte mit der Journey-Simulation | Simulieren Ihrer Journey
Verwendung: Manuelles Überprüfen der Verzweigungs- und Nachrichtenlogik Schritt für Schritt, wobei echte (aber designierte) Testprofile Ihre Entwurfs-Journey durchlaufen.
Der Journey-Testmodus ermöglicht die Validierung eines Journey-Entwurfs mithilfe persistenter AEP-Testprofile. Um zu bestätigen, dass die Verzweigungslogik und die Nachrichtenversandmechanik wie vorgesehen funktionieren, bevor eine Produktions-Zielgruppe mit der Journey in Kontakt kommt, lösen Sie Ereignisse manuell von der Oberfläche aus.
Wichtige Mechaniken:
- Nur als „Testprofile“ im Echtzeit-Kundenprofil markierte Profile können in eine Journey im Journey-Testmodus eintreten.
- Der Journey-Testmodus ist nur für Entwurfs-Journeys verfügbar, die einen Namespace verwenden, da in AEP überprüft werden muss, ob es sich bei einer Person um ein Testprofil handelt.
- Während einer einzelnen Testsitzung können maximal 100 Testprofile in eine Journey eintreten. Ereignisse können nur über die Benutzeroberfläche und nicht über API von externen Systemen ausgelöst werden.
- Durch Deaktivieren des Journey-Testmodus werden alle Profile entfernt, die in die Journey eingetreten sind, und das Reporting wird gelöscht.
| note important |
|---|
| IMPORTANT |
| Beim Journey-Testmodus werden echte Nachrichten an die tatsächlichen Posteingänge Ihrer Testprofile gesendet, wobei dieselbe Versand-Pipeline wie bei der Produktion verwendet wird. Es keine echten Kundinnen und Kunden kontaktiert, aber es ist auch keine reine Simulation. Stellen Sie sicher, dass Ihre Testprofile Adressen verwenden, über die Sie Kontrolle haben. |
Problem: Das Erstellen und Übertragen neuer AEP-Testprofile dauert eine gewisse Zeit. Journey-Simulation bietet eine schnelle Alternative, die überhaupt keine Testprofile erfordert. Dies ist nicht nur während des Wartens auf die Propagierung von Profilen nützlich, sondern auch immer dann, wenn die Erstellung eines geeigneten Testprofils für Ihren Anwendungsfall nicht praktikabel ist.
Verwendung: Eine finale, produktionsrealistische Prüfung direkt vor der Veröffentlichung.
Journey-Probelauf ist ein spezieller Journey-Veröffentlichungsmodus, bei dem Ihre Journey mit realen Produktions-Zielgruppen- und Segmentierungsdaten ausgeführt wird, ohne echte Personen zu kontaktieren oder Profilinformationen zu aktualisieren. Die Journey wird wie eine Live-Journey aktiviert, und Profile durchlaufen Verzweigungen und Knoten genau so, wie sie es in der Produktion tun würden. Aktionsknoten wie E-Mail-, SMS- und benutzerdefinierte Aktionen werden jedoch umgangen.
Wichtige Mechaniken:
- Ihre tatsächliche Produktions-Zielgruppe wird verwendet, damit Sie im großen Umfang die reale Reichweite und das Targeting sehen. So können Sie z. B. einen Fehler finden, bei dem eine gesamte Verzweigung unerwartet null Profile erhält.
- Bei jeder Aktivierung können Sie Warteaktivitäten deaktivieren, um Metriken schneller zurückzuerhalten. Damit die Journey vollständig isoliert bleibt, können Sie außerdem Aufrufe externer Datenquellen deaktivieren.
- Dies ist derzeit eine Funktion mit eingeschränkter Verfügbarkeit, die im Laufe der Zeit global eingeführt wird.
Ideal für: Finden von Problemen unmittelbar vor dem Live-Schalten der Journey, z. B. falsch eingegebene Bedingungsknoten oder Zielgruppen, die unerwartet keine Verzweigung erreichen.
Welche Methode sollten Sie verwenden? decision-guide
Beginnen Sie mit einer einfachen Frage: Verfügen Sie bereits über Testprofile, die zu Ihrem Anwendungsfall passen? Wenn ja, können Sie damit im Journey-Testmodus Schritt für Schritt validieren. Falls nicht oder wenn deren Erstellung für diesen speziellen Anwendungsfall nicht praktikabel ist, können Sie die Validierung mit der Journey-Simulation in wenigen Sekunden durchführen.
Jenseits dieser Wahlmöglichkeit läuft die Antwort meist auf eine weitere Frage hinaus: Wie nahe muss dieser Test an der Produktion sein?
Wenn Sie immer noch das Journey-Design iterieren und z. B. eine neue Verzweigung testen und unter Termindruck stehen, verwenden Sie die Journey-Simulation. Dafür werden keine echten Profile benötigt und die Ausführung dauert nur wenige Sekunden. Dies bleibt auch in späteren Entwicklungsphasen eine valide Option, wann immer das Erstellen geeigneter Testprofile für Ihren Anwendungsfall nicht praktikabel ist. Denken Sie daran, dass echte Nachrichten an die für die simulierten Benutzenden konfigurierten Ausführungsadressen gesendet werden.
Wenn Sie die Verzweigungs- und Nachrichtenlogik Schritt für Schritt manuell überprüfen müssen und bereit sind, AEP-Testprofile zu erstellen oder wiederzuverwenden, verwenden Sie den Journey-Testmodus. Denken Sie aber daran, dass echte Nachrichten an die echten Posteingänge dieser Testprofile gesendet werden.
Wenn Sie kurz davor sind, zu veröffentlichen und eine abschließende Überprüfung der erwarteten Volumina für Ihre tatsächliche Produktions-Zielgruppe durchführen möchten, verwenden Sie den Journey-Probelauf. Dabei werden weder Personen kontaktiert noch Profildaten geändert.
Schnellvergleich quick-comparison
Keine dieser Methoden kontaktiert echte Personen. Auch Profildaten bleiben in allen Fällen unberührt. Der Journey-Testmodus aktualisiert lediglich die für die Ausführung verwendeten Testprofile (keine echten Kundenprofile).
Häufige Fehler, die vermieden werden sollten common-mistakes
- Die Annahme, dass die Journey-Simulation vollkommen „sicher“ ist. Es ist die schnellste Methode zum Testen, sendet jedoch weiterhin echte Nachrichten an die für jede simulierte Testperson konfigurierte Ausführungsadresse – meist an Ihren eigenen Posteingang. Gehen Sie nicht davon aus, dass nichts gesendet wird.
- Die Erstellung von AEP-Testprofilen, wenn eine Journey-Simulation völlig ausreichend wäre. Wenn Sie lediglich eine neue Verzweigung oder einen Pfad für Entscheidungsrichtlinien schnell validieren möchten, entfällt bei der Simulation die Wartezeit auf die Propagierung der Testprofile vollständig – reservieren Sie den Journey-Testmodus für die Fälle, in denen Sie tatsächlich echte Testprofile benötigen.
- Die Annahme, dass der Journey-Testmodus ein reiner Probelauf ist. Profile im Journey-Testmodus erhalten echte Nachrichten über dieselbe Versand-Pipeline wie in der Produktion. Stellen Sie sicher, dass Ihre Testprofile ausschließlich Adressen verwenden, die Sie selbst kontrollieren.
- Die Annahme, dass der Journey-Probelauf Inhalts- oder Versandprobleme erkennt. Ein Probelauf umgeht Aktionsknoten vollständig – er validiert die Zielgruppenreichweite und die Verzweigungslogik, nicht jedoch den Nachrichteninhalt oder die Versandmechanismen. Verwenden Sie dazu die Simulation oder den Journey-Testmodus.
- Das Nichtbeachten der Namespace-Anforderung für den Journey-Testmodus. Der Journey-Testmodus funktioniert nur bei Journey-Entwürfen, die einen Namespace verwenden, da Journey Optimizer einen Namespace benötigt, um zu überprüfen, ob ein Profil als Testprofil gekennzeichnet ist.
Nächste Schritte next-steps
- Erste Schritte mit der Journey-Simulation – Ausführen der ersten Simulation
- Testen der Journey – Aktivieren des Journey-Testmodus mit AEP-Testprofilen
- Journey-Probelauf – Ausführen eines Probelaufs unter Produktionsbedingungen
- Veröffentlichen der Journey – Voraussetzungen und Veröffentlichungsprozess
- Erste Schritte mit Journeys – Überblick über Grundlagen und Funktionen
- Häufig gestellte Fragen zur Journey-Orchestrierung – Antworten auf häufig gestellte Fragen
- Testen, Validieren und Genehmigen – Vollständiger Überblick über Tests und Genehmigungen, einschließlich Inhaltsvorschau, Rendering-/Spam-Prüfungen, Experimenten und Genehmigungs-Workflows
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page compares the three journey validation methods in Adobe Journey Optimizer — Journey Simulation, Journey Test mode, and Journey Dry run. It provides a one-question quick pick, a decision guide, a quick-comparison table, and a list of common mistakes to help users choose the right one for their current stage of building a journey.
Intents:
- Choose the correct validation method for a given stage of journey building
- Compare Journey Simulation, Journey Test mode, and Journey Dry run side by side
- Understand when to use Journey Simulation for fast iteration without real test profiles
- Understand when to use Journey Test mode for step-by-step manual validation with real test profiles
- Understand when to use Journey Dry run for a final pre-launch check against production data
- Understand which validation methods send real messages or contact real customers
- Avoid common mistakes when picking or using a validation method
Glossary:
- Journey Simulation: A validation method that uses temporary simulated users, manually created or auto-generated, to test a journey without needing real AEP test profiles. (product-specific)
- Journey Test mode: A validation method that uses persistent AEP test profiles, flagged in Real-Time Customer Profile, to manually walk through a draft journey’s branch and message logic. (product-specific)
- Journey Dry run: A publication mode that runs a journey against real production audience data without contacting customers or updating profile data; action nodes are bypassed. (product-specific)
- Simulation Agent: The mechanism that automatically generates test events and matches them to simulated users during Journey Simulation. (product-specific)
Guardrails:
- Journey Test mode is only available for draft journeys that use a namespace, and supports a maximum of 100 test profiles per session
- Journey Test mode events can only be fired from the interface, not from external systems via API
- Journey Test mode sends real messages to test profiles’ real inboxes using the production delivery pipeline
- Disabling Journey Test mode removes all profiles that entered the journey and clears its reporting
- Journey Simulation does not evaluate exit criteria, consent policies, frequency/journey capping, opt-out/suppression, or quiet hours
- Journey Simulation’s custom actions and external data source calls are real, not mocked
- Journey Simulation sends real messages to the execution addresses (email, phone, push token) configured on the simulated users, using the same delivery pipeline as production
- Unlike Journey Simulation, Journey Dry run never sends real messages
- Journey Dry run is currently a Limited Availability feature, being rolled out globally over time
- Journey Dry run bypasses action nodes (email, SMS, custom actions) but still routes profiles through branches and nodes using real production data
Terminology:
- Canonical name: Journey Simulation — variants: simulate, simulation mode
- Canonical name: Journey Test mode — variants: Test mode, journey testing, test your journey
- Canonical name: Journey Dry run — variants: dry run, dry run mode
- Do not confuse: Journey Simulation (temporary simulated users, no AEP test profiles needed, sends real messages to the simulated users’ configured execution addresses) ≠ Journey Test mode (persistent AEP test profiles, sends real messages to those profiles’ real inboxes) ≠ Journey Dry run (real production audience data, no contact, no profile update, action nodes bypassed, never sends real messages)
FAQ:
- Q: Which validation method should I use while I am still designing a journey? — Use Journey Simulation; it needs no real test profiles and runs in seconds, making it ideal for fast iteration.
- Q: Does Journey Simulation send real messages? — Yes. Simulation delivers real messages to the execution addresses (email, phone, push token) configured on the simulated users, often the tester’s own address. It uses the same delivery pipeline as production, but it does not contact real customers or update live profile data.
- Q: Does Journey Test mode send real emails or SMS? — Yes. Journey Test mode delivers real messages to the actual inboxes of your test profiles, using the same delivery pipeline as production. It does not contact real customers, but the messages themselves are real.
- Q: Does Journey Dry run send any messages? — No. Dry run bypasses action nodes such as email, SMS, and custom actions, so profiles flow through the journey logic without any message being sent.
- Q: I need to validate a new branch quickly before a deadline. Which method fits? — Journey Simulation; it generates simulated users on demand (or reuses ones saved to the inventory) instead of requiring you to pre-create and wait for real test profiles.
- Q: Is Journey Dry run available to everyone? — It is currently a Limited Availability feature being rolled out globally over time; check availability for your organization.
- Q: Can I fire Journey Test mode events from an external system? — No; in Journey Test mode, events can only be fired from the interface, not from external systems via API.