Test your journey

Once you have built your journey, you can test it before publishing. Journey Optimizer offers “Test mode” as a way to view test profiles as they move along the journey, detecting potential errors before activation. Running quick tests allows you to check that journeys operate correctly so that you can publish them with confidence.

Only test profiles can enter a journey in test mode. You can either create new test profiles or turn existing profiles into test profiles. Learn more about test profiles in this section.

To use the test mode, follow these steps:

1. To activate the test mode, click the Test mode button, located in the top right corner.

   

2. If the journey has at least one Wait activity, set the Wait time parameter to define the time that each wait activity and event timeout will last in test mode. The default time is 10 seconds for waits and event timeouts. This will ensure that you get the test results quickly.

   

   NOTE

   When a reaction event with a timeout is used in a journey, the wait time default and minimum value is 40 seconds. See this section.

3. Use the Trigger an event button to configure and send events to the journey.

   

4. Configure the different fields expected. In the Profile Identifier field, enter the value of the field used to identify the test profile. It can be the email address, for example. Make sure to send events related to test profiles. See this section.

   

5. After the events are received, click the Show log button to view the test result and verify them. See this section.

   

6. If there is any error, deactivate the test mode, modify your journey and test it again. Once tests are done, you can publish your journey. See this page.

Important notes

• In test mode, you can only fire events using the interface. Events cannot be fired from external systems using an API.
• Only individuals flagged as “test profiles” in the Real-time Customer Profile Service are allowed to enter the tested journey. Refer to this section.
• The test mode is only available in draft journeys that use a namespace. Test mode needs to check if a person entering the journey is a test profile or not and thus must be able to reach Adobe Experience Platform.
• The maximum number of test profiles than can enter a journey during a test session is 100.
• When you disable the test mode, it empties the journeys from all people who entered it in the past or who are currently in it. It also clears the reporting.
• You can enable/disable the test mode as many times as needed.
• You cannot modify your journey when the test mode is activated. When in test mode, you can directly publish the journey, no need to deactivate the test mode before.
• When reaching a split, the top branch is always chosen. You can reorganize the position of the split branches if you want the test to choose a different path.
• To optimize performance and prevent obsolete resource usage, all journeys in test mode that have not been triggered for a week will switch back to the Draft status.
• Events triggered by the test mode are stored in dedicated datasets. These datasets are labelled as follows: JOtestmode - <schema of your event>
• When testing journeys that include multiple events, you must trigger each event in sequence. Sending an event too early (before the first wait node finishes) or too late (after the configured timeout) will discard the event and send the profile to a timeout path. Always confirm any references to event payload fields remain valid by sending the payload within the defined window
• Make sure the journey’s configured choose start and end dates/time window includes the current time when initiating test mode. Otherwise, triggered test events are silently discarded.

Trigger your events

Use the Trigger an event button to configure an event that will make a person enter the journey.

Prerequisites

As a prerequisite, you must know which profiles are flagged as test profiles in Adobe Experience Platform. Indeed, the test mode only allows these profiles in the journey.

The event must contain an ID. The expected ID depends on the event configuration. It can be an ECID or an email address for example. The value of this key needs to be added in the Profile Identifier field.

If your journey fails to enable test mode with error ERR_MODEL_RULES_16, ensure the event used includes an identity namespace when using a channel action.

The identity namespace is used to uniquely identify the test profiles. For example, if email is used to identify the test profiles, the identity namespace Email should be selected. If the unique identifier is the phone number, then the identity namespace Phone should be selected.

Event configuration

If your journey contains several events, use the drop-down list to select an event. Then, for each event, configure the fields passed and the execution of the event sending. The interface helps you pass the right information in the event payload and make sure the information type is correct. The test mode saves the last parameters used in a test session for later use.

The interface allows you to pass simple event parameters. If you want to pass collections or other advanced objects in the event, you can click on Code View to see the entire code of the payload and modify it. For example, you can copy and paste event information prepared by a technical user.

A technical user can also use this interface to compose event payloads and trigger events without having to use a third-party tool.

When clicking the Send button, the test begins. The progression of the individual in the journey is represented by a visual flow. The path progressively turns green as the individual moves across the journey. If an error occurs, a warning symbol is displayed on the corresponding step. You can place the cursor on it to display more information about the error and access full details (when available).

When you select a different test profile in the event configuration screen and run the test again, the visual flow is cleared and shows the path of the new individual.

When opening a journey in test, the displayed path corresponds to the last test executed.

Test mode for rule-based journeys

The test mode is also available for journeys that use a rule-based event. For more information on rule-based events, refer to this page.

When triggering an event, the Event configuration screen allows you to define the event parameters to pass in the test. You can view the event ID condition by clicking the tooltip icon in the top right corner. A tooltip is also available next to each field that is part of the rule evaluation.

Test mode for business events

When using a business event, use the test mode to trigger a single test profile entrance in the journey, simulate the event and pass the right profile ID. You have to pass the event parameters and the identifier of the test profile that will enter the journey in test. In test mode, there is no “Code view” mode available for journeys based on business events.

Note that when you first trigger a business event, you cannot change the business event definition in the same test session. You can only make the same individual or a different individual enter the journey passing the same or another identifier. If you want to change business event parameters, you must stop and start again test mode.

View logs

The Show log button allows you to view the test results. This page displays the journey’s current information in JSON format. A button allows you to copy entire nodes. You need to manually refresh the page to update the journey’s test results.

The number of individuals (technically they are called instances) currently inside the journey are displayed. Here is useful information that is displayed for each individual:

• Id: the individual’s internal ID in the journey. This can be used for debugging purposes.
• currentstep: the step where the individual is at in the journey. We recommend adding labels to your activities to identify them more easily.
• currentstep > phase: the status of the individual’s journey (running, finished, error or timed out). See below for more information.
• currentstep > extraInfo: description of the error and other contextual information.
• currentstep > fetchErrors: information on fetch data errors that occurred during this step.
• externalKeys: the value for the key formula defined in the event.
• enrichedData: the data that the journey has retrieved if the journey uses data sources.
• transitionHistory: the list of steps that the individual followed. For events, the payload is displayed.
• actionExecutionErrors : information on the errors that occurred.

Here are the different statuses of an individual’s journey:

• Running: the individual is currently in the journey.
• Finished: the individual is at the end of the journey.
• Error: the individual is stopped in the journey because of an error.
• Timed out: the individual is stopped in the journey because of a step which took too much time.

When an event is triggered using the test mode, a dataset is automatically generated with the name of the source.

The test mode automatically creates an Experience Event and sends it to Adobe Experience Platform. The name of the source for this experience Event is “Journey Orchestration Test Events”.