Create a journey

Last updated 10/05/2026

This article describes how to create a journey.

Basic information

• Journey name: Up to 80 characters.

• Journey group: Select or create a journey group to make journeys easier to manage.

• Journey timezone: If your project has multiple timezones enabled, you can select the timezone in which the journey runs. The selected timezone affects:

  • All times configured in journey nodes, which are in the specified timezone (such as the journey start/end time and waiting until a specified time).
  • The calculation timezone of data assets such as cohorts and tags that can be used in entry nodes, profile check nodes, and profile split nodes, which must be the same as the journey timezone.
  • The timezone used to settle journey data statistics reports.

Node components

Entry Node

Each journey has exactly one entry node. Depending on the usage scenario, three entry methods are supported: scheduled one-time entry, scheduled recurring entry, and behavior-triggered entry.

Entry method	Description
Scheduled one-time entry	Creates a journey that runs once and selects users to enter the journey at a fixed time.
Scheduled recurring entry	Creates a journey that runs repeatedly and selects users to enter the journey according to a fixed periodic execution rule.
Behavior-triggered entry	Users enter the journey after completing specified behaviors. Three behavior patterns are supported: Complete A, Completed A then B, and Completed A but not B.

Scheduled one-time

Field	Description
Entry Time	The time when the target users start entering the journey. It can't be earlier than the current time.
End Time	When the journey end time is reached, all users still in the journey exit it. After the journey ends, it cannot go online again.
Audience	Customize the audience conditions for target users or select an existing cohort in the project. By default, target users are calculated half an hour before the journey entry time.

Data asset usage notes

Cohorts or tags referenced in custom audience conditions must meet the following requirements:

• The asset timezone is the same as the journey timezone
• The asset entity is #user_id

Cohorts and tags used in entry nodes, profile check nodes, and profile split nodes of a journey must all meet the above requirements. This is not repeated below.

Scheduled recurring entry

Field	Description
Entry Time	Users enter the journey on schedule within a period according to the periodic rule you set. The time when users start entering the journey can't be earlier than the current time.
End Time	When the journey end time is reached, all users still in the journey exit it. After the journey ends, it cannot go online again.
Audience	Customize the audience conditions for target users or select an existing cohort in the project. By default, target users are calculated half an hour before the journey entry time.

Behavior-triggered entry

Field	Description	Rule description
Entry Time	Users who meet the behavior conditions within the entry period can enter the journey.
End Time	When the journey end time is reached, all users still in the journey exit it. After the journey ends, it cannot go online again.
Entry Condition	Three behavior patterns are supported: Complete A, Completed A then B, and Completed A but not B. Complete A supports Accumulatively completed, Each time continuously completed, and Each time completed in turn.	Accumulatively completed: Each time the user cumulatively completes the set behavior condition, the user meets the condition for one entry. For example, if the condition is Purchases greater than 10 within the period, the 11th, 12th, and 13th purchases within the period each trigger an entry. Each time continuously completed: The user enters the journey after completing an event consecutively within the statistical period without doing another event in between. For example, failing a challenge 5 times in a row without succeeding in between. Each time completed in turn: The user meets the entry condition after completing a specified behavior sequence. For example, completing registration - campaign participation - payment within 30 min in order within the statistical period. You can add associated properties, sequence time window limits, step blacklist limits, and more.
Audience	Whether to filter users who meet the entry condition by user profile. If filtering is needed, add audience conditions. After you set them, you can view & adjust the update frequency of the target cohort above the conditions.	The following conditions support real-time calculation: The audience conditions only use user properties and cohorts that Support Real-time Calculation User properties that support real-time calculation: properties whose definitions do not include user tags or dimension tables that are unavailable in real time Cohorts that support real-time calculation: cohorts whose size does not exceed the specified limit (2 million users by default) Note: If a scheduled cohort is referenced in a real-time audience, the latest update result of that cohort is used each time to determine the target users.

When you select scheduled recurring entry or behavior-triggered entry, you can set entry control rules.

Rule	Description
Entry Control	You can set: The maximum number of times a user can enter the journey within the journey period (for example, each user can enter the journey only once). The maximum number of pushes a user can receive within X days (for example, once within 7 days, which means only once within the last 7*24 hours). The maximum number of pushes a user can receive per X days / week / month (for example, once per week, which means only once within each calendar week).
Concurrent Entry	Whether a user can enter again on arrival if the user's previous entry has not yet exited the journey.

Action Node

Supported operation actions include Webhook delivery, push notifications, WeChat subscription messages, and KaKaoTalk - Brand Message.

Webhook delivery

Field	Description
Push Channel	Select a custom webhook channel that is enabled in the project. Note that if the channel's send ID cannot be used for real-time calculation, the channel cannot be used in journeys.
Push Content	Fill in the push content based on the custom content template. You can insert user properties to push personalized content.
Delivery Caps	Delivery caps are controlled at the channel level. When a channel is used by multiple operation tasks or journeys, you can enable delivery caps to limit, at the channel level, how many times a recipient can be reached within a period of time.
Do Not Disturb Control	When a user reaches the delivery node during the do-not-disturb period, you can choose to discard the push or wait until the do-not-disturb period ends and then continue the push.
Flow Methods	Direct flow: Users flow directly to the downstream node. By push result: Determines whether the push succeeded. Users whose push succeeded and users whose push did not succeed (including cases where the push was not executed because of delivery cap or do-not-disturb filtering, empty send ID filtering, and other reasons) are routed to different branches.
Send Test	You can run a Send Test on the push content to verify how the content is displayed.

Push Notification

Field	Description
Push Channel	Select a push message channel that is enabled in the project.
Push Content	Fill in the push content based on the custom content template. You can insert user properties to push personalized content.
Delivery Caps	Delivery caps are controlled at the channel level. When a channel is used by multiple operation tasks or journeys, you can enable delivery caps to limit, at the channel level, how many times a recipient can be reached within a period of time.
Do Not Disturb Control	When a user reaches the delivery node during the do-not-disturb period, you can choose to discard the push or wait until the do-not-disturb period ends and then continue the push.
Flow Methods	Direct flow: Users flow directly to the downstream node. By push result: Determines whether the push succeeded. Users whose push succeeded and users whose push did not succeed (including cases where the push was not executed because of delivery cap or do-not-disturb filtering, empty send ID filtering, and other reasons) are routed to different branches.
Send Test	You can run a Send Test on the push content to verify how the content is displayed.

WeChat subscription message

Field	Description
Push Channel	Select a WeChat subscription message channel that is enabled in the project.
Push Content	Fill in the push content based on the custom content template. You can insert user properties to push personalized content.
Delivery Caps	Delivery caps are controlled at the channel level. When a channel is used by multiple operation tasks or journeys, you can enable delivery caps to limit, at the channel level, how many times a recipient can be reached within a period of time.
Do Not Disturb Control	When a user reaches the delivery node during the do-not-disturb period, you can choose to discard the push or wait until the do-not-disturb period ends and then continue the push.
Flow Methods	Direct flow: Users flow directly to the downstream node. By push result: Determines whether the push succeeded. Users whose push succeeded and users whose push did not succeed (including cases where the push was not executed because of delivery cap or do-not-disturb filtering, empty send ID filtering, and other reasons) are routed to different branches.
Send Test	You can run a Send Test on the push content to verify how the content is displayed.

Decision Node

Includes profile check and behavior check nodes.

Profile Check

Field	Description	Rule description
Target Audience	Determines whether users flowing into the node meet the profile conditions based on user properties, behaviors, and more. After you set the conditions, you can view & adjust the update frequency of the profile cohort above the conditions.	The cohort update rules are the same as those in Behavior-triggered entry - Audience.
Estimated number of users	When your audience conditions use scheduled calculation, you need to estimate the target audience size. By default, profile check is available when the estimated number of users is less than 2 million.
Flow Methods	Options: All: Users who meet the conditions and users who do not are routed to different downstream branches. Meet: Only users who meet the conditions flow on, and users who do not are filtered out. Not Meet: Only users who do not meet the conditions flow on, and users who do are filtered out.

Behavior Check

Rule	Description	Rule description
Event Rules	Determines whether users complete the specified behavior conditions within a time window after flowing into the node. Three behavior patterns are supported: Accumulatively completed, Continuously Completed, and Completed in turn.	Accumulatively completed: Determines whether the user cumulatively completes the set behavior condition within the window. For example, if the condition is participating in campaigns at least 2 times within the window, the user flows on as meeting the condition after participating in campaigns twice. Continuously Completed: Determines whether the user completes an event consecutively within the window without doing another event in between. For example, if the user fails a challenge 5 times in a row without succeeding in between, the user flows on as meeting the condition. Completed in turn: Determines whether the user completes the specified behavior sequence within the window. For example, if the user completes campaign participation - payment initiation - payment completion in order within the window, the user flows on as meeting the condition. You can add associated properties, sequence time window limits, step blacklist limits, and more.
Flow Methods	Options: All: Users who meet the conditions and users who do not are routed to different downstream branches. Meet: Only users who meet the conditions flow on, and users who do not are filtered out. Not Meet: Only users who do not meet the conditions flow on, and users who do are filtered out.

Control Node

Control nodes control when and how users flow on. Splitting by profile, splitting by behavior, A/B split, and wait control are supported.

Profile Split

Field	Description	Rule description
Branch Rule	You can choose to enter by priority or enter by matched conditions.	Enter by Priority: Branches on the left have higher priority than branches on the right. Enter by matched conditions: When a user meets the conditions of multiple branches, the user enters all of those downstream branches at the same time.
Target Audience	Determines whether users flowing into the node meet the profile conditions of each branch based on user properties, behaviors, and more. After you set the conditions, you can view & adjust the update frequency of each branch cohort above the conditions.	The cohort update rules are the same as those in Behavior-triggered entry - Audience. Up to 20 branch conditions are supported.
Estimated number of users	When the branch audience conditions use scheduled calculation, you need to estimate the target audience size. By default, branch profile check is available when the estimated number of users is less than 2 million.
Fallback Branch	Whether users who do not meet any branch condition flow into the fallback branch. If it is not enabled, users who do not meet any branch condition are filtered out.

Behavior Control

Rule	Description	Rule description
Branch Rule	You can choose to enter by priority or enter by matched conditions.	Enter by Priority: Branches on the left have higher priority than branches on the right. Enter by matched conditions: When a user meets the conditions of multiple branches, the user enters all of those downstream branches at the same time.
Branch event rules	Determines, for each branch, whether users complete the specified behavior conditions within a time window after flowing into the node. Four behavior patterns are supported: Accumulatively completed, Continuously Completed, Completed in turn, and Has not completed.	Accumulatively completed: Determines, for each branch, whether the user cumulatively completes the set behavior condition within the window. If so, the user flows on. For example, if the condition is participating in campaigns at least 2 times within the window, the user flows on as meeting the condition after participating in campaigns twice. Continuously Completed: Determines, for each branch, whether the user completes an event consecutively within the window without doing another event in between. For example, if the user fails a challenge 5 times in a row without succeeding in between, the user flows on as meeting the condition. Completed in turn: Determines, for each branch, whether the user completes the specified behavior sequence within the window. For example, if the user completes campaign participation - payment initiation - payment completion in order within the window, the user flows on as meeting the condition. You can add associated properties, sequence time window limits, step blacklist limits, and more. Has not completed: Determines, for each branch, whether the user cumulatively completes the set behavior condition within the window. If not, the user flows on. For example, if the condition is participating in campaigns at least 2 times within 30 min, the user flows on as meeting the condition when the user has not participated in campaigns twice within 30 minutes.
Fallback Branch	Whether users who do not meet any branch condition flow into the fallback branch. If it is not enabled, users who do not meet any branch condition are filtered out.

A/B Test

Rule	Description
Experiment group settings	Splits users flowing into the node by ratio. You can add one Control Group and four Experiment Groups, and customize the group ratios.
Winning Metric	Measures the behavior conversion rate within a window after users are successfully split at the A/B split node, and compares the performance of different delivery strategies after the experiment node based on the conversion rate. You can add up to three winning metrics.
Activation Event	Once added, experiment conversion metrics are compared only for users who entered the experiment and completed the activation event within the statistical window.

Wait Control

Rule

Description

Control Type

Four time control types are supported: Wait xx minutes/xx hours/xx days (24 hours). Up to 30 days by default. Wait until a specified time x days later. Up to 30 days by default. For example, waiting until 9:00 1 day later means waiting until 9:00 tomorrow before flowing on Wait until a specified time every day/week/month. When you select by month, you can choose the last day, the penultimate day, or the third to last day of each month Wait until a specified time on a specified date. If the user arrives after the specified time, the user flows on directly

End Node

Users who flow into this node exit the journey directly.

Journey goal settings

You can set journey goals to measure whether users complete the expected behavior conversion after entering the journey. By default, up to 3 behavior conversion goals can be added.

Example scenarios for goal settings:

• In a first-purchase incentive journey for new users, you can count whether users make a payment within 1 day after registering and entering the journey.
• In a churn recall journey, you can count whether users log in within a period of time after entering the journey.

You can also select Exit the journey immediately after user achieving the goal., so that users exit the journey as soon as they complete the goal conversion and no subsequent operation actions are executed.

Test run

After the journey is created, you can click Test run. During the test run, the journey officially goes online and runs, but at delivery action nodes, the delivery action that calls the downstream API is not actually executed, and the push is treated as successful directly. With a test run, you can:

• Verify that the journey runs as expected before it officially goes online.
• Estimate the data volume of the journey after it officially goes online.

Journey operations

Add nodes

Click the Add Node button to add a node, or drag a node from the left onto the Add Node button.

Insert nodes

Hover over a connection line and click + between nodes to insert a node, or drag the node you need between two nodes.

Modify connections

Hover over a connection line and click the Modify Connection button to connect the line to another node. This lets you merge nodes.

Delete nodes

The system provides two deletion modes: to remove a single node, select Delete this node; to replan from the current node, select Delete this and subsequent nodes to clear them in a batch.

Copy nodes

Hover over a node and click Copy this node or Copy this and subsequent nodes. After you copy the current node, you can paste it at any point in the journey. After you copy the current and subsequent nodes, you can only paste them at the end of the journey.

Undo actions

If you make a mistake while building a journey, such as accidentally deleting or copying nodes or modifying node connections, click the Undo button to undo the last action instantly so that the journey can be rolled back seamlessly.

Layout direction

The journey layout is optimized with the D3 data visualization algorithm. Horizontal and vertical layouts are supported, and the layout is optimized automatically to improve the display of multiple nodes.