> 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/segmentation/behavioral-segments.md). # Behavioral Segments ### Overview Behavioral segments are based on the behavior of the user. It combines data from both the user profile state and his behavior. The segment is based on the historical behavior of the user, e.g. users that did total wagering of more than 100 EUR on Slot games in the last 30 days. {% hint style="info" %} This type of segment is updated by a defined schedule. For example once a day at 5 PM. From all other perspectives, this type of segment can be used as any other in all possible contexts of the Smartico platform. {% endhint %} Inside the segment template, you can find information about the segment's last and next rebuilds based on the defined schedule.

You can manually initiate the rebuild process by clicking the 'Rebuild Segment' button. Once triggered, the segment will be added to the queue, and the rebuild will begin shortly. Progress can be monitored in the Calculation History section. {% hint style="info" %} In the **'Users List'** tab, you can see all users currently included in the segment until the next rebuild. Any changes in user behavior before the rebuild will not be reflected until the segment is rebuilt. {% endhint %}

When setting the rebuild schedule for Behavioral Segments, the system will automatically select a time with lower system load by default. You can change this to a different time if needed. However, if the selected time falls within a high-load period, a warning shows the average calculation delay at that time and suggests choosing a different time. You can still proceed with your chosen time. {% hint style="info" %} Note: by default, a behavioral segment can be rebuilt at most once a day. Depending on your use case and the amount of data, it is possible to enable hourly rebuild, but it requires additional activation. Please contact your Success Manager to discuss this option. {% endhint %}

### How to Setup a Behavioural Segment In order to set up the segment you must fill in the following sections: * **Type of period** and **User had activity** - which activity you would like to track and for what period of time. The maximum time for analysis depends on the activity. For example, for Deposit is 365 days, and for Casino bets is 90 days. The shortest time back period is 1 day. * **Event attributes** - you can define related to the event (activity) attributes * **Total conditions** - aggregate conditions calculated across all qualifying events in the selected timeframe: Count of activities, Total (SUM), Min, Max, Average (AVG), or Median. E.g. to segment users whose Total bet amount was above 1000 EUR or whose Average deposit exceeded 50 EUR. * **Calculation schedule** - define a schedule when the segment will be rebuilt * **User State condition** - To make your segment even more precise you can also add a user state condition like brand, registration country, language, etc {% hint style="warning" %} **Important — Event Attributes vs. Total Conditions:** * **Event Attributes** filter *individual event records* (e.g. each single deposit must be >= 50 EUR, or game provider = Pragmatic). * **Total Conditions** filter the *cumulative aggregate* across all events in the timeframe (e.g. sum of all deposits >= 100 EUR, or total bet count >= 10). Placing cumulative amount or count conditions in Event Attributes will filter out single transactions that do not meet the full threshold, resulting in 0 users in the segment. {% endhint %}

Behavioral segment setup: 1 — Type of period; 2 — User had activity and the time window; 3 — Event attributes; 4 — Total conditions; 5 — User State condition; 6 — Calculation schedule

### Single Activity Restriction and Combining Segments Each behavioral segment can evaluate only one activity (event type). To segment users based on multiple activities (for example, players who deposited AND placed a casino bet), create a separate behavioral segment for each activity, then combine them in a User State segment (with the **Core: Behavioural segments** property) or in campaign targeting conditions. Behavioral segments like other segments can be exported and have a scheduled export if needed. In **User properties**, choose the user properties to include in the export. If you leave it empty, the export has only the basic details of each player (ID and brand). One export file (manual or scheduled) holds at most the number of players set in the **Max players in one segment export** setting in **Label settings** (1,000,000 by default). If the segment is bigger, the export is cut at this number. You cannot change this setting yourself; ask your Success manager to change it.

If a scheduled export exists for a segment, it will be indicated in the Segments grid view with an icon. Hovering over the icon will display the scheduled details.

This type of segment can be used in any context in CRM Automation or Gamification modules: * to limit Real-time and Scheduled campaigns * to limit Automation rules * to limit the visibility of Tournaments, Store items, and Mini-games ### Automation Rules and Journey Triggers When a behavioral segment finishes rebuilding, the system emits events for membership changes: * **Core: user added to behavioural segment** — fires for each player who newly entered the segment during this rebuild. * **Core: user removed from behavioural segment** — fires for each player who no longer meets the segment criteria and was removed. These events fire only for the delta (entering or exiting users). Players who remain in the segment continuously do not receive events on every rebuild cycle. You can use these events as triggers in Automation Rules and Journeys by selecting the specific segment. ### Behavioral Segments and User State Properties Behavioral segments can include user state properties. However, if a Behavioral Segment with user state properties is used in a Campaign, Automation Rule, Tournament, Mini-game, etc., any changes to a user's state properties before the next scheduled rebuild will not be applied. The user will continue to progress in the Campaign, Rule, Tournament, etc., based on their status during the last rebuild. **🔍 Example:** * You have a Behavioral Segment for users who deposited more than 100 EUR in the last 30 days with the user state property: `Last login device = Desktop.` * At 00:00, a scheduled rebuild occurs, and John matches the segment conditions. * At 02:00, John logs in using a mobile device. * Despite the change, John will continue to match the segment criteria until the next rebuild. * If John tries to register for a Tournament at 02:00, he will be allowed because the segment still considers him as having logged in from a Desktop.

### Fixed & Relative periods for Behavioral Segments There are three period types to help you build Behavioural segments. The options are available only for the behavioral segments and can be found in the **Type of period** field: * **Fixed Period:** Set specific dates, e.g., from 01.01.2024 to 23.01.2024 (UTC). * **Relative period:** Use dynamic ranges: Current day till now, Previous full day, Last 24 hours, Last weekend, This week till now, Last full week, This month till now, Last full month. You can also select different time zones and the calculations of the user segment will be based on it. * **Time back period:** Set a rolling lookback window (e.g., past 7 days, past 30 days) with an optional exclusion buffer (e.g., excluding the last 1 hour or last 1 day). For example, you can now create a behavioral segment for users who deposited more than 1000 EUR total in the last full month in UTC +6.

### FAQ **Q: Should I use a Real-Time Journey or a Scheduled Campaign with Behavioral Segments?** A: Because behavioral segments are recalculated periodically in batch, use Scheduled Campaigns for planned communications, scheduling the campaign to run after the segment rebuild time. If you need to trigger actions in real time when a player enters the segment, create an Automation Rule or Journey triggered by the "Core: user added to behavioural segment" event. **Q: Can I segment users by the number of distinct active days (e.g. wagered on 4 separate days in the last 7 days)?** A: No. Total conditions support the total count of events and aggregate values (sum, min, max, average, median), but do not support distinct calendar day counts. To track activity across multiple days, consider using daily Gamification missions or custom user tags. **Q: Does clicking "Estimate" rebuild the segment or update the users list?** A: No. The Estimate button runs a preview calculation to display the approximate audience size without saving changes, updating the active users list, or firing automation events. To update the segment membership, click "Rebuild Segment" or wait for the scheduled rebuild. --- # 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://help.smartico.ai/welcome/products/crm-automation/segmentation/behavioral-segments.md?ask=&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.