Content
Introduction
In this page you’ll learn…
What are rules?
How to use rules and combine them?
Available rules
Table of Contents
Getting Started with Rules
Rules are one of the most important components of Game Server, and they can be found in almost every available application.
Rules allow you to differentiate entities for specific user groups, and they can be used to target different sets of users.
Basics of Rules
Rules are based on logical operators. The 2 operators used are AND and OR:
| AND operator | OR operator |
| --- | --- |
| Users must match all added rules to receive the entity | Users must match at least one of the rules to receive the entity |
You can add as many rules inside a section of rules, and you can also combine sets of rules using Sections. Some rules also allow you to add multiple values by using the [green + button].
Example
Let’s say we want to target the following set of users:
From France OR UK
ANDHas Game version equal 2.7.0
ANDInstalled the app 15 days ago or more
How will we represent this in terms of rules?
Country = France or UK
Only the users who comply with all of these these conditions will receive the entity
Sections
Sections allow you to nest sets of rules and combine them to target users more accurately. Sections allow up to 3 levels of nesting , and they use different colours so that they can be distinguished easier. Sections also use the basic AND/OR operators to combine rules.
Next to [Add Rules], you’ll find [Add Section] (1) . After clicking the button, a new container will appear on top (2), where you’ll be able to add new rules and select which relation (AND/OR) should have with the other set of rules.
If you added your rules previously, and now you need to create a section, you can use the yellow button [Convert to a section] to create sections of rules without having to delete and add the rules in a section.
If there are rules without a section on the selected level, these rules will be moved to the newly created section
If there are 2 sections, then the system would convert it to a section with 2 sub sections (including top level)
By the click on the ‘Convert to a section’, system converts selected level of nesting into section and puts all the rules and sections from this level under created section
The button is disabled for the 3rd and 4th level of nesting
Example
Now we would like to target the following set of users:
Country = France or UK
ANDGame version = 2.7.0
ANDCohort day >= 15
OR
Country = France or UK
ANDGame version = 3.0.0
ANDCohort day >= 3
How will we represent this in terms of rules?
To do so, we need to create 2 sections of rules with the operand OR above, and include inside each set, the rules we want to match.
Game Server will then look for players matching the rules on the first set OR the second one.
Named Rule Groups
Named Rule Groups allow you to create and save a set of rules that can be later reused in any feature that uses rules, allowing you to save time setting up your configurations.
Setting up Named Rule Groups
Navigate to Named Rule Groups. In this page you’ll be able to visualise the already existing groups, and which rules compose them. Click the green [+ New] to create a new rule group. You can also duplicate, edit, or delete them using the actions available in the right side of the screen.
Give the group a name, and include your rules or sections of rules.
In order to use your Rule Group, navigate to any entity with rules, and click [Add Named Rule Group]. From there you can select your Rule Group without having to create it from scratch again!
The valid operators for Named Group Rules are IN/NOT IN
Named Rule Groups can be used in combination with other rules
Creating Named Rule Groups from Rules
You can also create Named Rule Groups directly from the Rules section in your entity. To do so:
Create your Rule, and click the grey [3 dots button]
Click [Create Named Rule Group]
Assign a name to your new Named Rule Group, and select whether you want to replace the section with the Named Rule Group
Your new Named Rule Group will be available to use and you will be able to edit it from Named Rule Groups section in Game Server
List of Available Rules
Below you’ll find a comprehensive list of all available rules with their conditions and the data available for each of them:
| Rule | Available conditions | Data | Description |
| Country | - IN - NOT IN | Country list | Country where the player is located |
| Language | Language list | Language of the device |
| Platform | Multi-select: - Other - iOS - Android - Amazon | OS of the player device |
| Cohort day | - >= - <= - > - < | Numeric input | Number of days starting from 12AM in local time zone |
| User Ids | - IN - NOT IN - >= - <= - > - < | Text input | User ID |
| Current game version | Current version of the game in the player’s device |
| Install game version | Version of the game originally installed in the player’s device |
| Previous game version | Previous version of the game installed in the player’s device |
| Install date (UTC) | - >= - <= | Date picker | Based on UTC time (Server time) |
| Install date (Local timezone) | - >= - <= | Date picker | Based on local time that the Client sent in /init call "utc_offset": "-11:00:00" |
| OS version | - IN - NOT IN - > - < - >= - <= | Text input | Operative system of the player’s device Example: - Android OS 11 / API-30 (RP1A.200720.012/A715FXXS4BUC1) - iPhone 12,4 |
| - IDFAs - IDFVs | - IN - NOT IN | Text input | |
| Device model | - LIKE - NOT LIKE | Text input. Regex can be used. | Example: samsung SM-A715F |
| LAT user * | - | - | If added, means LAT = true |
| Experiment variant | - IN - NOT IN | 1st level: all existing A/B experiments 2nd level: variants in specific experiment | GS will search whether player participated in specified variant of the experiment. Archived participations are not counted in the rule. Multiple experiment participations can be added via OR relation |
| Player Bucket | - IN - NOT IN | *User Id is divided by 100 Lower bound Upper bound Bounds can span from 0 to 99. | Bounds, ex. 0-9, means that players with ids end on _ xxx00 - xxx09 _ will match the rule. |
| Campaign Name | - CONTAINS - DOESN’T CONTAIN - IS BLANK - IS NOT BLANK | Case sensitive Partial search | Name of the ad campaign Note: When the user selects IS BLANK, the rule will match if there is no entity provided. |
| Media source | - IN - NOT IN - IS BLANK - IS NOT BLANK | Case sensitive Full search | Entity used to display ads |
| Onboarding mode | == | Text input | Available only for Duplica New object can be sent from client in /init call. Any unknown attribute except "onboarding_mode" will be ignored by server. "customattributes": { "onboardingmode": "hello" } Note: - Data is stored in separate Duplica table duplica_app_user_custom_attributes - Once sent to the server, it is saved in DB and there is no need to send this info again (only if you need to change) - Server handles "custom_attributes" only from Duplica players , otherwise it sends a 500 error (custom table created only for Duplica) |
| Total payments amount | - > - < - >= - <= - == | Single numeric decimal | Available only for Blackjack, Duplica, Merge, PPC |
| Last payment amount | - > - < - >= - <= - == | Single numeric decimal | Available only for Blackjack, Duplica, Merge, PPC |
| Days since last payment | - > - < - >= - <= - == | Single numeric decimal | Available only for Blackjack, Duplica, Merge, PPC |
| Days since previous visit | - > - < - >= - <= - == | Single numeric decimal | Calendar days are counted. Calculations are based on “Last visit at” and “Previous visit at” values for device. |
| Sessions count | - > - < - >= - <= - == | Single numeric decimal | Amount of sessions triggered by the user. Sessions is defined as as a period of play with no greater than a five minute break. |
| Debug IDs | - IN - NOT IN | String <=16 characters | |
| Device type | - IN - NOT IN | Multi-select: - Phone - Tablet | Tablet/Phone is detected based on screen resolution and DPI that are sent by the client |
| Days since version update | - > - < - >= - <= - == | Single numeric decimal | Calendar days are counted. Calculations are based on “App version updated at” value for device. |
| Version update date | - >= - <= | Date picker | Based on UTC time (Server time) The purpose of this rule is excluding users who update their app their app to a version that supports a specific journey after that journey starts, so that they can continue playing the journey they’d been playing before updating their version. This information is updated when the user makes the first /init call to server with a new version. When this happens, the date & time of this first init call is captured as update date in the device record in the system. |
| Build variant | - IN - NOT IN | Multi-select: - Default - Google - Samsung - Amazon - Apple - Apple - China | Platform used by the player |
| Device RAM capacity (MB) | - > - < - >= - <= - == | Single integer | In /init call client sends ram_capacity parameter which allows to deliver special configs and A/B Experiments for Android Go clients (low-end devices). The value is in megabytes. |
| Player segment | - >= - <= - > - < - == | Multi-select: list of segments synced from Hawk (the segments need to be created in Hawk beforehand) | Only active segments can be selected. |
| Days since Start At | - >= - <= - > - < | Numeric input | Usage : When an A/B experiment has variant groups created using this rule, GS counts the number of days since the “Start at” date of the experiment and decides which group the user should be in. Game Server starts counting the number of days starting from 12AM in local time zone. This rule is available only as an A/B Experiment Variant Rule and cannot be used anywhere else. |
| City | - IN - NOT IN | Dropdown with single value (only city available for now is London) | Behaviour: If a player belongs to the country in which the selected city is found (currently the only option is London), Game Server will send a request to GeoIP to check their city. The player matches the rule if GeoIP returns London as a city. |
| Player Buckets (NEW) | - IN - NOT IN | Dropdown with single value | The purpose of this rule is to deliver configurations only to users who belong to specific player buckets. This information is retrieved from Harmony, which includes the list of bucket IDs a player belongs to in each response. When evaluating a rule that includes a Player Bucket condition, the system checks whether the player’s bucket list includes the specified bucket ID. If it does, the configuration is delivered. If not, the configuration is excluded from delivery. |
\uD83D\uDCCB Related articles
- Page:
Configuring Game-Specific 3rd Party Machine Learning Models in Game Server
Page:
Configuring Embedded Machine Learning Models in Game Server
Page:
Ads Config: Configuring Ads in Game Server
Page:
File Configuration in Game Server
Page:
File Configuration in Game Server
Page:
Rules in Game Server
Page:
Game Settings Configuration
Page:
Setting up A/B Experiments
Page:
Managing Localisations in Harmony
Page:
Generic Daily Challenges
Page:
Configuring Ads in Game Server
Page:
Rules in Game Server
Page:
Setting up A/B Experiments
Page:
Chunks 2
**Introduction**
In this page you’ll learn…
- What are rules?
- How to use rules and combine them?
- Available rules
**Table of Contents**
* * *
# Getting Started with Rules
Rules are one of the most important components of Game Server, and they can be found in almost every available application.
Rules allow you to differentiate entities for specific user groups, and they can be used to target different sets of users.
# Basics of Rules
Rules are based on logical operators. The 2 operators used are AND and OR:
| **AND operator** | **OR operator** |
| --- | --- |
| Users must match **all added rules** to receive the entity | Users must match **at least one of the rules** to receive the entity |
You can add as many rules inside a section of rules, and you can also combine sets of rules using [Sections](https://tripledotstudios.atlassian.net/wiki/spaces/KB/pages/2668494860/Rules+in+Game+Server#Sections). Some rules also allow you to add multiple values by using the **[green + button]**.
### **Example**
Let’s say we want to target the following set of users:
- From France OR UK
**AND**
- Has Game version equal 2.7.0
**AND**
- Installed the app 15 days ago or more
**How will we represent this in terms of rules?**
- Country = France or UK
- Only the users who comply with all of these these conditions will receive the entity
# Sections
Sections allow you to nest sets of rules and combine them to target users more accurately. Sections allow **up to 3 levels of nesting** , and they use different colours so that they can be distinguished easier. Sections also use the basic AND/OR operators to combine rules.
Next to **[Add Rules]**, you’ll find **[Add Section]** (1) **.** After clicking the button, a new container will appear on top (2), where you’ll be able to add new rules and select which relation (AND/OR) should have with the other set of rules.
If you added your rules previously, and now you need to create a section, you can use the yellow button **[Convert to a section]** to create sections of rules without having to delete and add the rules in a section.
- If there are rules without a section on the selected level, these rules will be moved to the newly created section
- If there are 2 sections, then the system would convert it to a section with 2 sub sections (including top level)
- By the click on the ‘Convert to a section’, system converts selected level of nesting into section and puts all the rules and sections from this level under created section
- The button is disabled for the 3rd and 4th level of nesting
#### **Example**
Now we would like to target the following set of users:
- Country = France or UK
**AND**
- Game version = 2.7.0
**AND**
- Cohort day \>= 15
**OR**
- Country = France or UK
**AND**
- Game version = 3.0.0
**AND**
- Cohort day \>= 3
**How will we represent this in terms of rules?**
To do so, we need to create 2 sections of rules with the operand OR above, and include inside each set, the rules we want to match.
Game Server will then look for players matching the rules on the first set OR the second one.
# Named Rule Groups
_Named Rule Groups_ allow you to create and save a set of rules that can be later reused in any feature that uses rules, allowing you to save time setting up your configurations.
Setting up Named Rule Groups
1. Navigate to Named Rule Groups. In this page you’ll be able to visualise the already existing groups, and which rules compose them. Click the green **[+ New]** to create a new rule group. You can also duplicate, edit, or delete them using the actions available in the right side of the screen.
2. Give the group a name, and include your rules or sections of rules.
3. In order to use your Rule Group, navigate to any entity with rules, and click **[Add Named Rule Group].** From there you can select your Rule Group without having to create it from scratch again!
- The valid operators for Named Group Rules are IN/NOT IN
- Named Rule Groups can be used in combination with other rules
### Creating Named Rule Groups from Rules
You can also create Named Rule Groups directly from the Rules section in your entity. To do so:
1. Create your Rule, and click the grey **[3 dots button]**
2. Click **[Create Named Rule Group]**
3. Assign a name to your new Named Rule Group, and select whether you want to replace the section with the Named Rule Group
4. Your new Named Rule Group will be available to use and you will be able to edit it from Named Rule Groups section in Game Server
* * *
# List of Available Rules
Below you’ll find a comprehensive list of all available rules with their conditions and the data available for each of them:
| **Rule** | **Available conditions** | **Data** | **Description** |
| **Country** | - IN - NOT IN | Country list | Country where the player is located |
| **Language** | Language list | Language of the device |
| **Platform** | Multi-select: - Other - iOS - Android - Amazon | OS of the player device |
| **Cohort day** | - \>= - \<= - \> - \< | Numeric input | Number of days starting from 12AM in local time zone |
| **User Ids** | - IN - NOT IN - \>= - \<= - \> - \< | Text input | User ID |
| **Current game version** | Current version of the game in the player’s device |
| **Install game version** | Version of the game originally installed in the player’s device |
| **Previous game version** | Previous version of the game installed in the player’s device |
| **Install date (UTC)** | - \>= - \<= | Date picker | Based on UTC time (Server time) |
| **Install date (Local timezone)** | - \>= - \<= | Date picker | Based on local time that the Client sent in `/init` call `"utc_offset": "-11:00:00"` |
| **OS version** | - IN - NOT IN - \> - \< - \>= - \<= | Text input | Operative system of the player’s device Example: - Android OS 11 / API-30 (RP1A.200720.012/A715FXXS4BUC1) - iPhone 12,4 |
| - **IDFAs** - **IDFVs** | - IN - NOT IN | Text input | |
| **Device model** | - LIKE - NOT LIKE | Text input. Regex can be used. | Example: samsung SM-A715F |
| **LAT user \*** | - | - | If added, means LAT = true |
| **Experiment variant** | - IN - NOT IN | 1st level: all existing A/B experiments 2nd level: variants in specific experiment | GS will search whether player participated in specified variant of the experiment. Archived participations are not counted in the rule. Multiple experiment participations can be added via OR relation |
| **Player Bucket ** | - IN - NOT IN | _\*User Id is divided by 100_ Lower bound Upper bound Bounds can span from 0 to 99. | Bounds, ex. 0-9, means that players with ids end on _ **xxx00 - xxx09** _ will match the rule. |
| **Campaign Name** | - CONTAINS - DOESN’T CONTAIN - IS BLANK - IS NOT BLANK | Case sensitive Partial search | Name of the ad campaign Note: When the user selects IS BLANK, the rule will match if there is no entity provided. |
| **Media source** | - IN - NOT IN - IS BLANK - IS NOT BLANK | Case sensitive Full search | Entity used to display ads |
| **Onboarding mode** | == | Text input | Available only for **Duplica** New object can be sent from client in `/init` call. Any unknown attribute except **"onboarding\_mode"** will be ignored by server. "custom_attributes": { "onboarding_mode": "hello" } Note: - Data is stored in separate Duplica table `duplica_app_user_custom_attributes` - Once sent to the server, it is saved in DB and there is no need to send this info again (only if you need to change) - Server handles `"custom_attributes"` only from **Duplica players** , otherwise it sends a 500 error (custom table created only for Duplica) |
| **Total payments amount** | - \> - \< - \>= - \<= - == | Single numeric decimal | Available only for **Blackjack, Duplica, Merge, PPC** |
| **Last payment amount** | - \> - \< - \>= - \<= - == | Single numeric decimal | Available only for **Blackjack, Duplica, Merge, PPC** |
| **Days since last payment** | - \> - \< - \>= - \<= - == | Single numeric decimal | Available only for **Blackjack, Duplica, Merge, PPC** |
| **Days since previous visit** | - \> - \< - \>= - \<= - == | Single numeric decimal | **Calendar days** are counted. Calculations are based on “Last visit at” and “Previous visit at” values for device. |
| **Sessions count** | - \> - \< - \>= - \<= - == | Single numeric decimal | Amount of sessions triggered by the user. Sessions is defined as as a period of play with no greater than a five minute break. |
| **Debug IDs** | - IN - NOT IN | String \<=16 characters | |
| **Device type** | - IN - NOT IN | Multi-select: - Phone - Tablet | Tablet/Phone is detected based on screen resolution and DPI that are sent by the client |
| **Days since version update** | - \> - \< - \>= - \<= - == | Single numeric decimal | **Calendar days** are counted. Calculations are based on “App version updated at” value for device. |
| **Version update date** | - \>= - \<= | Date picker | Based on UTC time (Server time) The purpose of this rule is excluding users who update their app their app to a version that supports a specific journey after that journey starts, so that they can continue playing the journey they’d been playing before updating their version. This information is updated when the user makes the first `/init` call to server with a new version. When this happens, the date & time of this first init call is captured as update date in the device record in the system. |
| **Build variant** | - IN - NOT IN | Multi-select: - Default - Google - Samsung - Amazon - Apple - Apple - China | Platform used by the player |
| **Device RAM capacity (MB)** | - \> - \< - \>= - \<= - == | Single integer | In `/init` call client sends `ram_capacity` parameter which allows to deliver special configs and A/B Experiments for Android Go clients (low-end devices). The value is in megabytes. |
| **Player segment** | - \>= - \<= - \> - \< - == | Multi-select: list of segments synced from Hawk (the segments need to be created in Hawk beforehand) | Only active segments can be selected. |
| **Days since Start At** | - \>= - \<= - \> - \< | Numeric input | **Usage** : When an A/B experiment has variant groups created using this rule, GS counts the number of days since the “Start at” date of the experiment and decides which group the user should be in. Game Server starts counting the number of days starting from 12AM in local time zone. This rule is available **only** as an A/B Experiment Variant Rule and cannot be used anywhere else. |
| **City** | - IN - NOT IN | Dropdown with single value (only city available for now is London) | **Behaviour:** If a player belongs to the country in which the selected city is found (currently the only option is London), Game Server will send a request to GeoIP to check their city. The player matches the rule if GeoIP returns London as a city. |
| **Player Buckets (NEW)** | - IN - NOT IN | Dropdown with single value | The purpose of this rule is to deliver configurations only to users who belong to specific player buckets. This information is retrieved from Harmony, which includes the list of bucket IDs a player belongs to in each response. When evaluating a rule that includes a Player Bucket condition, the system checks whether the player’s bucket list includes the specified bucket ID. If it does, the configuration is delivered. If not, the configuration is excluded from delivery. |
## \uD83D\uDCCB **Related articles**
-
Page:
[Configuring Game-Specific 3rd Party Machine Learning Models in Game Server](/wiki/spaces/KB/pages/4580999169/Configuring+Game-Specific+3rd+Party+Machine+Learning+Models+in+Game+Server)
-
Page:
[Configuring Embedded Machine Learning Models in Game Server](/wiki/spaces/KB/pages/4548263939/Configuring+Embedded+Machine+Learning+Models+in+Game+Server)
-
Page:
[Ads Config: Configuring Ads in Game Server](/wiki/spaces/Innovecs/pages/4442063826/Ads+Config+Configuring+Ads+in+Game+Server)
-
Page:
[File Configuration in Game Server](/wiki/spaces/Innovecs/pages/4441866278/File+Configuration+in+Game+Server)
-
Page:
[File Configuration in Game Server](/wiki/spaces/KB/pages/4440228000/File+Configuration+in+Game+Server)
-
Page:
[Rules in Game Server](/wiki/spaces/Innovecs/pages/4355850392/Rules+in+Game+Server)
-
Page:
[Game Settings Configuration](/wiki/spaces/Innovecs/pages/3849912340/Game+Settings+Configuration)
-
Page:
[Setting up A/B Experiments](/wiki/spaces/Innovecs/pages/3848602658/Setting+up+A+B+Experiments)
-
Page:
[Managing Localisations in Harmony](/wiki/spaces/KB/pages/3230760961/Managing+Localisations+in+Harmony)
-
Page:
[Generic Daily Challenges](/wiki/spaces/KB/pages/2933653553/Generic+Daily+Challenges)
-
Page:
[Configuring Ads in Game Server](/wiki/spaces/KB/pages/2765029415/Configuring+Ads+in+Game+Server)
-
Page:
[Rules in Game Server](/wiki/spaces/KB/pages/2668494860/Rules+in+Game+Server)
-
Page:
[Setting up A/B Experiments](/wiki/spaces/KB/pages/2581889051/Setting+up+A+B+Experiments)
-
Page:
[Game Settings Configuration](/wiki/spaces/KB/pages/2580021328/Game+Settings+Configuration)