Journeys

A real-time journey is an always-on program that customers move through as their behavior changes. Travelers enter a real-time journey through their membership in a real-time segment, move through the journey’s stages–activations, waits, and splits–and leave when they meet one of the journey’s exit conditions or reach the end of their path. Every traveler’s path is recorded in a travel log.

Real-time journeys and batch journeys

Real-time journeys and batch journeys share the journey canvas and the same building blocks–activation, wait, conditional-split, percent-split, and merge nodes–but differ in when and how they run:

• A real-time journey runs continuously. Travelers enter and advance in real time as inbound events change their profiles.

• A batch journey runs on a schedule or recurrence.

Real-time journeys add a quiet-hours node, which holds travelers until a quiet window–such as overnight in the customer’s local time zone–ends, so that messages are not sent at inconvenient times. A profile collection supports up to 50 real-time journeys.

Real-time journeys deliberately do not include the batch journey’s measurement features. Goals, milestones, and conversion-rate metrics are batch-only; a real-time journey does not track them. To analyze a real-time journey, use its travel log.

How travelers enter

Travelers enter a real-time journey through real-time segment membership: a customer enters the moment they become a member of the segment that gates the journey, and the journey reacts to that entry as it happens.

To start a journey in response to a specific event–an abandoned cart, a status change–model that event as a real-time segment. Define an attribute that captures the event and a segment whose predicate tests it; the customer enters the journey the moment that event moves them into the segment. Because a real-time segment re-evaluates whenever a profile changes–on each event, and shortly after a time-based computed attribute changes–segment membership is how a real-time journey responds to “when X happens.”

How travelers leave

A traveler leaves a real-time journey in one of two ways:

• They meet an exit condition. A real-time journey’s exit conditions remove a traveler immediately when they receive an event of a given event type, join a real-time segment, or enter another real-time journey.

• They reach the end of their path. A traveler who completes the last node on their path leaves the journey.

Leaving the segment that let a traveler in does not remove them from the journey. A customer who abandons a cart and then purchases is still a traveler until an exit condition removes them, so add an exit condition for every reason a traveler should stop receiving the journey’s messages.

Re-entry and testing

A real-time journey controls whether, and how soon, a traveler can enter again:

• Re-entry allows a customer who has left the journey to enter it again the next time they join its segment.

• A cooldown–from minutes to months–sets how long after leaving a traveler must wait before re-entering.

• Linked journeys extend the re-entry check to other journeys you name, so that a customer’s recent path through a related journey is considered when deciding whether they can enter this one.

Use test mode to validate a real-time journey before it sends. In test mode, travelers move through the journey as they would in production, but activations are not sent to the destination and the journey does not write to its travel log.

The travel log

As travelers move through a real-time journey, Amperity records their paths in a travel log. The travel log holds one row for each stage a traveler enters–the start of the journey, each node, and how they left, by meeting an exit or by completing the journey. Each row records when the traveler entered the stage, so the rows for a traveler, in time order, reconstruct their path. A node’s row also records the node before it on the journey canvas; start, completion, and exit rows have none. When a traveler exits, the row captures why: the segment, journey, or event that caused the exit.

The travel log is data, not a screen in Amperity. To analyze it–who entered, how they moved, and where they left–export it to a downstream system.

Holdout and A/B testing

When a real-time journey splits travelers with a percent-split node, each traveler’s travel log rows record the percent-split node’s name as test_group_name, the path the traveler took as stage_name, and whether that path is the control as is_control. Include a control path with Include control, then compare the travelers on each path with the control path to measure the journey’s effect against the holdout.

Exporting the travel log

A real-time journey’s scheduled work is exporting its travel log. On its schedule, the journey sends new travel-log records to a configured destination, so that the data can land in a downstream system for analysis. Each run picks up the records added since the previous export.

Real-time journeys in segments

A segment’s Journey clause selects customers by their path through a journey: whether they passed through a node (Node Passed Through), when they first or last entered a node, and how many times they entered the journey (Entry Count).

Segment clauses that test whether a customer reached a goal or reached an exit do not apply to real-time journeys: real-time journeys do not track goals and exits the way batch journeys do, so those clauses return no results for a real-time journey.

A real-time journey’s travelers can’t be opened as a segment.