Skip to main content
Use Tag User steps and segments to control which users a Journey accepts. The same method works both ways: keep users out of a Journey they should never see, or send a specific group into one.

​
When to use this

Use tag-based membership control when entrance rules alone cannot express what you need:
  • Exclusion. You’re running an A/B or A/B/C test where each variant is a separate Journey, and a user must only ever receive one variant.
  • Inclusion. You want a specific group of users from one Journey, such as a random percentage or one branch of a test, to enter a different Journey.
If all variants share the same entrance signal and differ only in messaging, use a Split Branch inside one Journey instead. The split happens in a single Journey, so there are no cross-Journey lookups and no timing delays. The patterns below apply when the work must span separate Journeys.

​
How it works

Both patterns rely on the same three pieces:
  1. A Tag User step writes a tag onto the user at a known point in a Journey.
  2. A segment filters on that tag, turning it into a reusable audience.
  3. Another Journey’s entry rules either exclude that segment or enter from it.
A tag records where a user has been, so a segment can filter on it and entrance rules can act on it automatically. Audience activity also records which Subscriptions received each message, if you want to review or export that separately.

​
Exclude users from other Journeys

Use this to guarantee a user who enters one variant can never enter another. Each variant Journey tags its entrants and excludes anyone tagged by another variant, which ties the assignment to the user rather than to a schedule. Example: subscription pricing at a news publisher. Three subscription offers run at different prices. One Journey enters on a paywall_hit_3x custom event, another on a segment of free readers older than 30 days, and a third on newsletter signup. A reader can match more than one, and showing the same person two different prices is not acceptable, so each Journey tags its entrants and excludes the other two. Every variant needs its own tag, because the other Journeys are what check against it. If only A tagged its entrants, B and C could exclude anyone from A, but nothing would stop a user from entering both B and C.

​
Choosing which variant a user receives

This pattern makes the variants mutually exclusive. It does not let you decide in advance which variant a given user receives, because whichever Journey the user matches first claims them. To control the assignment, tag users into groups before the Journeys start and give each Journey its own group segment as its entrance audience: Each Journey then enters only from its own group, and the exclusion checks act as a safeguard.

​
Setup

1

Create a segment for each variant tag

Build a segment per variant, filtered on that variant’s tag, for example a segment where variant is A.
2

Add the Tag User action early in each Journey

Place the Tag User step as close to the front of the Journey as the flow allows, right after the user passes the entrance rules.
3

Wire the exclusion, based on entrance type

Segment-based entrance: Add the other variants’ tag segments to the Excluded Segment field on entry rules.Custom Event-based entrance: Entry rules cannot combine a Custom Event trigger with a segment filter. Add a Yes/No Branch as the first node after Entrance and check membership in the other variants’ tag segments. Route a match to exit with no message steps. Route no-match into the rest of the Journey.
Put the exclusion check before the first message step, not in a Journey-level exit rule. A user who matches both the entry rule and a segment-based exit rule at the same moment still completes the first step before exiting.
4

Repeat for every variant

Three variants means six directional checks: A excludes B and C, B excludes A and C, C excludes A and B.

​
Sequential scheduling

Running variants one after another (A ends, B starts, B ends, C starts) is good practice for a clean rollout, but it does not replace the tags and exclusions. If you schedule sequentially:
  • Use a hard end time on each Journey rather than “let current users finish.” A hard end stops messaging for everyone immediately. “Let current users finish” allows users already in the Journey to keep progressing after new entries stop.
  • Set the next Journey’s start time to the prior Journey’s actual end time, not just the same calendar day. A shared date with no specific start time can leave both Journeys live for the rest of the day.
  • Leave roughly 10 to 15 minutes between the end of one Journey and the start of the next, to cover the tag delay described in Timing and propagation.
Sequential scheduling adds a research tradeoff. Tell whoever reads the results, because each variant collects its users during a different period of time rather than the same period divided three ways. If anything changes between those periods, such as a promotion, a seasonal shift, or a product update, you cannot tell whether a difference in results came from the variant or from the timing.

​
Include a specific group in another Journey

Use this to send a specific group of users from one Journey into a separate Journey. Common cases:
  • Test a follow-up flow on a random percentage of an existing Journey’s users.
  • Hold back a control group from a downstream Journey so you can measure its effect.
  • Send users who took one branch of a test into a flow built for them.
A Split Branch divides users randomly. A Tag User step on the branch you care about turns that group into an audience you can target. Example: measuring a retailer’s loyalty program. To find out whether the program increases spend, the welcome Journey splits 90/10 and tags the 10% with loyalty_holdout: 2026-q3. The loyalty Journey then excludes that segment, which leaves a comparable group that never received loyalty messaging to measure against.

​
Setup

1

Add a Split Branch in the source Journey

Set the percentages you want. Split Branches support up to 20 branches with equal or custom splits, and percentages round to whole numbers.
You cannot edit a Split Branch once the Journey is live, so decide the percentages before you launch. See Split Branch for details.
2

Tag the branch you want to send forward

Add a Tag User step on that branch with a tag naming the group, for example followup: variant-b or holdout: true. Users on the other branches never get the tag, so the tag defines the group.If users can re-enter the source Journey and you need their branch assignment to stay the same, turn off Randomize on re-entry so they are not moved to a different branch.
3

Build a segment from the tag

Create a segment filtered on that tag. This segment is the audience the receiving Journey enters from.
4

Enter the receiving Journey from that segment

Point the receiving Journey’s entry rules at that segment. Allow time for the tag to be applied before the receiving Journey starts, or the first users through the split will not appear in the segment yet.

​
Remove tags when a test ends

A tag stays on the user until you remove it. When the test ends, clear it with a Tag User step that sets the value to blank. Otherwise the group keeps qualifying for the receiving Journey long after the test is over.
Put a date or test name in the tag value, such as followup: checkout-2026-q3. Tags left behind are much easier to find when the value says what the tag was for.

​
Timing and propagation

Tag changes and Custom Events process quickly, but not instantly.
  • Allow 15 minutes after a Tag action before a downstream step relies on that tag being readable in a segment.
  • Custom Events typically process within a few minutes.
For exclusion, this matters at the exclusion check. If a user’s tag from Journey A has not reached A’s segment by the moment Journey B evaluates that user, they can still enter B. It only affects users who qualify for two variants within that delay. For inclusion, it matters when users move between Journeys. Users who pass through the split just as the receiving Journey starts may not be in the segment yet, so leave a gap between tagging and that Journey’s start.

​
FAQ

​
Do I need the tag pattern if my Journeys never run at the same time?

Yes. Non-overlapping schedules stop two Journeys being live at the same time, which prevents a user entering both at once. They do not stop a user who went through A last month from matching B’s entrance criteria once B starts. Only a tag check makes exclusivity permanent rather than limited to a period of time.

​
Can I use one Split Branch instead of separate Journeys?

Yes, if all variants share the same entrance trigger and differ only in message content. The split then happens inside a single Journey, with no segment lookups and no delay.

​
How do I send only a percentage of users into a second Journey?

Add a Split Branch in the first Journey, tag the branch you want to send forward, and enter the second Journey from a segment built on that tag. See Include a specific group in another Journey.

​
What if a Yes/No Branch needs to check for more than one excluded tag at once?

Build one segment covering all the other variant tags, for example a segment matching variant is B OR variant is C, rather than stacking sequential branches. The check stays a single node, and adding a variant later means updating the segment definition instead of the branch logic.

​
How would I catch it if a small number of users end up double-tagged anyway?

Query for users carrying more than one variant tag. This is worth doing however short your scheduling gap is, because it turns an assumption you cannot easily verify into something you can check directly.

Journey actions

Wait, branch, and Tag User steps you can add to a Journey.

Journey settings

Entry rules, re-entry, and scheduling options for a Journey.

Segmentation

Build segments from tags and user properties for targeting.

Journey examples

Worked Journey walkthroughs for common messaging scenarios.