> For the complete documentation index, see [llms.txt](https://help.smartico.ai/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.smartico.ai/welcome/products/crm-automation/create-journey-flow.md).

# Campaigns

### Overview

Smartico supports two types of campaigns: **Real-time campaigns** and **Scheduled campaigns**.\
You can create campaigns in two ways: build them from scratch or start from pre-defined templates. The campaign creation from template is available for both Real-time and Scheduled campaign types.

{% hint style="info" %}
**Placeholders:** Templates provide the logic (the "flow"), but specific assets (Emails, SMS, Push, Bonus, etc.) must be reviewed to ensure branding and messaging accuracy
{% endhint %}

**Accessing Templates**

**Navigate to:** `Campaigns > Create > Create Campaign from Template.`

<figure><img src="/files/Xm85NpkU8i8Z3v93rnma" alt=""><figcaption></figcaption></figure>

**Select:** Choose from our pre-configured marketing or operational campaign types.

**Configure:** Assign a campaign name and select your target segment.

**Customize:** Review the flow and replace any placeholder content.

* **Note:** For activities like Email, the template uses a generic resource. You must update this content or swap it for an existing resource from your library.

**Activate:** Once placeholders are finalized, your campaign is ready for activation.

<figure><img src="/files/qTch00JbKdCG4q12oEgd" alt=""><figcaption></figcaption></figure>

### **Real-Time Campaigns (Journeys)**

Triggered immediately by specific player events, such as Deposit, Withdrawal, Login, Casino or Sports bets, Account status changes, client actions, etc. When setting up a real-time campaign, you can configure:

* **Entry trigger** - can be any event defined in the system (Deposit approved, User Login, User Logout, Sport bet, Casino bet, etc.)
* **Player Segment** (e.g., only VIP players, only players with deposits above €100, etc.)
* **Entry Mode** (e.g., once per open journey, once in a user’s lifetime, etc.)
* **Max. Campaign Duration** - Defines the maximum time a user can remain in the campaign per entry. The countdown starts the moment the user enters the campaign. Once the specified duration expires, the campaign will automatically end for that user.
* **Control Group** - when set, the system will keep the specified percentage of the users outside of the Campaign and will measure how they are achieving the 'Conversion Rule' in the specified period of the Campaign duration.
* **Custom activity period** - The Activity period defines the timeframes for when the users will be able to enter the campaign. When the End date is reached, new players cannot join, but existing ones can progress.
* **Active hours within the day** - The active hours define the entry time. The users keep progressing within the campaign if they’re already in it, even outside the active hours. You can choose from ‘System time (UTC)’ or ‘User time zone’. If ‘User time zone’ the active hours will be applied based on each player’s individual time zone.
* **Set explicit stop date (UTC)** - The Stop Date ends the campaign for all users but does **not** change the campaign’s overall status.
  * Users who are already in the campaign cannot progress after the Stop Date.
  * New users cannot join the campaign after the Stop Date.
* **Maximum number of entries per user** - allows you to define how many entries a user is allowed within a specific time period. Once the limit is reached, the user will no longer be able to enter the campaign until the restriction resets. Available options are:
  * Lifetime - limits the total number of entries for the user overall
  * Days - limits entries within a rolling or calendar-based period. You can choose:
    * Calendar days in user’s time zone
    * Calendar days in a specific timezone (e.g. UTC+3)
    * Time counted from the user’s last entry

{% hint style="info" %}
**Important:**

* The **'Maximum number of entries per user'** setting is only available when enabled in '**Label Settings → Enable maximum number of entries per user'**. By default, this setting is disabled.
* Please contact your Success Manager to enable it.
* Available only for Real-time Campaigns.
  {% endhint %}

<figure><img src="/files/lZ4pCDIdhNFFD3LyZX3I" alt=""><figcaption><p>BO: Journey template</p></figcaption></figure>

### **Scheduled Campaigns**

Such campaigns are triggered on a defined schedule, such as:

* Daily
* Specific days of the week
* Specific days of the month
* One-time on a specific date

Scheduled campaigns offer nearly the same configuration options as real-time campaigns, with one key difference: they are triggered by a schedule rather than an event. Below are the settings specific to scheduled campaigns:

* **Execution speed** - Depending on your SMS & Mail gateways, you can limit the speed of campaign execution.
* **User limit per run** - If the segment is bigger than the limit, users will be chosen randomly for every run. If you want to cover 100% of the segment in multiple runs, please use the “once in a lifetime” entry mode. Example: the segment has 1,000,000 users, you want to have a limit of 100,000 per day, and run the campaign for 10 days to cover every user out of the 10 mln. To achieve that, use the 'once in a lifetime' entry mode. Otherwise, the campaign will pick random users every day, and some of them will be able to enter the campaign more than once, while the others will not enter at all.

<figure><img src="/files/6birHTR5Ah6PtOgXTaHB" alt=""><figcaption><p>BO: Scheduled campaign template</p></figcaption></figure>

The Grid view provides a quick overview of all your campaigns, along with powerful filters to easily find the one you need. Key details such as campaign name, trigger, segment, status, execution status, duration, control group (if set), and conversions (last 24h, 7 days, or 30 days) are all displayed. You can also see the campaign’s active dates and much more at a glance.

<figure><img src="/files/mU3jfGnzfcxFQLa8fynO" alt=""><figcaption><p>BO: Campaigns grid view</p></figcaption></figure>

Both campaign types are created with the Smartico Flow Builder, a visual tool for planning and automating campaigns that guide users throughout their engagement journey with your brand.

<figure><img src="/files/eQ9Depyxvd1AAxvfmjzw" alt=""><figcaption><p>BO: Journey builder in Campaigns</p></figcaption></figure>

The core elements that define your campaign’s logic are called *Activities*. These are organized into categories, allowing you to simply drag and drop them to build your campaign flow. Each Activity comes with its own configuration options, giving you full flexibility to shape the flow as needed. Learn more about Activities in campaign flows [here](https://help.smartico.ai/welcome/products/crm-automation/activities-of-flows).

<figure><img src="/files/znr2BoozgCY60TMGVr5s" alt=""><figcaption><p>BO: Email activity in the Flow builder</p></figcaption></figure>

### Control Group

Setting up a control group (CG) in your campaign will keep the specified percentage of the users outside of the Campaign and will measure how they are achieving the 'Conversion Rule' in the specified period of the Campaign duration.

<figure><img src="/files/NlCcBR0H5JIDuwjyzIWi" alt=""><figcaption></figcaption></figure>

Using the Control Groups you can also:

* **Exclude users currently in any control group** - do not let a user enter Campaign B if they are already being held back in any other campaign.
* **Exclude users currently in a specific campaign's control group** - more targeted: only exclude if they are in Campaign A's control group specifically.

This can be controlled by a property called **‘Core: Active campaigns where user in CG’** ( `user_current_cg_campaigns` ) which is updated by the following events:

* Added → `cjm_user_added_to_control_group` - fires when the user is randomly assigned to the control group on campaign entry.
* Removed → `cjm_left_control_group_campaign` - fires when the campaign ends for that user (timeout, operator stop, or scheduled batch close).

These conditions can be added to any campaign's entry rules through the existing query builder.

#### Example Scenario

Run two parallel campaigns. ‘Campaign A’ has a control group for measurement. Any user currently sitting in Campaign A's CG should be shielded from ‘Campaign B’ - they can't receive both the "held-back measurement" role and an active offer at the same time.

**Campaign A - Retention Offer (the one with the CG)**

| **Settings:**               | **Value:**                                                              |
| --------------------------- | ----------------------------------------------------------------------- |
| Name                        | Retention\_weekly\_Offer                                                |
| Type                        | Journey                                                                 |
| Max. Campaign duration      | 3 Days                                                                  |
| Control Group               | 10 %                                                                    |
| Keep user in CG on re-enter | No (leave OFF unless you specifically need sticky CGs - see note below) |
| Entry Conditions            | Your normal eligibility segment (e.g. active depositors)                |

**Note:** This campaign measures whether your retention offer works. 10% of qualifying users are held back (CG). They enter the journey, receive no communication or rewards, but their conversions are tracked for comparison.

**Campaign B - Reactivation Bonus (the one being protected)**

| **Settings:**    | **Value:**                                                 |
| ---------------- | ---------------------------------------------------------- |
| Name             | Reactivation\_Bonus\_Push                                  |
| Type             | Scheduled or Journey                                       |
| Entry Conditions | Your normal target segment + the exclusion condition below |

Note: This is where you add the guard. In the entry conditions (segment or the campaign's own "Add Condition" field), add one of the two conditions depending on how broad you want the exclusion:

#### The Two Conditions - How to Set Them Up

**Option 1** - Broad: Exclude users in ***any*** control group

Use this when you want to protect Campaign B from any CG hold-back, regardless of which campaign placed them there. In the segment builder, add:

`Core: Active campaigns where user in CG | is empty`

What this means: the user's live CG list is empty - they are not currently being held back anywhere. This is the most common and recommended starting point.

<figure><img src="/files/UzEwiqKUayPvlGehghQD" alt=""><figcaption></figcaption></figure>

**Option 2** - Targeted: Exclude users in ***Campaign A's*** control group specifically

Use this when you have multiple campaigns with CGs (Control Groups) and you only want to block users from one specific campaign's CG - letting users in other CGs still enter Campaign B. In the segment builder, add:

`Core: Active campaigns where user in CG | doesn't habe any of| [Campaign A audience_id]`

Goal: Block Campaign B entry only for users currently in Campaign A's control group specifically.

1. Open Campaign B → segment / Add Condition.
2. Search for `Core: Active campaigns where user in CG`.
3. Set operator to `doesn't have any of`.
4. In the value field, enter the audience\_id of Campaign A - the integer in Campaign A's URL (<mark style="color:green;">#/j\_audience\_head/XXXXXX</mark>), e.g. <mark style="color:green;">531100</mark>.
5. Save and apply.

<figure><img src="/files/PWw9P6z6grO8nMoKhcIu" alt=""><figcaption></figcaption></figure>

The property stores exactly these audience IDs - when a user is placed into Campaign A's CG, <mark style="color:green;">531100</mark> (or whatever Campaign A's ID is) is appended to their `user_current_cg_campaigns` array. So `doesn't have any of` \[531100] correctly reads as "this user is not currently in Campaign A's control group."

**Important note:** on "doesn't have any of" semantics: if you list multiple IDs (e.g. 531100, 531200), the condition is satisfied when the user's array contains none of them. A user who is in Campaign A's CG and Campaign C's CG would still be blocked if only 531100 is listed. To block users in either A or C, add both IDs to the value list.

#### Quick-reference: Option 1 vs Option 2

|                          | Option 1                                | Option 2                                       |
| ------------------------ | --------------------------------------- | ---------------------------------------------- |
| **Goal**                 | Block users in *any* CG                 | Block users only in a *specific* campaign's CG |
| **Property**             | Core: Active campaigns where user in CG | Core: Active campaigns where user in CG        |
| **Operator**             | `is empty`                              | `doesn't have any of`                          |
| **Value**                | *(none)*                                | Audience ID(s) of the target campaign(s)       |
| **Where to find the ID** | —                                       | Campaign URL: `#/j_audience_head/XXXXXX`       |

### Campaign Status and Executions status

It’s important to distinguish between a campaign’s Status and its Execution Status:

1. **Campaign Status** - Controlled manually by the operator.
   1. **Draft**: Default status when a campaign is created.
   2. **Active:** Campaign is live. From here, it can be changed to other statuses.
   3. **Paused:** Campaign is temporarily stopped but can be reactivated. Campaigns are still running for users who entered Journey, but new users will not enter.
   4. **Disabled:** Campaign is temporarily stopped, but can be reactivated. Is disabled for new users and users who have already entered.
   5. **Executed / Archived:** Final states - once set, status cannot be changed further.

<figure><img src="/files/g1wjC2KNBOPakGM6jlh4" alt=""><figcaption><p>BO: Status and Execution status in campaigns template</p></figcaption></figure>

2. **Execution Status** - Indicates the actual state of the campaign based on its configuration (availability period, start/stop dates, and status). Possible states:
   1. **Inactive:** Campaign is not active -> Campaign Status = Archived, Paused, Disabled, Executed, or scheduling issue (e.g., the campaign did not start and there are no future runs)
   2. **Active / Planned:** Start date not reached yet - campaign hasn’t started, and players cannot enter or progress in the campaign.
   3. **Active / Running:** Campaign is live - players can enter and progress.
   4. **Active / Executed** (*Scheduled campaigns only*): All runs are completed, but the stop/end date has not yet been reached (or not set). Players cannot enter or progress.
   5. **Expired:** Campaign has reached its 'Active until' or Stop date.
      1. Active until date is reached - No new players can join, but existing ones can progress.
      2. Stop date is reached - The stop date stops the campaign for all the users inside and new users cannot enter the campaign after the stop date.
   6. **Failed** (Scheduled Campaigns): Current execution batch has problems. For example, the total of *started users* plus *skipped users* does not match the number of *target users*.

<figure><img src="/files/8KgIXmN9ndAKBeqQ7fil" alt=""><figcaption><p>BO: Status and Execution sttus in Campaigns grid</p></figcaption></figure>

{% hint style="warning" %}
If a Scheduled Campaign is configured as **'One-time on a specific date'**, once the date is reached and the campaign is executed:

* The Status changes to Executed.
* The Execution Status changes to Inactive.
  {% endhint %}


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.smartico.ai/welcome/products/crm-automation/create-journey-flow.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
