In questa pagina: confrontare simulazione Percorso, modalità Test Percorso ed esecuzione Percorso in prova. Scopri quale si adatta alla tua fase attuale di creazione di un percorso: da un’iterazione rapida durante la progettazione a un controllo pre-lancio finale rispetto al pubblico in tempo reale.
Adobe Journey Optimizer offre tre modi per convalidare un percorso prima della pubblicazione. Non sono intercambiabili: ognuno usa un tipo di dati diverso, si adatta a una fase diversa della tua build e comporta conseguenze diverse nel mondo reale. Comprendere la differenza fin dall’inizio ti aiuta a evitare due errori comuni. Il primo consiste nel trascorrere del tempo a creare profili di test quando una simulazione rapida può funzionare. Il secondo presuppone che un passaggio di convalida sia completamente “sicuro” quando può ancora contattare caselle in entrata reali o effettuare chiamate in uscita reali.
Questa pagina si concentra sulla convalida del flusso di percorso e della logica di diramazione. Per un quadro completo delle funzionalità di test e approvazione, inclusi anteprima del contenuto, rendering di e-mail e controlli di posta indesiderata, esperimenti A/B e flussi di lavoro di approvazione, vedere Test, convalida e approvazione.
Sei nuovo alla convalida? Inizia qui quick-pick
Se non sei sicuro del metodo applicabile, rispondi a questa domanda:
- Sto ancora progettando il mio percorso e desidero convalidare rapidamente la logica di un ramo, senza creare profili di test. → Utilizzare Simulazione Percorso.
- Desidero convalidare manualmente la logica del percorso bozza passo dopo passo, utilizzando profili di test reali (ma designati). → Utilizzare Modalità test Percorso.
- Sto per pubblicare e voglio un controllo finale dei volumi previsti rispetto al mio pubblico di produzione reale, senza contattare nessuno. → Usare Percorso di prova.
Non sei ancora sicuro, o vuoi il quadro completo? Continua a leggere — ogni metodo è descritto in dettaglio di seguito.
I tre metodi di convalida validation-methods
Quando utilizzare: Iterazione rapida durante la progettazione del percorso, in particolare prima di una scadenza o durante il test di nuovi rami o percorsi. Inoltre, funziona bene come metodo di convalida continuo quando la creazione di un profilo di test appropriato per il tuo caso d’uso non è pratica.
La simulazione dei Percorsi convalida il percorso con utenti simulati temporanei. Non è necessario creare o attendere la propagazione di profili di test Adobe Experience Platform (AEP) reali. Puoi creare manualmente gli utenti simulati, oppure consentire all’intelligenza artificiale di generare automaticamente gli eventi di test di cui il percorso ha bisogno e di farli corrispondere agli utenti simulati giusti, attivando il percorso in pochi secondi.
Meccanica chiave:
- Gli utenti simulati non sono profili reali in AEP; puoi anche salvarli nel inventario per riutilizzarli nelle simulazioni future invece di crearli ogni volta da zero.
- I criteri di uscita, i criteri di consenso, la limitazione di frequenza/percorso, la rinuncia/soppressione e le ore non interattive non vengono valutati.
- Le azioni personalizzate e le chiamate a origini dati esterne effettuano ancora vere chiamate in uscita, non vengono beffate.
| note important |
|---|
| IMPORTANT |
| La simulazione invia messaggi reali agli indirizzi di esecuzione (e-mail, telefono, token push) configurati sugli utenti simulati, ad esempio il tuo indirizzo e-mail. Utilizza la stessa pipeline di consegna della produzione. Non contatta clienti reali o aggiorna i dati del profilo live, ma i messaggi stessi sono reali. |
Ideale per: Convalida di un nuovo ramo (ad esempio, due nuovi percorsi dei criteri di decisione) senza attendere la propagazione del profilo di test di AEP.
➡️ Introduzione alla simulazione del percorso | Simula il tuo percorso
Quando utilizzare: verifica manuale della logica di ramo e messaggio passo dopo passo, con profili di test reali (ma designati) che attraversano il percorso di bozze.
Modalità di test Percorsi consente di convalidare un percorso bozza utilizzando Profili di test AEP persistenti. Per confermare che la logica di ramificazione e la meccanica di consegna dei messaggi funzionino come progettato prima che qualsiasi pubblico di produzione tocchi il percorso, attiva manualmente gli eventi dall’interfaccia.
Meccanica chiave:
- Solo i profili contrassegnati come “profili di test” in Real-Time Customer Profile possono accedere a un percorso in modalità di test Percorso.
- La modalità Test percorso è disponibile solo per i percorsi bozza che utilizzano uno spazio dei nomi 🔗, poiché deve verificare in AEP se una persona è un profilo di test.
- Un massimo di 100 profili di test può entrare in un percorso durante una singola sessione di test e gli eventi possono essere attivati solo dall’interfaccia, non da sistemi esterni tramite API.
- La disattivazione della modalità di test Percorso rimuove tutti i profili che sono entrati nel percorso e cancella i rapporti.
| note important |
|---|
| IMPORTANT |
| La modalità di test del percorso invia messaggi reali alle caselle in entrata effettive dei profili di test, utilizzando la stessa pipeline di consegna della produzione. Non contatta clienti reali, ma non si tratta neanche di una simulazione "a secco": assicurati che i profili di test utilizzino gli indirizzi che controlli. |
Punto critico: La creazione e la propagazione di nuovi profili di test di AEP richiede tempo. Simulazione Percorso offre un’alternativa rapida che non richiede alcun profilo di test. È utile non solo in attesa che i profili si propaghino, ma non è pratico creare in qualsiasi momento un profilo di test appropriato per il caso d’uso.
Quando utilizzare: un controllo finale e realistico della produzione subito prima della pubblicazione.
Percorso di prova è una modalità speciale di pubblicazione del percorso che esegue il percorso rispetto al pubblico di produzione reale e ai dati di segmentazione, senza contattare clienti reali o aggiornare le informazioni del profilo. Il percorso si attiva come un percorso live e i profili passano attraverso rami e nodi esattamente come farebbero in produzione. Tuttavia, nodi azione quali e-mail, SMS e azioni personalizzate vengono ignorati.
Meccanica chiave:
- Utilizza il pubblico di produzione effettivo, in modo da visualizzare la portata reale e il targeting su larga scala (ad esempio, individuare un bug in cui un intero ramo riceve inaspettatamente zero profili).
- A ogni attivazione, per recuperare più rapidamente le metriche puoi disabilitare le attività di attesa e mantenere il percorso completamente isolato puoi disabilitare le chiamate a origini dati esterne.
- La funzionalità Disponibilità limitata è attualmente in fase di rollout a livello globale nel tempo.
Ideale per: Rilevare problemi come nodi di condizione digitati in modo errato o tipi di pubblico che non raggiungono in modo imprevisto un ramo, immediatamente prima di capovolgere il percorso dal vivo.
Quale metodo si deve utilizzare? decision-guide
Inizia con una semplice domanda: hai già profili di test adatti al tuo caso d’uso? In caso affermativo, la modalità di test Percorso ti consente di convalidarla passo dopo passo. In caso contrario, o se non è possibile crearli per questo particolare caso d’uso, la simulazione dei Percorsi ti fa convalidare in secondi.
Al di là di questa scelta, la risposta in genere si riduce a un’altra domanda: quanto è vicino alla produzione questo test?
Se stai ancora iterando nella progettazione del percorso — testando un nuovo ramo, lavorando in base a una scadenza — utilizza Simulazione del Percorso. Non ha bisogno di profili reali ed è in esecuzione in secondi. Resta inoltre una scelta valida in un secondo momento della build, ogni volta che non è pratico creare profili di test adatti al tuo caso d’uso. Ricordati che invia messaggi reali agli indirizzi di esecuzione configurati sugli utenti simulati.
Se devi verificare manualmente il ramo e la logica dei messaggi passo dopo passo e sei disposto a creare o riutilizzare i profili di test di AEP, utilizza Modalità test Percorso. Ricorda solo che invia messaggi reali alle caselle in entrata reali dei profili di test.
Se stai per pubblicare e desideri un controllo finale dei volumi previsti rispetto al pubblico di produzione effettivo, utilizza Percorso di prova. Non contatta mai nessuno o modifica i dati del profilo.
Confronto rapido quick-comparison
Nessuno di questi metodi contatta clienti reali. Anche i dati di profilo vengono lasciati intatti in ogni caso, con la differenza che la modalità Test di Percorso aggiorna i profili di test utilizzati per eseguirli (non i profili cliente reali).
Errori comuni da evitare common-mistakes
- La simulazione del Percorso è completamente “sicura”. È il modo più veloce per eseguire il test, ma invia comunque messaggi reali all’indirizzo di esecuzione configurato su ogni utente simulato, di solito la tua casella in entrata. Non presumere che non venga inviato nulla.
- Creazione dei profili di test di AEP quando dovrebbe essere eseguita la simulazione del Percorso. Se devi solo convalidare rapidamente un nuovo ramo o percorso di criteri decisionali, la simulazione evita completamente l’attesa della propagazione del profilo di test, salvando la modalità di test Percorso per i casi in cui siano effettivamente necessari profili di test reali.
- Trattamento della modalità di test Percorso come “dry” I profili della modalità di test del percorso ricevono messaggi reali tramite la pipeline di consegna della produzione. Assicurati che i profili di test utilizzino solo gli indirizzi controllati.
- Prevista esecuzione di prova del Percorso per rilevare il contenuto o problemi di consegna. L’esecuzione a secco ignora completamente i nodi di azione: convalida la logica di diffusione e diramazione del pubblico, non il contenuto dei messaggi o la meccanica di consegna. Utilizza la modalità Simulazione o Test Percorso.
- Dimenticamento del requisito dello spazio dei nomi per la modalità Test Percorso. La modalità Test percorso funziona solo su percorsi bozza che utilizzano uno spazio dei nomi, perché Journey Optimizer necessita di uno spazio dei nomi per verificare se un profilo è contrassegnato come profilo di test.
Passaggi successivi next-steps
- Introduzione alla simulazione di percorso — Eseguire la prima simulazione
- Verifica il percorso - Attiva la modalità di test del Percorso con i profili di test di AEP
- Percorso di esecuzione di prova — Esecuzione di un’esecuzione di prova realistica per la produzione
- Pubblicare il percorso — Prerequisiti e processo di pubblicazione
- Introduzione ai percorsi: panoramica su nozioni di base e funzionalità
- Domande frequenti su Journey Orchestration — Risposte alle domande comuni
- Test, convalida e approvazione: scenario completo di test e approvazione, inclusi anteprima del contenuto, controlli di rendering/posta indesiderata, esperimenti e flussi di lavoro di approvazione
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.