> For the complete documentation index, see [llms.txt](https://user.netmera.com/netmera-user-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://user.netmera.com/netmera-user-guide/omnichannel-engagement/journey-orchestration/journey-components/branch.md).

# Branch components

Reference for Branch components that route users by profile data, message response, test variant or frequency.

Branch components route users through different paths in a Journey based on specific criteria. Use them to create different experiences for users based on their profile data, previous message interactions, test variants, or how often they have passed through a Journey step.

The following Branch components are available:

* **User Branch**: Routes users based on user data and conditions
* **Check Interaction**: Routes users based on their interaction with a previous message or campaign
* **Variants**: Splits users into different test groups
* **Capping**: Controls how often users can pass through a specific point in a Journey

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2Fguiq0WByJDDa7OphEkgl%2FEkran%20Resmi%202026-09-25%2010.45.22.png?alt=media&amp;token=6e80e5f1-3542-4709-87a2-0ed69fab38bb" alt="" width="563"><figcaption></figcaption></figure>

### User Branch

User Branch allows users to follow different paths in a Journey based on conditions. Use it when the Journey should take different actions depending on information about the user.

For example, users with a **Premium** subscription can follow one path, while users with a **Standard** subscription follow another path.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2Fin3Cfn8yAhOi4v7gGM1W%2FEkran%20Resmi%202026-09-25%2010.48.30.png?alt=media&amp;token=b5c99056-c153-4271-bdf3-f8599ad3c853" alt="" width="563"><figcaption></figcaption></figure>

#### Add a User Branch

Add a **User Branch** to the Journey where users should be evaluated against specific conditions.

Each path in the User Branch has its own conditions. When a user reaches the branch, Netmera evaluates the conditions and routes the user to the corresponding path.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2Fd7vniw8VTg5HlEYq88Uj%2FEkran%20Resmi%202026-09-25%2010.46.02.png?alt=media&amp;token=2b815889-02a3-40fc-80d7-65ff8ccde8df" alt="" width="563"><figcaption></figcaption></figure>

#### Choose a condition type

Select the type of information that should be used to evaluate the user.

Available condition types include:

* **Profile Attribute**: Evaluate information stored in the user's profile
* **Segment**: Route users based on segment membership
* **Tag**: Evaluate tags assigned to the user
* **Event**: Evaluate events performed by the user

Select the condition type that matches the information that should determine the user's path.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2F3CMU5fhdsC6ieE9JYXmK%2FEkran%20Resmi%202026-09-25%2010.47.28.png?alt=media&amp;token=d93f2277-fc9e-4349-80e3-9bb66c2f3f2b" alt="" width="563"><figcaption></figcaption></figure>

#### Define the condition

After selecting a condition type, define the criteria that the user must meet.

Select an operator and specify the value for the condition.

For example:

**Subscription Level** → **equals** → **Premium**

This condition routes users whose Subscription Level is Premium to the corresponding path.

Select **Add** to save the condition.

Multiple conditions can be added to a path when more specific criteria are required.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FDGqspOL2Lxa3j80jPbTk%2FEkran%20Resmi%202026-09-25%2010.46.17.png?alt=media&amp;token=c62c2003-576d-4917-b199-c7be874f912c" alt="" width="563"><figcaption></figcaption></figure>

#### Add groups

Use groups to combine multiple conditions and create more detailed branching logic.

Select **Add Group**, then add the conditions that should be evaluated together.

Each group uses one of the following logical operators:

* **Match all conditions:** The user must meet all conditions in the group
* **Match any condition**: The user must meet at least one condition in the group

For example, a group using **Match all conditions** can route users who are both in a specific segment and have a specific profile attribute.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FoXOKZEzoGDEDeT1pwic6%2FEkran%20Resmi%202026-09-25%2010.47.06.png?alt=media&amp;token=9de6c8aa-5a3a-47c5-bf4c-432ba358754d" alt="" width="563"><figcaption></figcaption></figure>

### Check Interaction

Check Interaction allows a Journey to evaluate how users interacted with a message or campaign that was created before the Journey started.

Use this component when the next Journey step should depend on whether a user received, opened, or clicked a previous message.

For example, users who opened a previous push notification can follow one path, while users who did not open it can follow another path.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2F2m6QMIdNLLOwjHWEXrLs%2FEkran%20Resmi%202026-09-25%2010.50.38.png?alt=media&amp;token=441a08f0-72e1-4bdd-be98-c58a46cf1a33" alt="" width="563"><figcaption></figcaption></figure>

#### Configure the interaction check

Select the **Check Interaction** step to open its configuration options.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2F09Ra82xskzXdcEPXOFR4%2FEkran%20Resmi%202026-09-25%2010.49.26.png?alt=media&amp;token=6c82384e-3d44-4d2b-89b1-261a33c668c4" alt="" width="563"><figcaption></figcaption></figure>

#### Step name

Enter a meaningful name that describes the interaction being checked.

A descriptive name makes the step easier to identify when reviewing or managing the Journey.

For example:

**Opened Welcome Push**

#### Search message by name

Search for and select the message or campaign that should be checked.

The selected message determines which user interaction Netmera evaluates.

For example, select a campaign named **Welcome Push** to check whether users interacted with that campaign.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FLG0gnbvGmUweNcfsobZC%2FEkran%20Resmi%202026-09-25%2010.49.50.png?alt=media&amp;token=6fa9a7d2-90b9-4093-a6af-cbc8f744a82d" alt="" width="563"><figcaption></figcaption></figure>

#### Interaction type

Select the interaction that should determine the user's path.

Available options include:

* **Received**
* **Not Received**
* **Opened**
* **Not Opened**
* **Clicked**
* **Not Clicked**

The available interaction types depend on the channel of the selected message.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FNtSyhE0C4SCQ0e00lS7g%2FEkran%20Resmi%202026-09-25%2010.50.01.png?alt=media&amp;token=3320019f-6bd0-46e8-8a06-afd45eeddc88" alt="" width="563"><figcaption></figcaption></figure>

#### Choose the interaction type based on the channel

Use the interaction type that corresponds to the selected message channel.

<table><thead><tr><th width="253.9765625">Interaction Type</th><th>Supported Channels</th></tr></thead><tbody><tr><td><strong>Received / Not Received</strong></td><td>Available based on the selected message</td></tr><tr><td><strong>Clicked / Not Clicked</strong></td><td>Push Notifications</td></tr><tr><td><strong>Opened / Not Opened</strong></td><td>Mobile Widget, Web Widget, SMS, E-mail</td></tr></tbody></table>

For example, use **Clicked** to check whether a user clicked a Push Notification. Use **Opened** to check whether a user opened an E-mail.

#### Look back (days)

Specify how many days Netmera should check for the selected interaction.

For example, enter **7** to check whether the user performed the selected interaction within the specified 7-day period.

This allows the Journey to evaluate recent user behavior rather than checking interactions without a defined time frame.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FDNA9WLUdhgbS2is6OrlL%2FEkran%20Resmi%202026-09-25%2010.50.14.png?alt=media&amp;token=573de90e-1858-4d6c-8fd8-5630129a9b0c" alt="" width="563"><figcaption></figcaption></figure>

### Variants

Variants allows you to test different versions of a message or action within the same Journey.

Use Variants when you want to divide users into different groups and provide each group with a different experience. This can be used to compare different messages, content, designs, or actions.

For example, create two variants of a Push Notification:

* **Variant A**: Message with a discount offer
* **Variant B**: Message with a different offer

Users are distributed between the variants according to the percentages configured for each variant.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FthkVZSY3tXpGliG8sr7G%2FEkran%20Resmi%202026-09-25%2010.58.04.png?alt=media&amp;token=67c6669f-8842-4323-b46d-c5cf336d3d00" alt="" width="563"><figcaption></figcaption></figure>

#### Configure variants

Select the **Variants** step to configure the test groups and the actions users receive in each group.

#### Step name

Enter a meaningful name that describes the test.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2F0HFjyDJNXvIt5Q6xJSyW%2FEkran%20Resmi%202026-09-25%2010.57.28.png?alt=media&amp;token=60a18fc7-66be-43a9-b644-8a8f3e21597c" alt="" width="563"><figcaption></figcaption></figure>

For example:

**Push Notification A/B Test**

A descriptive name makes the test easier to identify when reviewing the Journey and its results.

#### Add variants

Select **+** to create the variants that should be tested.

Each variant represents a different version of the experience.

For example:

* **Variant A - Discount Offer**
* **Variant B - Free Shipping**

Add as many variants as required for the test.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FGP8sLZptgDqqaZ7MVqw8%2FEkran%20Resmi%202026-09-25%2010.58.30.png?alt=media&amp;token=75112f42-2222-4e9a-8b7c-d26521172535" alt=""><figcaption></figcaption></figure>

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FEcHrjzCn2JpqLFSjaFo7%2FEkran%20Resmi%202026-09-25%2011.00.15.png?alt=media&amp;token=ddd8b1c7-9b0f-46b5-8280-d18c0e9baf38" alt="" width="563"><figcaption></figcaption></figure>

#### Set distribution percentages

Define the percentage of users who should enter each variant.

Select the percentage value next to a variant and enter the required distribution.

For an equal split between two variants:

| Variant   | Distribution |
| --------- | -----------: |
| Variant A |          50% |
| Variant B |          50% |

You can also use different percentages when one variant should be shown to a smaller or larger portion of users.

For example:

| Variant   | Distribution |
| --------- | -----------: |
| Variant A |          70% |
| Variant B |          30% |

The configured percentages determine how users are distributed across the variants.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FYBszGCtzMcWqUM9tt1Fi%2FEkran%20Resmi%202026-09-25%2010.59.47.png?alt=media&amp;token=f595a542-6387-42b3-ba6d-953158ed85ce" alt=""><figcaption></figcaption></figure>

#### Define actions for each variant

Configure the message or action that users should receive after entering each variant.

Each variant can contain a different set of Journey steps.

For example:

**Variant A - Discount Offer**

Add a Push Notification with a discount-focused message.

**Variant B - Free Shipping**

Add a Push Notification with a different offer.

Different variants can also use different content, designs, or actions depending on the purpose of the test.

#### Save the configuration

After configuring the variants, distribution percentages, and actions, select **Save**.

The Variants step is then added to the Journey and can be connected to the subsequent Journey steps.

### Capping

Capping controls how often users can pass through a specific point in a Journey.

Use Capping when users should not repeatedly receive the same communication or pass through the same Journey step without a limit.

For example, a Journey can allow a user to pass through a specific message step once, or allow multiple passes with a defined waiting period and maximum number of passes.

The Capping step has two paths:

* **ON\_PASSED**: The user is allowed to continue through the capped path
* **ON\_CAPPED**: The user has reached the configured limit and is routed through the alternative path

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FYVfvrXn1xfupmzmAGhee%2FEkran%20Resmi%202026-09-25%2011.02.55.png?alt=media&amp;token=0cd11dde-b5a1-4d7c-8af1-5c063ac916f9" alt="" width="563"><figcaption></figcaption></figure>

#### Capping and Entry Rules

Capping works independently from the frequency settings configured in **Entry Rules**.

* **Entry Rules > Capping Options** determine how often a user can **enter the Journey**
* **Capping > User Eligibility Type** determines how often a user can **pass through that specific Capping step**

A user can therefore be eligible to enter a Journey while still being capped at a specific point within the Journey.

#### Add the Capping step

In Journey Builder:

1. Select **Add Step** where the capping rule should apply.
2. Under **Branch**, select **Capping**.
3. Select **Add**.

The Capping step is added with the **ON\_PASSED** and **ON\_CAPPED** paths.

#### Configure the User Eligibility Type

Select the Capping step to open the **Capping Details** panel.

Under **User Eligibility Type**, select one of the following options:

* **One Time**
* **Multiple Times**

**One Time**

Select **One Time** when each user should be allowed to pass through the Capping step only once.

The first time the user reaches the step, the user follows **ON\_PASSED**.

If the same user reaches the Capping step again, the user follows **ON\_CAPPED** instead.

When **One Time** is selected, the following fields are not displayed:

* **Lock Duration**
* **Entry Capping**

**Multiple Times**

Select **Multiple Times** when users should be allowed to pass through **ON\_PASSED** more than once.

The number and frequency of eligible passes are controlled by the configuration below.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2Fbbkol9OUYZBheiG4Inwg%2FEkran%20Resmi%202026-09-25%2011.01.02.png?alt=media&amp;token=55cf3c44-1127-46bc-b315-a06343ae53a5" alt="" width="563"><figcaption></figcaption></figure>

#### Configure the capping limits

When **Multiple Times** is selected, configure the following options:

**Lock Duration**

Defines how long a user must wait after an eligible pass before they can pass through **ON\_PASSED** again.

If the user reaches the Capping step during the lock duration, the user follows **ON\_CAPPED**.

For example, if the Lock Duration is set to 24 hours, a user who passes through **ON\_PASSED** cannot pass through the same path again for 24 hours.

**Entry Capping**

Defines the maximum number of times a user can pass through **ON\_PASSED**.

For example, an Entry Capping value of **3** allows a user to pass through **ON\_PASSED** up to three times within the applicable period.

After reaching the configured limit, subsequent attempts follow **ON\_CAPPED**.

**Specify a capping time period**

Enable this option to apply the Entry Capping limit within a recurring period.

When the configured period resets, the user's Entry Capping count is reset and the user can become eligible to pass through **ON\_PASSED** again.

**Capping Time Period**

Define how often the Entry Capping limit should reset.

The configured period determines the timeframe in which the Entry Capping limit applies.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FuIgRWqbc2xCwTLYAwnM2%2FEkran%20Resmi%202026-09-25%2011.01.41.png?alt=media&amp;token=3bf61467-5e13-4bd4-962d-bb16e209a61f" alt="" width="563"><figcaption></figcaption></figure>

#### Configure the capping paths

After configuring the Capping step, connect the subsequent Journey steps to the appropriate paths.

**ON\_PASSED**

Use this path for users who are eligible to continue through the capped point.

For example, connect it to a message or another Journey action.

**ON\_CAPPED**

Use this path for users who have reached the configured capping limit.

For example, connect it to an alternative message, another Journey action, or the end of the Journey.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2Fvl4KnQeLiHbU5yVkV8o7%2FEkran%20Resmi%202026-09-25%2011.03.56.png?alt=media&amp;token=7681d791-574c-4178-8e70-7343e50009ae" alt="" width="563"><figcaption></figcaption></figure>

#### View capping step statistics

Capping performance can be reviewed from Journey Analytics.

From the Journey list, select the **View** icon in the **Action** column to open the **Journey Analytics** page.

For a Capping step, the following metrics are available:

<table><thead><tr><th width="166.45703125">Metric</th><th>Description</th></tr></thead><tbody><tr><td><strong>Entry Count</strong></td><td>Number of users who entered the Capping step</td></tr><tr><td><strong>Pass</strong></td><td>Number of users who passed the capping rule and continued through <strong>ON_PASSED</strong></td></tr><tr><td><strong>Block</strong></td><td>Number of users who reached the capping limit and continued through <strong>ON_CAPPED</strong></td></tr></tbody></table>

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2F7UgmEEcDqNMitSFBF06w%2Fimage.png?alt=media&#x26;token=9fa92a66-020b-42a3-8917-083580cdd22d" alt="" width="563"><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://user.netmera.com/netmera-user-guide/omnichannel-engagement/journey-orchestration/journey-components/branch.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.