Hightouch Journeys allows you to create automated sequences of interactions and data syncs. With journeys, you can trigger campaigns, wait for certain actions or events, personalize experiences based on member attributes, and sync data to hundreds of destinations.
Hightouch Journeys are built on top of the same underlying data schema that audiences use. Additionally, the parent model used in a journey needs to be using the lightning sync engine.
Journeys also leverage syncs when you want to take some action inside of a journey such as triggering an email or sending a user into an ad campaign. You’ll want to ensure all the destinations you want to send users to are set up as well.
To create a new journey, go to the journeys overview page and click add journey in the top right corner. You’ll be prompted to select a parent model (if you’ve set up more than one) and to give your journey a name and description. Finally, click create journey.
You can also copy an existing journey rather than creating it from scratch. To make a copy,
Click Make a copy from the Journey list page
Click Make a copy from the horizontal three-dots menu in the Journey detail page
Update the journey name and description as needed, and select Create journey to save the new journey.
Copied Journeys share a Parent Model with the original Journey.
Copied journeys are automatically saved in a draft state. Make sure to review all journey details, particularly sync configurations, and make any required changes before enabling your copied journey.
After creating a new journey, you’ll land in the edit view. This is where you can add more steps or “tiles” to the journey and configure the logic for each one. At any point, you can click save changes or discard changes to create the associated action and exit the edit view. If you navigate away from this edit view with unsaved changes, those changes will be lost.
While in the edit view, you can build out your journey by dragging tiles onto the canvas from the panel on the right. Once you’ve created a new tile, you can click on it to view and edit its configuration.
Some helpful tips for interacting with the canvas in edit view:
Pan by clicking on empty space and dragging or scrolling on a trackpad
Zoom by using the +/- buttons in the top left, or pinching on a trackpad
Create a tile by dragging one onto the canvas from the library on the right
Move a tile by clicking and dragging it around the canvas
Edit a tile’s configuration by clicking on the tile
Delete a tile by hovering over it and clicking the trash icon (note: the start tile cannot be deleted)
Duplicate a tile by hovering over it and clicking the copy icon (note: the start tile cannot be duplicated)
Clean up a messy canvas by clicking the clean up icon on the top left of the canvas
Select multiple tiles by holding Shift on your keyboard while clicking and dragging around a set of tiles. Once they're selected, you can then move all of these tiles as a group, copy them, or delete them.
Members will flow through your journey according to the connections you create between tiles. To connect two tiles, click and drag starting from the circular connector on the bottom of a tile. Drag the connector on to the target tile (you should see a green outline appear) and release.
For some tiles such as “hold until” and “segment”, connections are created from smaller tiles underneath, rather than from the tile itself. You can see in the “hold until” example below how connections are created from the “rule met” and “rule not met” tiles, rather than from the yellow “hold until” tile.
Each connector dot can only have one connection coming out of it. This is to ensure journey members aren’t duplicated down multiple paths. However, you can have multiple connectors lead into the same tile, often referred to as a “merge” between journey paths.
To delete a connection, hover over the middle of a connector and you’ll see a trash can icon appear.
Journeys are evaluated on a fixed schedule. The schedule defaults to every hour, and must be greater than every 5 minutes. A journey evaluation, or journey “run”, is when Hightouch looks at the current state of the journey, pushes records through the journey until they reach a time delay, and triggers all the syncs in the journey.
To edit the schedule, ensure you’re in edit mode, locate the settings panel on the right hand side, and click Edit. You’ll see the settings drawer appear where you can choose between a regular interval or custom recurrence schedule type.
In most cases, a 1 hour interval should be sufficient. Keep in mind that the journey schedule also dictates the sync schedule, so if you want all the syncs to be triggered at a specific time of day or interval, you’ll want to set the journey schedule accordingly.
To start a journey, ensure all your changes are saved, and then press Start in the upper right. After pressing start, your journey is now live and you should see member counts appear inside each tile. If you used an interval schedule, the first run should kick off after a few seconds (you can refresh the page to check the updated counts). If you used a custom recurrence schedule, the first run will kick off at whatever time you specified.
Once the journey is live, you can pause or turn off the journey at any time by clicking the corresponding buttons in the upper right corner.
Just like Hightouch’s audience builder, the journey builder is super flexible and data-agnostic. You don’t have to necessarily run users through a journey. For b2b use cases, you can build a journey for accounts, opportunities, or workspaces. For marketplaces, you can build journeys for both merchants and consumers. For travel companies, you can build journeys based on trips or bookings. To accomplish these, you can build parent models in the schema builder that represent something other than users, and select that parent model when creating a new journey.
When the journey begins running, all members of the entry audience will enter the journey. On subsequent journey runs, any new members that have entered the audience will automatically enter the journey.
If a journey member drops out of the entry audience, they will remain in the journey. If a journey member drops out of the entire parent model, Hightouch no longer has access to that data and therefore they will exit the journey.
In the start tile, specify whether members may re-enter the journey. If the journey allows unlimited re-entries, then members are eligible to re-enter the journey after they finish. With unlimited entries, a member will re-enter if they finish the journey, drop out of the entry audience, and then re-enter the entry audience. As long as a member remains in the entry audience, they will not re-enter the journey.
Start by selecting the event that will be used as the entry criteria. Add additional properties as needed to further refine which events will trigger your journey.
Only events with a primary key defined can be used in journey entry criteria. Primary keys should be unique. In cases where they are not unique, only the first event - based on the event's timestamp - with that primary key will enter the journey.
When you start your journey, only members who perform the event after the start will enter the journey (i.e. events whose timestamps are later than the journey start time will enter the journey).
In the start tile, specify whether members may re-enter the journey. If you allow unlimited entries, then you must also determine whether the same member can be in the journey multiple times at once. If only a single entry at a time is allowed, only the first event will trigger a journey trip for that member.
When you select event-based entry for your journey, that event’s properties can be referenced in other tiles in the journey and can be used in syncs triggered by the journey.
Reference an entry event property in a sync. For example, you can send the category of the product that a user searched to your destination, so that you can reference the category name in emails.
Reference an entry event property in a segment tile. For example, if users enter your journey after making a purchase, you can send them down different branches depending on the category of the product they purchased.
Compare event properties to entry event properties in a segment tile. For example, if users enter your journey after adding items to their carts, you can send them down different branches depending on whether they've added to cart or purchased other products with the same category in the past.
Compare event properties to entry event properties in a hold until tile. For example, you can hold a user in a this node until they purchase a product in the category that matches the category of a search that triggered their entry into a journey.
Exit criteria allow you to define global criteria to identify users who should immediately exit your journey regardless of which step they’re currently on. Use exit criteria to remove users from journeys when they take a key action (e.g. make a purchase) or their attributes change (e.g. opt out).
This tile encompasses all the “actions” that you might want to take from within a Hightouch Journey such as triggering a campaign, sending users to ad platforms, updating records in a database, or sending records to any of our 250+destination integrations.
After dragging a “send to destination” tile onto the canvas, you can click the tile to open the configuration drawer, and click Add sync to add a new sync. You’ll be prompted to save your work before jumping into the sync configuration process.
You’ll notice one additional piece of sync configuration that is specific to journey syncs: specifying whether your sync is a “trigger” or “cohort” sync. The basic difference is:
Trigger syncs allow for the same parent model record (same user) to be synced multiple times without ever worrying about “removing” a record from the sync. This is useful if you have a sync that’s triggering a campaign in your email tool and you’ve enabled “unlimited entries” in the start tile. Thus when a record re-enters the journey, Hightouch will be able to trigger the campaign again.
Cohort syncs will ensure records are never duplicated in the downstream destination. These should be used when syncing into a segment/cohort object and you care about maintaining the right group of records in the destination. When choosing this option, you’ll additionally need to specify when, if ever, Hightouch should remove records from the destination cohort.
Review our best practices for selecting sync configurations.
This tile is used to hold records for a specified period of time in minutes, hours, days, weeks, months, or years. Because journeys run on a schedule, the time delay should be greater than or equal to your journey schedule to ensure that members progress through the journey as expected.
This tile is used to hold records until they perform a specific action or event. You also need to specify a maximum hold duration after which, if the event hasn’t been performed, the record goes down the “rule not met” branch. This tile is useful if you want to take some action immediately following the event/action you’re waiting for.
As you can see in the image below, you can further filter down the event of interest if you’re waiting for an event with specific properties.
This tile is used to split journey members based on any data you have available. Mutual exclusivity is automatically enforced between the segments you create here, meaning that a record can only ever fall into one segment. A catch-all “everyone else” segment is also created automatically so that you can specify what to do with members who don’t qualify for any of the created segments.
To create a new segment, click Add segment in the top right of the tile’s configuration drawer. Once created, you can specify which members should fall into this segment using a similar interface as the audience builder. To change the name of the segment, click one of the pencil icons at the top of the configuration drawer. At the bottom of the drawer you have the option to save changes, discard changes, or delete the segment.
Once you’ve created segments, they can be reprioritized by using the arrows on the left, or dragging/dropping using the handle. To jump back into a segment and edit it, you can click Edit or click on the segment name on the canvas.
This tile enables you to randomly assign members to different split groups within your journey, unlocking the ability to run A/B or multivariate testing. You can create as many split groups as needed (with a minimum of two), each with its own weight and name. For even more advanced testing, you can chain multiple A/B Split tiles together to set up multivariate experiments. Consistency is automatically maintained, ensuring that each record is always assigned to the same group on subsequent runs.
To create a new split, click Add A/B Split in the top right of the tile’s configuration drawer.
Once created, you can specify split percentages (weights), edit group names, or add/remove split groups. The sum of all weights must be 100 and group names must be unique within the split.
Once a journey is live you have the option to pause it or turn it off, both of which can be found in the upper right corner.
When turning off a journey, you’ll be presented with two options:
Allow existing members to complete the journey while closing it to new entries
Hard stop and remove all members immediately (note: hard stopping a journey will take a few moments to complete and the journey may briefly appear as “paused”)
When a journey is stopped, you have the option to reset it.
Resetting a journey will clear out all internal state, making it behave as if you've never run the journey before. All entry history will be cleared and all syncs will be reset.
Journeys can only be edited when in the “Paused”, “Draft”, or “Off” state. If you’d like to edit a live journey, you must first pause it.
When editing a paused journey that has members inside of it, members will remain in their current tile and proceed in the new journey once resumed. If you delete a tile with members in it, those members will be removed from the journey.
Once you’ve launched your journey, the performance tile allows you to monitor the progress of your journey.
The Entire journey section contains overall user counts for your journey as well as counts of unique users. These counts correspond to the entire history of the journey, unless you reset the journey in which case the counts reset to zero.
In progress: users are currently in one of the journey tiles.
Entered: users who have ever entered this journey.
Met exit criteria: users who qualified out of the journey, at any step, due to your exit criteria.
Finished: users who completed the journey in full.
Select a tile to view counts for a specific node.
Currently in tile: users currently in this tile. Note: in practice, this count is typically 0 except for time delay tiles and hold until tiles.
Entered tile: users who have ever entered this tile.
Met exit criteria: users who exited this tile (and journey) after meeting global journey exit criteria.
Advanced from tile: users who exited this tile and proceeded to the following tile. For segment, A/B split, and hold until tiles, the aggregate count is available, as well as a breakdown of counts by each branch of the node. Toggle to see segment percentages.
Click any count to view the users in more detail. The drawer shows the 100 random profiles of users who meet the filter criteria. Click a specific user to view all attributes.
The Journeys system creates tables in your data warehouse to enable journey observation, reporting, and debugging.
Each journey has two individual tables created in the HIGHTOUCH_PLANNER schema, where journey_id in the naming scheme is the UUID of the journey with the dashes removed.
JOURNEY_LOG_<journey_id>: this table logs the progress of all rows through a given journey.
This table is actually used as part of Journey execution, so while it’s safe
to read from it to do analysis, please do not insert, update, or delete
to/from it, since this might cause the Journey to behave in unexpected
ways.
JOURNEY_METADATA_<journey_id>: this table can be used to rebuild the journey graph and to access your node names for easier reporting.
Additionally, two global views are available in hightouch_audit that contain a comprehensive view of all of a workspace’s journeys in the warehouse, giving customers a single read-only point to monitor their journeys. These tables have the same schema as their underlying tables in addition to a reference to the source table that the row came from. We recommend that you use these global views rather than the individual journey_log and journey_metadata tables for your warehouse reporting.
The JOURNEY_LOG_<journey_id> logs the progress of all rows through a given journey.
Each time a row enters the journey, moves from one node to another, or exits the journey, we create an entry in the log table. Note that since a row can enter a journey more than once, we also have a ROW_INSTANCE_ID column on the table, which is used to uniquely identify each time a row enters the journey. That instance ID will be consistent for that particular instance of the row as it moves through the journey.
Note that resetting a journey will clear the log table.
Column
Type
Description
row_id
string
The primary key from the journey’s parent model that this row represents.
row_instance_id
string
A UUID to uniquely identify a row_id each time it enters the journey.
run_id
string
The ID of the journey run that executed this operation. This is an internal detail.
from_node_id
string
The ID of the node that this action originates with. For moves or exits, it’s the node that the row moved or exited from. For enters, it’s NULL.
to_node_id
string
The ID of the node that this action targets. For moves and enters, it’s the node the row moved into. For exits, it’s NULL.
timestamp
timestamp
The effective timestamp of this operation. Note that this does not always represent the actual time the operation occurred - for example, if a user moved from one node to another due to an event, this will be the timestamp of the event rather than the timestamp we actually ran the warehouse query.
event_type
string
What type of event this log line represents. One of moved-to-node, entered-journey, exited-journey-by-criteria, or exited-journey.
The JOURNEY_LOG_VIEW_<workspace_slug> view shows the progress of all rows in all journeys.
Each time the journey is added or removed from your workspace, this view is updated.
Column
Type
Description
source_table
string
The name of the table this row came from: journey_log_<journey_id>.
row_id
string
The primary key from the journey’s parent model that this row represents.
row_instance_id
string
A UUID to uniquely identify a row_id each time it enters the journey.
run_id
string
The ID of the journey run that executed this operation. This is an internal detail.
from_node_id
string
The ID of the node that this action originates with. For moves or exits, it’s the node that the row moved or exited from. For enters, it’s NULL.
to_node_id
string
The ID of the node that this action targets. For moves and enters, it’s the node the row moved into. For exits, it’s NULL.
timestamp
timestamp
The effective timestamp of this operation. Note that this does not always represent the actual time the operation occurred - for example, if a user moved from one node to another due to an event, this will be the timestamp of the event rather than the timestamp we actually ran the warehouse query.
event_type
string
What type of event this log line represents. One of moved-to-node, entered-journey, exited-journey-by-criteria, or exited-journey.
The JOURNEY_METADATA_VIEW_<workspace_slug> view contains the positions of the nodes across all journeys in the workspace and the customer-defined names of those nodes.
Each time the journey runs, this view is updated.
Column
Type
Description
source_table
string
The name of the table this row came from: journey_log_<journey_id>.
journey_id
text
The id of the journey.
journey_name
text
The customer-defined name of the journey.
node_name
text
The customer-defined name of the node.
node_id
text
The ID of the journey node.
to_nodes
text[]
An array of the outbound node ids from the given node.
If your entry audience is inside of a priority list, the priority will be respected when determining who should enter the journey. For example, if your entry audience, Audience B, is prioritized underneath Audience A, and user 1 meets the criteria for both audiences, the user will only fall into Audience A. This means they will not enter the journey until they drop out of Audience A (while remaining in Audience B).
It’s worth noting that all syncs in a journey get triggered at the same time (at the end of each journey run). So if you have two back-to-back sync tiles without any time delay between them, a record could be synced to both destinations at the same time. If you want to ensure some sequencing, a time delay is needed.
Use these guidelines to choose the optimal sync settings for your journey.
Trigger Mode, like the name implies, is usually used for triggered sends such as email or SMS campaigns. Trigger mode typically works best with insert mode to ensure that members don't receive the same message multiple times. In trigger mode, members are never removed from destinations.
Sync Mode
Trigger Mode Journeys
Insert
Recommended
Members who enter or re-enter a tile during a given journey run are synced to the destination
Changes to members who have previously synced to the destination are ignored
Upsert
Not Recommended: syncs are triggered for new and updated members, which can lead to duplicate triggered sends
Members who enter the tile will be synced to the destination
Changes to any member who has ever synced to the destination are synced to the destination
Update
Not Recommended: syncs are triggered for updated members, which can lead to duplicate triggered sends
Changes to any member who has ever synced to the destination are synced to the destination
New members entering the node will only sync to the destination if the member already exists in the destination
All
Not Recommended
All members who have ever passed through the send to destination tile are synced every time the journey runs
Diff
Not Recommended
One file is sent for each operation. Any member who entered the node, has changed, or removed is synced to the destination.
Cohort Mode is usually used for audiences, lists, or any behavior where members should only appear in the destination once. Cohort mode works best with upsert and all sync configurations. When configuring delete behavior, syncs should not be set to do nothing for cohort mode syncs.
Sync Mode
Cohort Mode Journeys
Cohort Removal Behavior
Upsert
Recommended
New members entering the tile during a given journey run will sync to the destination
Changes to members already in the destination will sync
Members will be removed from the destination based on the journey configuration
Update
Not Recommended
Changes to members already in the destination will sync
New members entering the node will only sync to the destination if the member already exists in the destination
Members will be removed from the destination based on the journey configuration
Usually deleteMode for update syncs is set to clear, meaning the member remains in the destination but with all attributes cleared.
Insert
Not Recommended because removal configurations aren't respected
New members entering the node are synced to the destination
Members who are changed or removed are ignored
No removal will occur, regardless of Journey settings
All
Recommended when the members in the destination should exactly match the members in the journey
No diff is performed. All members who have ever passed through the send to destination tile and not met removal criteria are synced to the destination
Members will be removed from the destination based on the journey configuration
Diff
Not Recommended
One file is sent for each operation. Any member who entered the node, has changed, or removed is synced to the destination.
No removal will occur, regardless of Journey settings
Ready to get started?
Jump right in or a book a demo. Your first destination is always free.