Skip to main content
Journeys

Journey best practices

Build journeys that reach the right people at the right time and lead them to one clear goal.

Written By Bruno

Last updated 30 minutes ago

Overview

A good journey moves people toward one outcome, such as a first request, a paid plan, or a return visit. It sends fewer, better-timed messages, mixes email with in-app messages, and stops as soon as a person reaches the goal.

Use these practices when you plan a new journey or improve a live one. For the steps to build one, see Creating a journey.


Start with one goal

Decide what a person should do before you add the first block. The user creates a request within 14 days gives you a clearer journey than Users learn the product.

Turn on Track a goal in the journey settings and set Reach the goal within (days after entering) to a realistic time. Then turn on Exit on goal, so people who convert stop getting messages that no longer apply to them.

The goal also powers the Goal tab in journey reports and the results of split tests. Without a goal, you can see who received a message, but not whether the journey worked.


Control who enters

Keep the audience narrow

Add audience rules to the Entry block so only people who can act on the journey enter. For example, a trial journey should include only companies on the trial plan.

Add exit rules for the opposite case. People leave as soon as they match an exit rule, and a person who matches one cannot enter. For a trial journey, an exit rule such as plan is not trial removes people who upgrade or cancel.

Decide who enters at publish

When you publish a journey that starts on audience rules or a date, choose Who can enter:

  • Only people who qualify from now on - Only people who start to match after you publish enter. Use this for onboarding and other journeys that should start at a moment in a person's lifecycle

  • Everyone who currently qualifies - Everyone who matches now enters too. Use this for a one-time campaign to your existing base

Journeys with an event or page trigger always count only events and visits after you publish.

Tip: Before you choose Everyone who currently qualifies, use 'Preview as…' with a few real people to check that the audience rules match only the people you expect.


Mix email and in-app messages

Email reaches people when they are away from your product. In-app messages (chats, banners, surveys, product tours, and posts) reach people only while they are online in your product, and they need the Messenger on your site.

Use the paths of each block to combine both channels:

  • In-app first, email as fallback - Show a banner or chat, then connect its If not online after… path to an email for people who did not come online in time. The In-app launch with email fallback template uses this pattern

  • Email first, in-app follow-up - Send an email, then show an in-app message when the person returns to your product

Set the in-app timeout on each block to match your audience. People who use your product daily can have a short timeout, such as 3 days. For occasional users, keep the default of 30 days or move them to email sooner.

Product tours show on desktop web only. Give people who use only your mobile apps a different path, such as an email with a link.


Give people time to act

Add a Wait before a Rule that checks engagement. A rule that checks whether people opened an email right after it was sent finds almost nobody, and the editor warns you about it.

For checks that can come true later, choose Keep checking for a while in the rule. People move on as soon as they match, and everyone else takes the else path when the time runs out.

Send messages when people are likely to read them:

  • Set a Send window in the journey settings, such as office hours. People still enter at any time; their messages wait for the window

  • Use Person’s time zone for waits and custom send windows when your audience is in many time zones. Office hours always use your workspace time zone


Start from a proven pattern

Each of these patterns has a template that you can use as a starting point. Replace the placeholder content and check the rules before you publish.

Onboard new users

Send a welcome email when a user is first seen. Then branch on whether they opened it: send a next-step email to people who opened and a shorter nudge to the others. Set the goal to the first useful action, such as creating a request. Template: Welcome new users.

Convert trials to paid

Start when a company is on the trial plan. Show the core value on day one, check a few days later whether the user clicked through, and send a reminder before the trial ends. Use the plan change as the goal, with Exit on goal on. Template: Trial to paid.

Win back inactive users

Reach users with no activity for 30 days and show what changed while they were away. Tag people who do not respond, so you can find them later. Set the goal to being active again. Template: Win back inactive users.


Protect your email reputation

  • Pick a Subscription for marketing emails, so people can unsubscribe from that type of email only

  • Send from your own sending domain. Opens and clicks are not tracked from the default Featurebase address, so rules that branch on them cannot work

  • Leave visitors out of email journeys. Visitors have no email address, so they leave the journey at the first Email block

  • Turn on identity verification for journeys that send email. Without it, anyone can be identified with any email in your widget

Free and new workspaces also send without open and click tracking. Tracking starts on a paid plan once the workspace is 30 days old.

People who are not verified receive at most 3 journey emails per email address per day. Further emails wait until the next day (UTC).


Test and improve

Before you publish, use 'Preview as…' to walk one person through the journey. Nothing is sent or saved. After you publish, use 'Send test' on a block to receive it yourself.

Check the report during the first days. Look for blocks with many people under Not sent or Not received, and for rules that almost nobody matches. To try a different message or timing, add a split test instead of changing the live journey for everyone.

When you change a live journey, publish the changes as a new version. You can choose whether people who are already in the journey move to it. See Managing live journeys.