Choisir une méthode de validation choose-validation-method

Sur cette page : comparez la simulation de parcours, le mode test de parcours et le test à blanc de parcours. Découvrez quelle méthode correspond à l’étape où vous en êtes actuellement dans la création d’un parcours, depuis l’itération rapide pendant la conception jusqu’à la vérification finale avant le lancement en fonction de votre audience réelle.

Adobe Journey Optimizer vous propose trois méthodes pour valider un parcours avant sa mise en ligne. Elles ne sont pas interchangeables : chacune utilise un type de données différent, s’adapte à une étape différente de votre création et a des conséquences concrètes différentes. Comprendre la différence dès le départ vous permet d’éviter deux erreurs courantes. La première consiste à passer du temps à créer des profils de test alors qu’une simulation rapide suffirait. La seconde consiste à considérer qu’une étape de validation est entièrement « sécurisée » alors qu’elle peut encore accéder à de véritables boîtes de réception ou effectuer de vrais appels sortants.

IMPORTANT
Avant d’utiliser l’une de ces méthodes de test, cliquez sur Valider dans l’en-tête du parcours. Il exécute des contrôles de configuration, y compris des contrôles de messages, et affiche les erreurs et les avertissements dans le panneau Alertes ; il ne remplace pas les tests. Résolvez les erreurs et validez à nouveau avant de continuer. Si vous modifiez le parcours par la suite, exécutez à nouveau Valider avant de le tester ou de le publier. En savoir plus sur la validation des parcours ​.

Cette page se concentre sur la validation du flux de parcours et de la logique de branchement. Pour obtenir une vue d’ensemble des fonctionnalités de test et d’approbation (notamment la prévisualisation du contenu, le rendu des e-mails et les contrôles anti-spam, les expériences A/B et les workflows d’approbation), consultez Tester, valider et approuver.

Vous découvrez la validation ? Commencez par ici quick-pick

Si vous ne savez pas quelle méthode s’applique à votre situation, répondez à cette question :

  • Je suis toujours en train de concevoir mon parcours et je souhaite valider rapidement la logique d’une branche, sans créer de profil de test. → Utilisez la simulation de parcours.
  • Je souhaite valider manuellement pas à pas la logique de mon brouillon de parcours à l’aide de profils réels (mais désignés comme profils de test). → Utilisez le mode test de parcours.
  • Je suis sur le point de publier et je souhaite une vérification finale des volumes attendus par rapport à mon audience de production réelle, sans contacter qui que ce soit. → Utilisez le test à blanc de parcours.

Vous hésitez encore ou vous souhaitez une vue d’ensemble ? Continuez la lecture : chaque méthode est détaillé ci-dessous.

Les trois méthodes de validation validation-methods

Simulation de parcours

Utilisation : itération rapide lors de la conception du parcours, en particulier juste avant une échéance ou lors du test de nouvelles branches ou de nouveaux chemins d’accès. Elle fonctionne également bien comme méthode de validation continue chaque fois que la création d’un profil de test approprié à votre cas d’usage n’est pas envisageable.

La simulation de parcours valide votre parcours avec des utilisateurs et utilisatrices simulés temporaires. Nul besoin de créer ou d’attendre que des profils de test Adobe Experience Platform réels (AEP) se propagent. Vous pouvez créer manuellement des utilisateurs et utilisatrices simulés ou laisser l’IA générer automatiquement les événements de test dont votre parcours a besoin et les faire correspondre aux utilisateurs et utilisatrices simulés appropriés, ce qui déclenche le parcours en quelques secondes.

Mécanismes clés :

  • Les utilisateurs et utilisatrices simulés ne sont pas de vrais profils dans AEP. Vous pouvez également les enregistrer dans l’inventaire pour les réutiliser dans les simulations futures au lieu de les créer à chaque fois à partir de zéro.
  • Les critères de sortie, les politiques de consentement, le capping de la fréquence/du parcours, les processus d’opt-out/de suppression et les heures creuses ne sont pas évalués.
  • Les actions personnalisées et les appels de source de données externes effectuent toujours de vrais appels sortants, ils ne sont pas simulés.
note important
IMPORTANT
La simulation envoie des messages réels aux adresses d’exécution (e-mail, téléphone, jeton push) configurées sur les utilisateurs et utilisatrices simulés. Par exemple, votre propre adresse e-mail. Elle utilise le même pipeline de diffusion que la production. Elle ne contacte pas de vrais clientes ou clients, ou ne met pas à jour les données de profils en direct, mais les messages eux-mêmes sont réels.

Idéal pour : la validation d’une nouvelle branche (par exemple, deux nouveaux chemins de politique de décision) sans attendre la propagation du profil de test AEP.

➡️ Commencer avec la simulation de parcours | Simuler votre parcours

Mode test de parcours

Utilisation : vérification manuelle étape par étape de la logique des branches et des messages, avec des profils réels (mais désignés comme des profils de test) qui naviguent dans votre brouillon de parcours.

Le mode test de parcours permet de valider un brouillon de parcours à l’aide de profils de test AEP persistants. Pour confirmer que la logique de branchement et les mécanismes de diffusion des messages fonctionnent comme prévu avant qu’une audience de production n’atteigne le parcours, déclenchez manuellement les événements à partir de l’interface.

Mécanismes clés :

  • Seuls les profils indiqués comme « profils de test » dans le profil client en temps réel peuvent rejoindre un parcours dans le mode test de parcours.
  • Le mode test de parcours n’est disponible que pour les brouillons de parcours qui utilisent un espace de noms, car il doit vérifier dans AEP si une personne est un profil de test.
  • Un maximum de 100 profils de test peuvent rejoindre un parcours au cours d’une seule session de test et les événements ne peuvent être déclenchés qu’à partir de l’interface, et non à partir de systèmes externes via l’API.
  • La désactivation du mode test de parcours supprime tous les profils qui ont rejoint le parcours et efface les rapports.
note important
IMPORTANT
Le mode test de parcours envoie des messages réels aux boîtes de réception de vos profils de test, en utilisant le même pipeline de diffusion que la production. Il ne contacte pas de vrais clientes et clients, mais il ne s’agit pas non plus d’une simulation « à blanc » : assurez-vous que vos profils de test utilisent des adresses que vous contrôlez.

Problème : la création et la propagation de nouveaux profils de test AEP prennent du temps. La simulation de parcours offre une alternative rapide qui ne nécessite aucun profil de test. Elle s’avère utile non seulement pendant que vous attendez que les profils se propagent, mais aussi chaque fois qu’il n’est pas pratique de créer un profil de test adapté à votre cas d’usage.

➡️ Tester votre parcours

Test à blanc d’un parcours

Utilisation : pour effectuer une dernière vérification, réaliste par rapport à la production, juste avant la publication.

Le test à blanc de parcours est un mode de publication de parcours spécial qui exécute votre parcours par rapport aux données réelles d’audience et de segmentation de production, sans contacter les clientes et clients ni mettre à jour les informations de profil. Le parcours s’active comme un parcours dynamique et les profils traversent les branches et les nœuds exactement comme ils le feraient en production. Toutefois, les ​ nœuds d’action tels que les e-mails, les messages mobiles et les actions personnalisées sont ignorés.

Mécanismes clés :

  • Utilise votre audience de production réelle, afin que vous puissiez voir la portée réelle et le ciblage à grande échelle (par exemple, la détection d’un bug en raison duquel une branche entière ne reçoit inopinément aucun profil).
  • À chaque activation, pour obtenir des mesures plus rapidement, vous pouvez désactiver les activités d’attente et pour garder le parcours entièrement cloisonné, vous pouvez désactiver les appels à des sources de données externes.
  • Il s’agit actuellement d’une fonctionnalité en disponibilité limitée, déployée à l’échelle mondiale au fil du temps.

Idéal pour : détecter des problèmes tels que des nœuds de condition mal configurés ou des audiences qui n’atteignent pas de manière inattendue une branche, juste avant de mettre le parcours en ligne.

➡️ Test à blanc du parcours

Quelle méthode devriez-vous utiliser ? decision-guide

Commencez par une question simple : disposez-vous déjà de profils de test adaptés à votre cas d’usage ? Si oui, le mode test de parcours permet de valider pas à pas. Si ce n’est pas le cas, ou si leur création pour ce cas d’usage particulier n’est pas pratique, la simulation de parcours vous permet d’obtenir une validation en quelques secondes.

Au-delà de ce choix, la réponse se résume généralement à une question supplémentaire : à quel point ce test doit-il être proche de la production ?

Si vous êtes encore en train d’itérer sur la conception du parcours en testant une nouvelle branche ou en travaillant avec une échéance serrée, utilisez la simulation de parcours. Elle ne nécessite aucun profil réel et s’exécute en quelques secondes. Elle reste également un choix pertinent plus tard dans votre processus de développement, chaque fois qu’il n’est pas pratique de créer des profils de test adaptés à votre cas d’usage. Rappelez-vous simplement qu’elle envoie des messages réels aux adresses d’exécution configurées sur les personnes simulées.

Si vous devez vérifier manuellement la logique des branches et des messages étape par étape et que vous souhaitez créer ou réutiliser des profils de test AEP, utilisez le mode test de parcours. Rappelez-vous simplement qu’il envoie de vrais messages aux boîtes de réception réelles de ces profils de test.

Si vous êtes sur le point de publier et souhaitez une vérification finale des volumes prévus par rapport à votre audience de production réelle, utilisez le test à blanc de parcours. Il ne contacte jamais personne et ne modifie aucune donnée de profil.

TIP
Vous ne savez pas par où commencer ? La plupart des équipes utilisent la simulation de parcours lors de la création, puis un test à blanc de parcours juste avant la publication. Optez pour le mode test de parcours lorsque vous devez passer manuellement en revue la logique de branche avec des profils de test réels au lieu de profils simulés.

Comparaison rapide quick-comparison

Méthode
Données utilisées
Envoie de vrais messages ?
Idéal pour
Simulation de parcours
Personnes simulées temporaires, créées manuellement ou générées automatiquement.
Oui, aux adresses d’exécution configurées sur les personnes simulées.
Itération rapide sur de nouvelles branches ou nouveaux chemins, sans attendre la propagation réelle du profil de test.
Mode test de parcours
Profils de test AEP persistants.
Oui, vers les boîtes de réception réelles des profils de test, à l’aide du pipeline de diffusion de production.
Vérification manuelle étape par étape de la logique de la branche/du message dans un brouillon de parcours.
Test à blanc d’un parcours
Audience/données de production réelles.
Non (actions contournées).
Vérification finale de prélancement de la portée de l’audience, du ciblage et de la logique de branche réels à échelle réelle.

Aucune de ces méthodes ne contacte des clientes et clients. Les données de profil restent également inchangées dans tous les cas, à l’exception du mode test de parcours qui met à jour les profils de test utilisés pour l’exécution (et non les profils clients réels).

Erreurs courantes à éviter common-mistakes

  • Considérer que la simulation de parcours soit totalement « sécurisée ». Il s’agit du moyen le plus rapide de tester, mais il envoie toujours des messages réels à l’adresse d’exécution configurée pour chaque utilisateur ou utilisatrice simulés, généralement votre propre boîte de réception. Ne partez pas du principe que rien n’est envoyé.
  • Créer des profils de test AEP alors que la simulation de parcours suffirait. Si vous devez simplement valider rapidement une nouvelle branche ou un nouveau chemin de politique de décision, la simulation ignore entièrement l’attente de la propagation du profil de test. Réservez le mode test de parcours lorsque vous avez réellement besoin de profils de test réels.
  • Considérer le mode test de parcours comme un test « à blanc » Les profils en mode test de parcours reçoivent des messages réels par le biais du pipeline de diffusion de production. Assurez-vous que vos profils de test utilisent uniquement les adresses que vous contrôlez.
  • S’attendre à ce que le test à blanc de parcours détecte les problèmes de contenu ou de diffusion. Le test à blanc contourne entièrement les nœuds d’action : il valide la logique de portée de l’audience et de branche, et non le contenu du message ou la mécanique de diffusion. Utilisez le mode de simulation ou de test à blanc de parcours pour cela.
  • Oublier l’exigence d’espace de noms pour le mode test de parcours. Le mode test de parcours ne fonctionne que sur les brouillons de parcours qui utilisent un espace de noms, car Journey Optimizer a besoin d’un espace de noms pour vérifier si un profil est marqué comme profil de test.

Étapes suivantes next-steps

AI Knowledge Reference

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 Journey Simulation, Journey Test mode, and Journey Dry run to help users choose a validation method 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

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)

Guardrails:

  • Validate runs configuration checks, including message checks, and shows errors and warnings in the Alerts panel; it does not replace testing. Errors must be resolved and validation rerun before continuing. Edits require revalidation before testing or publishing.

  • Journey Test mode is only available for draft journeys that use a namespace, and supports a maximum of 100 test profiles per session (hard limit)

  • 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 names: Journey Simulation, Journey Test mode, Journey Dry run
  • 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 messages? — 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: Is Journey Dry run available to everyone? — It is currently a Limited Availability feature being rolled out globally over time.
  • 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.
recommendation-more-help
journey-optimizer-help