# Journeys **URL:** https://heroiclabs.com/docs/satori/concepts/journeys/ **Summary:** Journeys move each player through a sequence of steps on their own clock, so what a player receives next depends on where they've already been and how long ago. **Keywords:** journeys, player journeys, lifecycle, automation, orchestration **Categories:** satori, concepts, liveOps --- # Journeys Journeys lets you build personalized player flows right from the console. Think of a journey as a map of the different paths a player moves along, one that adapts as they go. For example, you can build a journey to: * **Onboard new players**: guide them through their first sessions to their first real win. * **Win back lapsed players**: reach players who have stopped playing and bring them back in. * **Unblock stuck players**: spot players failing the same level and move them past it. * **Grow spend**: offer a bigger deal each time a player buys. ## Why journeys Satori already gives you the building blocks for LiveOps with audiences, remote configs and experiments. These tools define who the player is and what they should see. Journeys answer a different question: *what happens next*. Instead of defining properties of a target group, as you would do with an audience, you design a sequence. This can be a trigger, a wait, a branch, a user action, all responding to what a player does. Take a new player. The happy path is that they're still playing a week in, and you reward them for it. What if they drift off before then? In that case, you might want to re-engage them: ```text ┌─ yes -> weekend bonus, day 7 reward new player -> wait 6 days -> engaged? └─ no -> win-back message, comeback pack ``` With journeys, you can: - Map out the whole flow in one place. No need to wire up separate campaigns. - Run the campaign on each player's own clock rather than a shared calendar. Put another way, a journey is a campaign that spans over a player's lifecycle. {{< screenshot src="/images/pages/satori/concepts/journeys/journey-editor.png" alt="The D7-Retention journey open on the canvas in the Satori console, with steps connected from entry to exit, per-step player counts, and the step panel open" caption="An example new player journey: After Day 6, any player who is still engaged gets a weekend bonus and a Day 7 reward. Anyone who isn't gets a win-back message, a comeback pack, and a last chance two days later." >}} ## How it works Journeys is a modular system built from four kinds of components, which between them control who enters, what each player receives, and when.

Entry

Sets which players start the journey, and when.

Actions

Give the player something on arrival: a message, a live event, an experiment, or a flag variant.

Delays

Hold the player until a duration elapses or a scheduled time arrives.

Conditional branches

Ask a question about the player, then send them down the path that matches.

### Entry Each journey carries one or more entry triggers, and a player who matches any one of them is admitted. {{< table name="satori.concepts.journeys.entry-triggers" >}} Two more settings shape who gets in. **Start and end times** bound the period when a journey admits anyone at all. Enable a journey before its start time and it reports as **Scheduled**, turns **Running** once the window opens, and **Terminated** after the end time passes. The **rejoin cooldown** decides what happens once a player reaches the exit. By default they never come back. Set a cooldown and they become eligible again after it elapses, which turns a one-off flow into a recurring one such as a weekly check-in. ### Actions An action gives the player something the moment they arrive, then hands them to the next step. Switch on a weekend bonus, send a day 7 reward: both are actions. Actions reach your game through the Satori systems your game already reads, so you can add a journey without shipping a client update. {{< table name="satori.concepts.journeys.step-actions" >}} ### Delays A delay holds the player in place before the next step runs. This is what puts a journey on the player's own clock rather than a shared calendar. A **Wait** step pauses for a fixed duration, counted from the moment that player arrived. A six-day wait lands on each player's own day six, not on one date for everybody. A **Time Window** step waits for a specific date instead, or for the next slot in a recurring schedule such as 9 AM every Saturday. Recurring schedules resolve in UTC or in the player's own timezone, so a step meant for Saturday morning lands on Saturday morning wherever they are. ### Conditional branches A branch asks a question about the player, then sends them down the path that matches. Did they come back? Did they buy? Which spend tier are they in? You branch on the same player properties your audiences filter on, so anything you can segment on, you can branch on. This is what lets one journey cover outcomes that would otherwise be separate campaigns. Each player only ever meets the arm that fits them. A branch can also wait for its answer instead of taking one straight away. Use that when the thing you're watching for could happen any time over the next few days: a purchase, a completed level, a return to the game. Players who never do it leave by the timeout path once the wait elapses. {{< note "important" "Give every branch a way out" >}} Delays and timeouts move a player on by themselves. Conditions depend on the player's data changing, which happens as they play and their events reach Satori, so a player who stops playing sits on a branch indefinitely. A branch that matches on something the player might never do needs a wait rather than a bare **No match** path. {{< /note >}} ## Key capabilities

Act through the configuration your game already reads	Journey actions work through feature flags, live events, and experiment phases. Your game keeps making the same Satori calls and receives different values as the player advances, so adding or changing a journey needs no client release.
Set the pace to each player's own clock	Hold a player for a fixed duration, until a specific date, or until the next occurrence of a recurring schedule, resolved in their own timezone.
Undo what an earlier step granted	A Revert Step action removes the live event, experiment phase, or flag variant a player picked up earlier in the same journey.
See where players stop	Per-step player counts sit on the canvas itself, alongside totals for active and completed players and the fastest, slowest, and average time to finish.
Explain what one player received, and why	An identity's page lists the journeys that player is in and every step they've passed through, with timestamps, so you can answer a support question without reconstructing the run from logs.
Reuse a flow inside another	An Enter Journey action enrolls the player into a second journey, so a shared sequence such as a welcome flow is written once. Journeys can't enroll into each other in a cycle.

## See next - [Build an escalating offer chain](../../guides/offer-chain/) - [Live events](../live-events/) - [Experiments](../experiments/) - [Segmentation](../segmentation/)