Step-by-step Journey configurations for onboarding, re-engagement, abandoned cart, A/B testing, recurring sends, and event-driven workflows.
Each example below includes the recommended Journey settings and step-by-step configuration. Start with the simpler patterns (onboarding, re-engagement) and work up to more advanced workflows (recurring sends, event-driven progression, action button branching).
Use this pattern to send a welcome or onboarding sequence to new subscribers. It is also commonly referred to as a welcome campaign, welcome series, or new user campaign. The goal is to guide users toward completing a key action (finishing their profile, making their first purchase, or discovering a core feature) rather than messaging them the moment they sign up.
Journey setting
Description
Entry rules
Event-based (recommended): Use a Custom Event trigger (for example, signup_completed) so the sequence starts at a meaningful moment: when the user finishes registration.
Segment-based fallback: “User matches the segment criteria” using the “Subscribed Users” segment, future additions only. Use this if you don’t have a signup event set up.
Exit rules
They moved through the entire journey, or when the user completes the key action (for example, they exit a “has not completed onboarding” segment).
Re-entry rules
No
Content
A short sequence over the user’s first week: a welcome email on day 0, a push nudge on day 2 if they haven’t acted, and a follow-up email on day 7 as a last touch.
Journey steps
1
Immediately: Send a welcome email
The user just signed up and is likely still in your app. An email is the right first touch: it’s expected, non-intrusive, and can include more detail than a push notification. Save push for when they’ve left.
2
Wait 1 day
Give the user time to explore on their own before following up.
3
Day 2: Branch on key action completed?
Add a yes/no branch based on whether the user has completed your onboarding goal. Track this with a tag (for example, onboarding_complete = true) or segment membership.
Yes branch: Exit the journey. The user doesn’t need a nudge.
No branch: Send a push notification with a specific, actionable prompt. For example: “Finish setting up your profile” or “Make your first [action].”
4
Wait 5 days
Allow time for the push to land before sending a final message.
5
Day 7: Branch on key action completed?
Yes branch: Exit the journey.
No branch: Send a follow-up email as a last touch. Avoid messaging further. Users who haven’t engaged after a week are better candidates for a re-engagement campaign.
Use this pattern to win back users who haven’t opened your app or visited your site recently. The journey sends a series of increasingly compelling messages and exits the user as soon as they return.
Journey setting
Description
Entry rules
User’s last session is greater than 7 days; subscribed users. Consider excluding segments like paid customers if the goal is to re-engage free users.
Exit rules
They moved through the entire journey or meet certain conditions — exit when the user becomes active in your app or website.
Re-entry rules
Yes, after a certain amount of time: 7 days. Users re-enter whenever they go inactive again.
Content
Remind users to come back to your app when they haven’t opened it in a while, and entice them with rewards or discounts.
Journey steps
1
Send a push notification
Start with a push — it’s the most visible channel for re-engaging lapsed users. Use a clear, action-oriented message like “We miss you! Here’s what’s new.”
2
Wait 2 days
Give the user time to respond to the push before escalating.
3
Branch on user activity
Add a yes/no branch to check if the user has returned (for example, last session within 2 days).
Yes branch: Exit the journey. The user is re-engaged.
No branch: Send an email with a stronger incentive (for example, a discount, new content, or feature highlight).
4
Wait 3 days
Allow time for the email to drive the user back.
5
Final check
Active: Exit the journey.
Still inactive: Optionally send a final SMS or exit. Avoid further messaging — users who haven’t responded after multiple touches are unlikely to convert from more messages.
Use this pattern for time-limited promotions, sales events, or product launches. The journey builds anticipation, reminds users during the event, and creates urgency as it ends.
Journey setting
Description
Entry rules
User matches the segment criteria. Subscribed users, or a segment relevant to the promotion.
Exit rules
They moved through the entire journey or meet certain conditions. Select a segment that defines the goal (for example, users who purchased).
Re-entry rules
No — for one-off campaigns, send once.
Content
Prepare them for the event, remind them when it starts, and offer a discount or reward as it gets close to ending.
Journey steps
1
Announcement: Send a teaser message
Send an email or push announcing the upcoming promotion. Include the date, what to expect, and a reason to pay attention.
2
Wait until event start
Add a wait step timed to the start of your promotion.
3
Event start: Send the main offer
Send a push notification or email with the promotion details, discount code, or call to action.
4
Wait 2–3 days (mid-event)
Give users time to act on the initial message.
5
Reminder: Last chance message
Send a final push or email with urgency — “Sale ends tomorrow” or “Last chance for 20% off.” Users who already converted will have exited via the exit rule.
The user’s last session is greater than the amount of time.
The threshold for how long the user has been inactive in your app or website.
Audience
Include the segment you want to target with the tag.
These are the users eligible to receive the message.
Exit rules
Exit when the user no longer matches the audience conditions.
When the user leaves the segment, they are no longer eligible for the journey message.
Re-entry rules
Yes, after a certain amount of time.
The amount of time you want to wait for the user to be eligible to get the message again.
Journey steps
1
Add the desired message(s)
Choose a template for the message step. You can use push, email, SMS, or in-app depending on the action you want the user to take.
2
Set a wait node for the amount of time you want the user to wait
This can be a short or long interval depending on whether the message should repeat as a reminder. In this example, the wait is set to 104 weeks (2 years) so the message effectively sends only once — the long wait prevents the user from looping back through the journey while re-entry rules handle the next trigger.
Using a split branch node, you can set a 50/50 split within your journey. Create two different message templates and as your users flow through, half will get “Template A” and the other “Template B”.Export the message data from each template to compare analytics between variants.
This example displays 3 or more in-app messages in sequence, showing one per day. If a user does not open the app, the next message appears the next time they open it.Initial setup
1
Create a new segment
Create a segment called iam_journey with filter: User Tag iam_journey is 1
You can change iam_journey to whatever name you choose.
This tag will be set on each user that finishes the journey and gets all messages.
Configure the time window to filter for your target day of week (for example, Friday).
Users entering the journey will wait until the next matching day.
2
Add your message after the time window
Place the message node immediately after the time window so it sends when the day is reached.
3
End the journey
Let users exit after the message sends. With re-entry at 7 days, they will rejoin and repeat weekly.
Update the message content regularly to avoid sending the same copy each week.
Escalate engagement based on user progression using custom events and wait-until conditions.
Journey setting
Description
Entry rules
Custom Event = Progression_Level, with filter progression_level = 0.
Audience
Optional segment filter. You can run this for all users or restrict to a subset; no tags required.
Exit rules
- They moved through the entire journey. - Or when maximum progression level is reached (progression_level = 3). - Optionally: exit when a Wait Until node expires. - Optionally: branch from a Wait Until node to tag users who do not complete the event, leading them into a re-engagement journey.
Re-entry rules
No
Content
Stage-based messages that escalate as users complete milestones (emails in this example).
Progression journey flow
Journey steps
1
User enters the journey
All eligible users enter based on entry rules.
Trigger: Custom EventProgression_Level with progression_level = 0.
Start: Immediately.
2
Level 1
Wait until custom event Progression_Level occurs with progression_level = 1.
Send: Level 1 Complete! message.
(Optional) Apply expiration on the wait node → exit user if milestone not reached.
(Optional) Branch: if expiration hits, tag the user and send them into a re-engagement journey.
3
Level 2
Wait until custom event Progression_Level occurs with progression_level = 2.
Send: Level 2 Complete, you are doing great! message.
(Optional) Apply expiration or branch/tag to re-engagement.
4
Level 3
Wait until custom event Progression_Level occurs with progression_level = 3.
Send: You’ve reached level 3! message.
(Optional) Apply expiration or branch/tag to re-engagement.
5
Exit
End the journey once users complete Level 3, or when a Wait Until node expires.
Optionally, use branch/tag paths to route stalled users into a re-engagement track.
Schedule: Start immediately, Never stops.
This method ensures progression happens only when real engagement signals occur. Adding expiration and branch/tag logic lets you handle stalled users gracefully — either exiting them or re-routing into a re-engagement Journey.
Route users down different Journey paths based on which push notification action button they tapped. This pattern uses action buttons, a custom event, and a Wait Until step to branch users by their specific button click — not just whether they clicked or not.
This example requires website or app code to capture the button click and send a custom event. It cannot be done entirely through the OneSignal dashboard.
Journey setting
Description
Entry rules
User matches the segment criteria (for example, subscribed users or a campaign-specific segment).
Exit rules
They moved through the entire journey.
Re-entry rules
No
Content
Send a push with multiple action buttons, then branch follow-up messages based on which button the user tapped.
The built-in Yes/No branch message behavior conditions detect whether a user clicked or was delivered a message — but not which button they clicked. To branch by specific button, you capture the Action ID from the click event and send it as a Custom Event property that the Journey can branch on.
1
Add action buttons to your push
When creating the push message in the Journey (or in a template), open Advanced Options > Action Buttons and assign a unique Action ID to each button.Example: A promotional push with two CTAs:
On your website or in your app, listen for the notification click event and send a Custom Event that includes the Action ID as a property.
The Web SDK example requires version 160500 or later. Users should be logged in for custom events to be tracked.
OneSignalDeferred.push(function(OneSignal) { OneSignal.Notifications.addEventListener("click", function(event) { var actionId = event.result.actionId; if (actionId) { OneSignal.User.trackEvent("cta_clicked", { button: actionId }); } });});
OneSignal.Notifications.addClickListener { event -> val actionId = event.result.actionId if (actionId != null) { OneSignal.User.trackEvent("cta_clicked", mapOf("button" to actionId)) }}
let listener = { (event: OSNotificationClickEvent) in if let actionId = event.result.actionId { OneSignal.User.trackEvent("cta_clicked", properties: ["button": actionId]) }}OneSignal.Notifications.addClickListener(listener)
See Custom events for event requirements and limits.
3
Add a Wait Until step in the Journey
After the push message step in your Journey:
Add a Wait Until step.
Add a condition for each button: Custom Event cta_clicked where property button equals the Action ID (for example, shop_now).
Add additional conditions for each Action ID you want to branch on (for example, learn_more).
Set an expiration (for example, 3 days) so users who don’t click any button continue down a fallback path.
Users follow the branch for the first condition they meet. If no condition is met before the expiration, they follow the expiration branch.
4
Add follow-up messages to each branch
On each branch after the Wait Until step, add the appropriate follow-up message or action:
“Shop Now” branch: Send a product recommendation or discount code.
“Learn More” branch: Send educational content or a feature overview.
Expiration branch: Send a re-engagement message or exit the Journey.
You can chain multiple Wait Until steps to branch on subsequent interactions too — there is no limit on the number of Wait Until steps in a Journey.
Yes. Add a time window node as the first step and configure it for every day of the week with the hours you want the message to send (for example, 10 AM to 6 PM in the user’s time zone). Then set re-entry rules to re-enter after a time shorter than one day but longer than the time window duration — for example, 12 hours for an 8-hour window. This ensures users re-enter early enough to catch the next day’s time window without risking a double-send within the same window.
Yes. Add a split branch node to divide users evenly (for example, 50/50). Place a different message template on each branch, then compare analytics between the two templates after the Journey runs.
How do I limit how many times a user can enter a Journey?
Use a tag (for example, journey_count) to track entries. Increment the tag each time the user enters, and add an audience exclusion rule that blocks users once the tag reaches your desired limit. See the Limited entry journey example above.
Why did my recurring Journey send on the wrong day?
The time window node filters by the user’s local time zone if time zone data is available. If a user does not have time zone data, the message sends based on your app’s default time zone. Verify that your time window settings and user time zone data are correct.
Set the Journey status to Paused or Stopped in the Journey settings. Paused Journeys retain users at their current step; stopped Journeys exit all users immediately. See Journey settings for details.
