Content
Introduction
In this guide you’ll learn:
What is segmentation
What are the attributes
Types of attributes
How to create attributes
What are the segments
How are segments configured in Harmony
Offline segments
How to use your Segments in GS and Hawk
Table of Contents
First of all, what is segmentation?
User segmentation is the process of creating groups of users based on specific characteristics.
By identifying commonalities and differences among different user segments, we can develop targeted shop offers, create more personalised user experiences, and ultimately drive better results. With a good segmentation strategy, you can…
Personalise experiences. You can create an experience specific to the player, ensuring they are provided with affordable and attainable goals.
Create relevant content. Surface the right content to players based on the features and benefits that will matter to them the most, especially when considering where they are in the player life cycle.
Drive strong perception of value. Ensure you’re driving the strongest perception of value for your game. This will keep players engaged over time and bring continued monetisation growth as players see value in spending both time and money in your game.
At Tripledot, we use Harmony to slice groups of users and create segments. Once the segments are created, Product Managers can use them to create different catalogs to send customised offers in the game shops, create A/B experiments with your segments, and much more. You can also use these segments in Game Server to create Rules.
Interested in the topic?
New to Gaming? Read more about LiveOps here! Also,in this URL you’ll find an interesting presentation on LiveOps and Segmentation.
Do you want to know more about segmentation? Here’s an in-depth article about it!
Segmentation Features
Segmentation is composed of two main features:
Attributes
Segments
Below you’ll find what every feature is and how to use them.
Attributes
What are Attributes?
Attributes represent the properties of players and their devices, used to define and create audience segments.
There are different categories of attributes:
Source-Based Category
External attributes: attributes created by Data Science & Engineering and sent daily to Player Service. One of the examples of External attributes is: avg_game_wins_7d
You can check the examples list here. Please note. This list is not exhaustive.Custom: attributes created by Client developers and sent immediately to Player Service based on different triggers. Ex: current_level
System attributes: attributes calculated internally by Player Service. There are 3 main triggers that can be used by the Client team:
| Trigger | Attribute | Description |
| --- | --- | --- |
| App Open | Last Login Date | The date and time when the player last logged into the app. |
| | Previous Login Date | The date and time of the player’s login prior to the last login. |
| | Total Session Count | The total number of app sessions the player has initiated over all the devices. |
| | Session Count | The number of sessions the player has initiated in the current time period on each device. |
| App Install | Install Date | The date and time when the app was installed on the player’s device. |
| | Install ID | A unique identifier for the app installation. |
| | Account ID | A unique identifier for the player’s account in the system. |
| | IDFV | Identifier for Vendors, a unique identifier specific to the player’s device. |
| | Country | The country where the app is being accessed. |
| | App Version | The version of the app being used by the player. |
| | Platform | The operating system (e.g., iOS, Android) the player is using. |
| | Language | The primary language set on the player’s device. |
| | Time Zone Offset | The difference in time between the player’s local time zone and UTC. |
| Payment Success | Average Payments Amount | The average amount of all payments made by the player. |
| | Last Payment Amount | The amount of the most recent payment made by the player. |
| | Last Payment Date | The date and time when the player made their most recent payment. |
| | Last Payment Category | The category associated with the player’s most recent payment (e.g., item type). |
| | Total Payments Amount | The cumulative sum of all payments made by the player. |
| | Total Payments Count | The total number of payments made by the player. |
| | Last X Payments Amounts | A list or summary of the amounts for the last X payments made by the player. |
| | Max Payment Amount | The highest single payment amount made by the player. |
| LiveOps Events | LiveOps Experiment Ids | Unique identifiers for LiveOps experiments the player is part of. |
| | LiveOps Experiment Variant Ids | Unique identifiers for the specific variants of LiveOps experiments assigned |
Please note that this is not an exhaustive list of attributes and triggers.
For QA:
- IDFV is available as an attribute to facilitate testing
About System Attributes
These attributes are processed by Harmony and do not need calculation from the Client. This means that if a system trigger takes place, such as payment success, the Client triggers “Payment Success” which has information about the transaction.
Once the trigger with the transaction data has been received by Harmony, Harmony Server recalculates the related system attributes (average payment).
You can find more information here.
As attributes come from different sources, not all of them can be used starting from the moment the player first opens the game. To better visualise the timeline of a player and how the events are created and reported, check the timeline below:
Attributes can be used in Harmony immediately upon data arrival, but segment updates align with the designated start day.
Type-Based Category
This classification distinguishes whether the attributes pertain to players or devices :
Player Attributes:
Device Attributes:
A player can have multiple devices, each with its own attribute values. For example, if we have the attribute "platform," one of the player’s devices might have "Android" as its platform value, while another device could have "iOS."
Data Formats
The following data formats are supported:
Integer : Represents whole numbers without any decimal points.
Timestamp : Represents a specific point in time, typically stored in a format like Unix epoch time or an ISO timestamp.
Float : A numeric value that can contain decimal points.
String : A sequence of characters or text.
Boolean : Represents a binary value, typically
trueorfalse.Array : A collection or list of values, which can include strings, numbers, or other data types.
Version : Typically following semantic versioning (e.g., major.minor.patch).
Expiration Dates in External Attributes
External attributes have an expiration setting. There are three options for expiration:
Never: The attribute will not expire, meaning it remains valid indefinitely.
Immediate: The attribute will expire immediately after it is not updated after successful processing.
Delayed: This allows you to set a custom expiration period where the attribute remains valid for a set time before expiring.
The expiration mechanism ensures that the system can effectively manage external data that may become outdated, either by keeping it indefinitely, removing it immediately, or setting it to expire after a set period.
For example, consider the attribute “avg_payments_7d”:
If a player hasn’t made a purchase for 7 days, the data exchange (DE) stops sending values for this attribute.
If the attribute is set to never expire , Harmony will use the last known value for this player when calculating segments, even if the data is old.
If the attribute is set to expire immediately , Harmony will ignore this attribute in the next player segmentation, treating it as though no recent value exists.
Creating Attributes
Attributes can only be created by backend teams upon request.
System attributes are available by default for new applications.
External attributes must first be requested from Data Engineering (DE).
For External attributes , set the expiration date to ensure the attribute data stays up to date.
The system will stop using this attribute for the player in segmentation after the defined time.
Never : Attribute remains valid indefinitely, with no expiration.
Immediate : Expires right after successful processing if not updated.
Delayed : Custom expiration period; remains valid for a specified time before expiring.
Specify the expiration time in the time fields for days, hours, minutes, and seconds.Custom attributes require alignment with client developers.
Segments
How do we create segments?
Segments are created using attributes, which can be sent by clients, provided by Data Engineering, or available as system defaults.
Segment Example
We’d like to create a segment to target Daily Challenge players.
This means that we’ll be looking for:
Frequent players (for example, using an attribute like
avg_number_of_games_7d >= X)Who play at least 80% of Daily Challenges (for example,
daily_challenge_play_rate >= 0.8)Rarely play Journeys (for example, `journeyplayrate ](/wiki/spaces/KB/pages/2580021328/Game+Settings+Configuration#What-does-priority-and-availability-exactly-mean%3F), which means that if 2 segments have the same attributes, the player will receive the segment that has more priority.
However , the priority set up in Harmony does not apply when using segments in Game Server. This means that the priority of your configurations in Game Server overrides the priority established in Harmony.
Using your Segments in Hawk
Your segments can be used in Hawk in any feature that uses segmentation (Catalos, Campaigns…).
You can find the existing segments for your application in the side bar, in the section Segmentation. In this area you’ll find a table of existing segments with the following information:
Name of the segment and ID
In which entity they’re being used. You can click the name of the entity that uses it to see more details.
Status information (active/inactive, test/live)
Last synchronisation date.
Segments are synchronised once every minute from Harmony, however you can further expedite the process if there is an update by using the Synchronize button.
To use your segments in any feature:
Navigate to the desired feature.
Locate the Segment dropdown and find your segment in the dropdown.
Technical information: Game Server/ Hawk - Harmony Server-to-Server Communication
Game Server and Hawk are connected to Harmony through a server-to-server connection, which means that during the calls from Game Server or Hawk to Harmony, Game Server or Hawk can retrieve and update existing attributes that Harmony will subsequently recalculate in its segments.
Chunks 3
## Introduction
In this guide you’ll learn:
- What is segmentation
- What are the attributes
- Types of attributes
- How to create attributes
- What are the segments
- How are segments configured in Harmony
- Offline segments
- How to use your Segments in GS and Hawk
**Table of Contents**
* * *
## First of all, what is segmentation?
User segmentation is the process of creating groups of users based on specific characteristics.
By identifying commonalities and differences among different user segments, we can develop targeted shop offers, create more personalised user experiences, and ultimately drive better results. With a good segmentation strategy, you can…
- **Personalise experiences**. You can create an experience specific to the player, ensuring they are provided with affordable and attainable goals.
- **Create relevant content**. Surface the right content to players based on the features and benefits that will matter to them the most, especially when considering where they are in the player life cycle.
- **Drive strong perception of value**. Ensure you’re driving the strongest perception of value for your game. This will keep players engaged over time and bring continued monetisation growth as players see value in spending both time and money in your game.
At Tripledot, we use Harmony to slice groups of users and create segments. Once the segments are created, Product Managers can use them to create different catalogs to send customised offers in the game shops, create A/B experiments with your segments, and much more. You can also use these segments in Game Server to create [Rules](/wiki/spaces/KB/pages/2668494860/Rules+in+Game+Server).
**Interested in the topic?**
New to Gaming? Read more about LiveOps [here](https://www.applovin.com/blog/what-are-live-ops-and-why-are-they-important/)! Also,[in this URL](https://www.slideshare.net/GameCamp/live-ops-in-mobile-gaming-how-to-do-it-right) you’ll find an interesting presentation on LiveOps and Segmentation.
Do you want to know more about segmentation? [Here’s](https://medium.com/googleplaydev/user-segmentation-approaches-for-games-4457aa57d56e) an in-depth article about it!
# Segmentation Features
Segmentation is composed of two main features:
- **Attributes**
- **Segments**
Below you’ll find what every feature is and how to use them.
Attributes
### What are Attributes?
Attributes represent the properties of players and their devices, used to define and create audience segments.
There are different categories of attributes:
#### Source-Based Category
- **External attributes:** attributes created by Data Science & Engineering and sent daily to Player Service. One of the examples of External attributes is: avg\_game\_wins\_7d
You can check the examples list [here](/wiki/spaces/DS/pages/2844950582/External+LiveOps+Attributes+via+Data). Please note. This list is not exhaustive.
- **Custom:** attributes created by Client developers and sent immediately to Player Service based on different triggers. Ex: current\_level
- **System attributes:** attributes calculated internally by Player Service. There are 3 main triggers that can be used by the Client team:
| **Trigger** | **Attribute** | **Description** |
| --- | --- | --- |
| **App Open** | Last Login Date | The date and time when the player last logged into the app. |
| | Previous Login Date | The date and time of the player’s login prior to the last login. |
| | Total Session Count | The total number of app sessions the player has initiated over all the devices. |
| | Session Count | The number of sessions the player has initiated in the current time period on each device. |
| **App Install** | Install Date | The date and time when the app was installed on the player’s device. |
| | Install ID | A unique identifier for the app installation. |
| | Account ID | A unique identifier for the player’s account in the system. |
| | IDFV | Identifier for Vendors, a unique identifier specific to the player’s device. |
| | Country | The country where the app is being accessed. |
| | App Version | The version of the app being used by the player. |
| | Platform | The operating system (e.g., iOS, Android) the player is using. |
| | Language | The primary language set on the player’s device. |
| | Time Zone Offset | The difference in time between the player’s local time zone and UTC. |
| **Payment Success** | Average Payments Amount | The average amount of all payments made by the player. |
| | Last Payment Amount | The amount of the most recent payment made by the player. |
| | Last Payment Date | The date and time when the player made their most recent payment. |
| | Last Payment Category | The category associated with the player’s most recent payment (e.g., item type). |
| | Total Payments Amount | The cumulative sum of all payments made by the player. |
| | Total Payments Count | The total number of payments made by the player. |
| | Last X Payments Amounts | A list or summary of the amounts for the last X payments made by the player. |
| | Max Payment Amount | The highest single payment amount made by the player. |
| **LiveOps Events** | LiveOps Experiment Ids | Unique identifiers for LiveOps experiments the player is part of. |
| | LiveOps Experiment Variant Ids | Unique identifiers for the specific variants of LiveOps experiments assigned |
Please note that this is not an exhaustive list of attributes and triggers.
**For QA:**
- IDFV is available as an attribute to facilitate testing
**About System Attributes**
These attributes are processed by Harmony and do not need calculation from the Client. This means that if a system trigger takes place, such as payment success, the Client triggers “Payment Success” which has information about the transaction.
Once the trigger with the transaction data has been received by Harmony, Harmony Server recalculates the related system attributes (average payment).
You can find more information [here](/wiki/spaces/LIV/pages/2748612656/System+Attributes+and+System+Triggers).
As attributes come from different sources, not all of them can be used starting from the moment the player first opens the game. To better visualise the timeline of a player and how the events are created and reported, check the timeline below:
Attributes can be used in Harmony immediately upon data arrival, but segment updates align with the designated start day.
#### Type-Based Category
This classification distinguishes whether the attributes pertain to **players** or **devices** :
- **Player Attributes:**
- **Device Attributes:**
A player can have multiple devices, each with its own attribute values. For example, if we have the attribute "platform," one of the player’s devices might have "Android" as its platform value, while another device could have "iOS."
#### Data Formats
The following data formats are supported:
- **Integer** : Represents whole numbers without any decimal points.
- **Timestamp** : Represents a specific point in time, typically stored in a format like Unix epoch time or an ISO timestamp.
- **Float** : A numeric value that can contain decimal points.
- **String** : A sequence of characters or text.
- **Boolean** : Represents a binary value, typically `true` or `false`.
- **Array** : A collection or list of values, which can include strings, numbers, or other data types.
- **Version** : Typically following semantic versioning (e.g., major.minor.patch).
#### Expiration Dates in External Attributes
External attributes have an expiration setting. There are three options for expiration:
- **Never:** The attribute will not expire, meaning it remains valid indefinitely.
- **Immediate:** The attribute will expire immediately after it is not updated after successful processing.
- **Delayed:** This allows you to set a custom expiration period where the attribute remains valid for a set time before expiring.
The expiration mechanism ensures that the system can effectively manage external data that may become outdated, either by keeping it indefinitely, removing it immediately, or setting it to expire after a set period.
For example, consider the attribute “avg\_payments\_7d”:
- If a player hasn’t made a purchase for 7 days, the data exchange (DE) stops sending values for this attribute.
- If the attribute is set to **never expire** , Harmony will use the last known value for this player when calculating segments, even if the data is old.
- If the attribute is set to **expire immediately** , Harmony will ignore this attribute in the next player segmentation, treating it as though no recent value exists.
### Creating Attributes
**Attributes can only be created by backend teams upon request.**
- **System attributes** are available by default for new applications.
- **External attributes** must first be requested from Data Engineering (DE).
For **External attributes** , set the **expiration date** to ensure the attribute data stays up to date.
The system will stop using this attribute for the player in segmentation after the defined time.
**Never** : Attribute remains valid indefinitely, with no expiration.
**Immediate** : Expires right after successful processing if not updated.
**Delayed** : Custom expiration period; remains valid for a specified time before expiring.
Specify the expiration time in the time fields for days, hours, minutes, and seconds.
- **Custom attributes** require alignment with client developers.
## Segments
### How do we create segments?
Segments are created using attributes, which can be sent by clients, provided by Data Engineering, or available as system defaults.
**Segment Example**
**We’d like to create a segment to target Daily Challenge players.**
This means that we’ll be looking for:
- Frequent players _(for example, using an attribute like_ `avg_number_of_games_7d >= X`_)_
- Who play at least 80% of Daily Challenges _(for example,_ `daily_challenge_play_rate >= 0.8`_)_
- Rarely play Journeys _(for example,_ `journey_play_rate ](/wiki/spaces/KB/pages/2580021328/Game+Settings+Configuration#What-does-priority-and-availability-exactly-mean%3F), which means that if 2 segments have the same attributes, the player will receive the segment that has more priority.
However **, the priority set up in Harmony does not apply when using segments in Game Server**. This means that the **priority of your configurations in Game Server overrides the priority established in Harmony**.
## Using your Segments in Hawk
Your segments can be used in Hawk in any feature that uses segmentation (Catalos, Campaigns…).
You can find the existing segments for your application in the side bar, in the section **Segmentation**. In this area you’ll find a table of existing segments with the following information:
- Name of the segment and ID
- In which entity they’re being used. You can click the name of the entity that uses it to see more details.
- Status information (active/inactive, test/live)
- Last synchronisation date.
- Segments are synchronised once every minute from Harmony, however you can further expedite the process if there is an update by using the **Synchronize** button.
To use your segments in any feature:
1. Navigate to the desired feature.
2. Locate the **Segment** dropdown and find your segment in the dropdown.
Technical information: Game Server/ Hawk - Harmony Server-to-Server Communication
Game Server and Hawk are connected to Harmony through a server-to-server connection, which means that during the calls from Game Server or Hawk to Harmony, Game Server or Hawk can retrieve and update existing attributes that Harmony will subsequently recalculate in its segments.
