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 vor der Markteinführung vor der Live-Audience.
Adobe Journey Optimizer bietet Ihnen drei Möglichkeiten, eine Journey zu validieren, bevor sie live geschaltet wird. Sie sind nicht austauschbar: Jeder verwendet eine andere Art von Daten, passt zu einem anderen Schritt Ihres Builds und hat unterschiedliche reale Folgen. Wenn Sie den Unterschied im Voraus verstehen, können Sie zwei häufige Fehler vermeiden. Die erste besteht darin, Zeit in die Erstellung von Testprofilen zu investieren, wenn eine schnelle Simulation ausreichen würde. Der zweite Schritt geht davon aus, dass ein Validierungsschritt vollständig „sicher“ ist, wenn er immer noch echte Posteingänge kontaktieren oder echte ausgehende Aufrufe tätigen kann.
Auf dieser Seite wird die Validierung des Journey-Flusses und der Verzweigungslogik beschrieben. Ein vollständiges Bild der Test- und Genehmigungsfunktionen - einschließlich Inhaltsvorschau, E-Mail-Rendering und Spam-Prüfungen, A/B-Experimente und 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 gilt, beantworten Sie diese eine Frage:
- Ich entwerfe noch meine Journey und möchte die Logik einer Verzweigung schnell validieren, ohne Testprofile zu erstellen. → Journey-Simulation verwenden.
- Ich möchte meine Entwurfslogik der Journey Schritt für Schritt manuell mithilfe echter (aber designierter) Testprofile validieren. → Journey-Testmodus verwenden.
- Ich bin im Begriff, zu veröffentlichen und möchte eine abschließende Überprüfung der erwarteten Volumina gegenüber meiner tatsächlichen Produktionspublikation, ohne irgendjemanden zu kontaktieren. → Verwenden Sie Journey Probelauf.
Immer noch nicht sicher, oder wollen Sie das vollständige Bild? Lesen Sie weiter — jede Methode wird unten detailliert beschrieben.
Die drei Validierungsmethoden validation-methods
Verwendung: Schnelle Iteration beim Journey-Design, insbesondere kurz vor Ablauf einer Frist oder beim Testen neuer Verzweigungen oder Pfade. Es funktioniert auch als kontinuierliche Validierungsmethode, wenn das Erstellen eines geeigneten Testprofils für Ihren Anwendungsfall nicht praktikabel ist.
Journey-Simulation Validiert Ihren Journey mit temporären simulierten Benutzenden - Sie müssen keine echten Adobe Experience Platform (AEP)-Testprofile erstellen oder darauf warten, dass sie sich ausbreiten. Sie können simulierte Benutzende manuell erstellen oder zulassen, dass KI automatisch die Testereignisse generiert, die Ihr Journey benötigt, und sie den richtigen simulierten Benutzenden zuordnet, wodurch das Journey in Sekunden ausgelöst wird.
Schlüsselmechanik:
- Simulierte Benutzende sind in AEP keine echten Profile. 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, Häufigkeit/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 verspottet.
| note important |
|---|
| IMPORTANT |
| Simulation sendet echte Nachrichten an die Ausführungsadressen (E-Mail, Telefon, Push-Token), die für die simulierten Benutzer konfiguriert sind - z. B. Ihre eigene E-Mail-Adresse. Es wird dieselbe Bereitstellungs-Pipeline wie für die Produktion verwendet. Es kontaktiert keine echten Kunden und aktualisiert keine Live-Profildaten, aber die Nachrichten selbst sind real. |
Perfekt für: Validieren einer neuen Verzweigung (z. B. zwei neue Entscheidungsrichtlinienpfade) ohne auf die Testprofilweitergabe an AEP zu warten.
➡️ Erste Schritte mit der Journey- | Simulieren Sie Ihren Journey
Verwendung: Manuelles Überprüfen der Verzweigungs- und Nachrichtenlogik Schritt für Schritt, wobei echte (aber designierte) Testprofile Ihre Entwurfs-Journey durchlaufen.
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 den Journey berührt, lösen Sie Ereignisse manuell von der -Oberfläche aus.
Schlüsselmechanik:
- Nur Profile, die im Echtzeit-Kundenprofil als „Testprofile“ gekennzeichnet sind, können im Journey-Testmodus auf eine Journey zugreifen.
- Der Journey-Testmodus ist nur für Entwurfs-Journey verfügbar, die einen Namespace verwenden, da sie mit AEP abgleichen müssen, ob eine Person ein Testprofil ist.
- Während einer einzelnen Testsitzung können maximal 100 Testprofile auf eine Journey zugreifen. 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 auf die Journey zugegriffen haben, und die Berichte 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 kontaktiert keine echten Kunden, aber es ist auch keine „trockene“ Simulation - stellen Sie sicher, dass Ihre Testprofile Adressen verwenden, die Sie steuern. |
Problem: Das Erstellen und Übertragen neuer AEP-Testprofile dauert seine Zeit. Journey Simulation bietet eine schnelle Alternative, die überhaupt keine Testprofile erfordert. Dies ist nicht nur während des Wartens auf die Ausbreitung von Profilen nützlich, sondern auch jedes Mal, wenn Sie ein geeignetes Testprofil für Ihren Anwendungsfall erstellen, ist dies nicht praktikabel.
Verwendung: Eine endgültige, produktionsrealistische Prüfung direkt vor der Veröffentlichung.
Journey Dry Run ist ein spezieller Journey-Veröffentlichungsmodus, bei dem Ihr Journey mit echten Produktions-Zielgruppen- und Segmentierungsdaten ausgeführt wird, ohne echte Kunden zu kontaktieren oder Profilinformationen zu aktualisieren. Der Journey wird wie eine Live-Journey aktiviert, und Profile fließen durch Verzweigungen und Knoten genau so, wie sie es in der Produktion tun würden. Aktionsknoten wie EMail, SMS und benutzerdefinierte Aktionen werden jedoch umgangen.
Schlüsselmechanik:
- Verwendet Ihre tatsächliche Produktions-Zielgruppe, sodass Sie die tatsächliche Reichweite und das Targeting in großem Maßstab sehen (z. B. einen Fehler fangen, bei dem eine gesamte Verzweigung unerwartet null Profile erhält).
- Bei jeder Aktivierung können Sie Warteaktivitäten deaktivieren, um Metriken schneller zurückzuerhalten, und um die Journey vollständig isoliert zu halten, können Sie Aufrufe externer Datenquellen deaktivieren.
- Dies ist derzeit eine Funktion Eingeschränkte Verfügbarkeit, die im Laufe der Zeit global eingeführt wird.
Ideal für: Sie Probleme wie falsch eingegebene Bedingungsknoten oder Zielgruppen, die unerwartet keine Verzweigung erreichen, direkt vor dem Live-Spiegeln der Journey.
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 im Journey Testmodus die Validierung Schritt für Schritt durchführen. Wenn dies nicht der Fall ist oder die Erstellung für diesen speziellen Anwendungsfall nicht sinnvoll ist, werden Sie bei Journey Simulation in Sekunden validiert.
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 im Journey-Design) eine neue Verzweigung testen und dabei gegen einen Termin arbeiten, verwenden Sie die Journey-Simulation. Es benötigt keine echten Profile und wird in Sekunden ausgeführt. Es bleibt auch später im Build eine gültige Wahl, wenn das Erstellen geeigneter Testprofile für Ihren Anwendungsfall nicht praktisch ist. Denken Sie daran, dass echte Nachrichten an die Ausführungsadressen gesendet werden, die für die simulierten Benutzer konfiguriert sind.
Wenn Sie die Verzweigungs und Nachrichtenlogik Schritt für Schritt manuell überprüfen müssen bereit sind, AEP-Testprofile zu erstellen oder wiederzuverwenden, verwenden Sie den Journey-Testmodus. Denken Sie daran, dass es echte Nachrichten an die echten Posteingänge dieser Testprofile sendet.
Wenn Sie im Begriff sind, zu veröffentlichen und eine abschließende Überprüfung der erwarteten Volumes anhand Ihrer tatsächlichen Produktions-Audience durchführen möchten, verwenden Sie Journey Probelauf. Es kontaktiert nie jemanden oder ändert keine Profildaten.
Schnellvergleich quick-comparison
Keine dieser Methoden kontaktiert echte Kunden. Profildaten bleiben in allen Fällen unberührt, mit der Ausnahme, dass der Journey-Testmodus die Testprofile aktualisiert, mit denen sie ausgeführt werden (keine echten Kundenprofile).
Häufige zu vermeidende Fehler common-mistakes
- Angenommen, die Journey-Simulation ist absolut sicher. Dies ist die schnellste Methode zum Testen, aber es sendet trotzdem echte Nachrichten an die Ausführungsadresse, die für jeden simulierten Benutzer konfiguriert ist - normalerweise Ihr eigener Posteingang. Gehen Sie nicht davon aus, dass nichts gesendet wird.
- Erstellen von AEP-Testprofilen, wenn das Journey-Simulation ausreichen würde. Wenn Sie nur eine neue Verzweigung oder einen neuen Entscheidungsrichtlinienpfad schnell validieren müssen, überspringt die Simulation das Warten auf die Testprofilweitergabe vollständig - speichern Sie den Journey-Testmodus für den Fall, dass Sie tatsächlich echte Testprofile benötigen.
- Behandeln des Journey-Testmodus als „trocken“ Journey-Testmodusprofile empfangen echte Nachrichten über die Produktionsversand-Pipeline. Stellen Sie sicher, dass Ihre Testprofile nur von Ihnen kontrollierte Adressen verwenden.
- Es wird ein Journey-Probelauf erwartet, um Inhalts- oder Bereitstellungsprobleme zu erfassen. Ein Probelauf umgeht Aktionsknoten vollständig - er validiert die Reichweite und Verzweigungslogik der Zielgruppe, nicht den Nachrichteninhalt oder die Versandmechanik. Verwenden Sie dazu den Simulations- oder Journey-Testmodus.
- Namespace-Anforderung für das Journey des Testmodus wird vergessen. Der Journey-Testmodus funktioniert nur bei Entwurfs-Journeys, 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 — Führen Sie Ihre erste Simulation aus
- Journey testen — Aktivieren des Journey-Testmodus mit AEP-Testprofilen
- Journey-Probelauf — Führen Sie einen produktionsrealistischen Probelauf aus
- Veröffentlichen des Journey — Voraussetzungen und Veröffentlichungsprozess
- Erste Schritte mit Journey — Überblick über Grundlagen und Funktionen
- Häufig gestellte Fragen zu Journey Orchestration — Häufig gestellte Fragen beantwortet
- Testen, Validieren und Genehmigen - Vollständige Test- und Genehmigungslandschaft, 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.