Skip to content

Commit 4cc92c1

Browse files
authored
Merge pull request #7292 from segmentio/contextual-journeys-payload-doc
Journey Context Private Beta
2 parents c4f6ef7 + 046f277 commit 4cc92c1

File tree

1 file changed

+146
-0
lines changed

1 file changed

+146
-0
lines changed
Lines changed: 146 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,146 @@
1+
---
2+
title: Journey Context
3+
plan: engage-foundations
4+
hidden: true
5+
---
6+
7+
[Event-Triggered Journeys](/docs/engage/journeys/event-triggered-journeys/) redefine how you orchestrate and personalize customer experiences.
8+
9+
This page explains Journey context, which can help you dynamically adapt each journey to individual user interactions, creating highly relevant, real-time workflows.
10+
11+
> info "Private Beta"
12+
> Event-Triggered Journeys is in private beta, and Segment is actively working on this feature. Some functionality may change before it becomes generally available. During private beta, Event-Triggered Journeys is not HIPAA eligible.
13+
14+
## Overview
15+
16+
Unlike traditional audience-based journeys, which rely solely on user progress through predefined steps, event-triggered journeys capture and store the details of user-triggered events. This shift allows you to access the data that caused users to reach a specific step and use it to make more precise decisions throughout the journey.
17+
18+
With journey context, you can:
19+
20+
- Split journeys based on event attributes or outcomes.
21+
- Personalize customer experiences using real-time event data.
22+
- Enable advanced use cases like abandonment recovery, dynamic delays, and more.
23+
24+
## What is Journey context?
25+
26+
Journey context is a flexible data structure that captures key details about the events and conditions that shape a customer’s journey. Journey context provides a point-in-time snapshot of event properties, making accurate and reliable data available throughout the journey.
27+
28+
Journey context stores:
29+
- **Event properties**: Information tied to specific user actions, like `Appointment ID` or `Order ID`.
30+
- **Split evaluations**: Results of branch decisions made during the journey, enabling future steps to reference these outcomes.
31+
32+
Journey context doesn't store:
33+
- **Profile traits**, which may change over time.
34+
- **Audience memberships**, which can evolve dynamically.
35+
36+
This focused approach ensures journey decisions are always based on static, reliable data points.
37+
38+
### Examples of stored context
39+
40+
Event properties are the foundation of Journey context. Examples of event properties include:
41+
42+
- **Appointment Scheduled:**
43+
- `Appointment ID`
44+
- `Appointment Start Time`
45+
- `Appointment End Time`
46+
- `Assigned Provider Name`
47+
- **Order Completed:**
48+
- `Cart ID`
49+
- `Order ID`
50+
- An array of cart contents
51+
52+
Segment captures each event’s properties as a point-in-time snapshot when the event occurs, ensuring that the data remains consistent for use in personalization, branching, and other advanced workflow steps.
53+
54+
## Using Journey context in Event-Triggered Journeys
55+
56+
Journey context provides the framework for capturing and referencing data about events and conditions within a journey. It allows Event-Triggered Journeys to dynamically respond to user behavior by making event-specific data available for decisions and actions at each step.
57+
58+
This is useful for scenarios like:
59+
60+
- **Abandonment recovery:** Checking whether a user completed a follow-up action, like a purchase.
61+
- **Customizing messages:** Using event properties to include relevant details in communications.
62+
- **Scheduling workflows:** Triggering actions based on contextual data, like the time of a scheduled appointment.
63+
64+
By incorporating event-specific data at each step, journey context helps workflows remain relevant and adaptable to user actions.
65+
66+
### Journey steps that use context
67+
68+
Journey context gets referenced and updated at various steps in an event-triggered journey. Each step plays a specific role in adapting the journey to user behavior or conditions.
69+
70+
#### Wait for event split
71+
72+
This step checks whether a user performs a specific event within a given time window. If the event occurs, Segment adds its details to journey context for use in later steps.
73+
74+
For example, a journey may wait to see if a `checkout_completed` event occurs within two hours of a user starting checkout. If the event happens, the workflow can proceed; otherwise, it may take an alternate path. The data captured includes event properties (like `Order ID`) and the results of the split evaluation.
75+
76+
#### Context split
77+
78+
This step evaluates conditions using data already stored in journey context. Based on the conditions, users are routed to different branches of the journey.
79+
80+
For example, a user who triggers an event with a property like `order_value > 100` might be routed to one branch, while other users follow a different path. The split uses attributes from journey context, like event properties or prior split outcomes, to determine the appropriate branch.
81+
82+
#### Profile data split
83+
84+
This step evaluates user traits or audience memberships to determine branching. While Segment doesn't store profile data in journey context, it complements the static data available in the journey.
85+
86+
For example, users in a premium audience can be directed to a tailored experience, while others follow the standard flow. Segment stores the results of this split in journey context for reference in later steps.
87+
88+
#### Contextual delay
89+
90+
A contextual delay introduces a wait period based on time-related data in journey context. This keeps workflows aligned with real-world events.
91+
92+
For example, a journey can wait until one hour before an `Appointment Start Time` to send a reminder email. The delay reads from journey context but doesn't add any new data to it.
93+
94+
#### Function steps
95+
96+
Function steps process data from journey context through custom logic. The output of the function gets written back to context for use in later steps.
97+
98+
For example, a function might calculate a discount percentage based on an event property, then store that value in journey context for later use. The output gets scoped to a dedicated object (`function_output`) to keep the context structured and reliable.
99+
100+
#### Send to destination
101+
102+
The send to destination step allows journey context data to be included in payloads sent to external tools, like messaging platforms or analytics systems.
103+
104+
For example, a payload sent to a messaging platform might include `Order ID` and `Cart Contents` to personalize the message. Users can select which parts of journey context to include in the payload.
105+
106+
## Context structure
107+
108+
The structure of journey context organizes event-specific data gets and makes it accessible throughout the journey workflow. By standardizing how data is stored, Segment makes it easier to reference, use, and send this information at different stages of a journey.
109+
110+
Journey context is organized as a collection of key-value pairs, where each key represents a data point or category, and its value holds the associated data. This structure supports various types of information, like event properties, split outcomes, and function outputs.
111+
112+
For example, when a user triggers an event like `Appointment Scheduled`, Segment stores its properties (like `Appointment ID`, `Appointment Start Time`) as key-value pairs. You can then reference these values in later journey steps or include them in external payloads.
113+
114+
The following example shows how journey context might look during a workflow. In this case, the user scheduled an appointment, and the workflow added related event data to the context:
115+
116+
```json
117+
{
118+
"appointment_scheduled": {
119+
"appointment_id": "12345",
120+
"start_time": "2024-12-06T10:00:00Z",
121+
"end_time": "2024-12-06T11:00:00Z",
122+
"provider_name": "Dr. Smith"
123+
},
124+
"split_decision": {
125+
"split_name": "appointment_type_split",
126+
"branch_chosen": "existing_patient"
127+
},
128+
"function_output": {
129+
"discount_percentage": 15
130+
}
131+
}
132+
```
133+
134+
This payload contains:
135+
136+
- **Event properties**: Captured under the `appointment_scheduled` key.
137+
- **Split outcomes**: Documented in the `split_decision` object.
138+
- **Function results**: Stored in the `function_output` object for use in later steps.
139+
140+
## Journey context and Event-Triggered Journeys
141+
142+
Journey context underpins the flexibility and precision of Event-Triggered Journeys. By capturing key details about events and decisions as they happen, journey context lets workflows respond dynamically to user actions and conditions.
143+
144+
Whether you're orchestrating real-time abandonment recovery, scheduling contextual delays, or personalizing messages with event-specific data, journey context provides the tools to make your workflows more relevant and effective.
145+
146+
To learn more about how Event-Triggered Journeys work, visit the [Event-Triggered Journeys documentation](/docs/engage/journeys/event-triggered-journeys/).

0 commit comments

Comments
 (0)