Player Information
Customer information is crucial for CRM (Customer Relationship Management) systems when it comes to sending marketing campaigns for several reasons:
-
Personalization: By understanding customer preferences, purchase/gaming history, and behavior patterns, PEP can help personalize marketing campaigns. Personalized campaigns are more likely to resonate with customers, leading to higher engagement and conversion rates.
-
Targeting: Enable businesses to segment their customer base, based on various criteria such as demographics, interests, or purchase history. This segmentation allows for targeted marketing campaigns tailored to specific customer groups, increasing the relevance of the messages delivered.
-
Timing: Can track customer interactions across multiple channels and touch-points, helping businesses identify the most opportune moments to engage with customers. Sending marketing campaigns at the right time can significantly impact their effectiveness and improve overall customer satisfaction.
-
Retention: By analyzing customer data through segmentation and analytics, you can identify at-risk customers or those who may be ready for additional products or services. Targeted marketing campaigns aimed at retaining customers or encouraging repeat purchases can help increase customer loyalty and lifetime value.
-
Feedback Loop: Facilitate the collection of feedback and data from marketing campaigns. By analyzing campaign performance metrics and customer responses, businesses can gain valuable insights into what resonates with their audience and continuously refine their marketing strategies for better results.
Customer information is vital for PEP to send effective marketing campaigns because it enables personalization, targeting, timely engagement, retention efforts, and continuous improvement through feedback analysis. During this chapter we are going to guide you to properly understand how to send data to PEP and best practices.
Player Information
PEP allows you to properly create new customers/players in our data store; PEP requires at least the following information to work:
- Player ID: Unique player identifier
- First Name: Player First Name
- Last Name: Player Last name
- Gender: Player Gender useful for customizable marketing campaign greetings
- Phone number: Mobile phone number for campaigns through SMS channel
- Email: Player email used to send campaigns through Email channel
- Username: Username of the player. If the player doesn't have a username, you can use the player's email
- Language: Player Language to properly address campaigns based on the player language
- Currency: Based player currency
- Birthdate: Player birthdate useful for happy birthday campaigns
- Nationality: Player nationality for demographic targeting campaigns
- Address Country: Player country for demographic targeting campaigns
- Address City: Player country for demographic targeting campaigns
- Address Street
- Address Postcode
Our platform allows you to register, update or delete player's information in real time through our players Rest API.
You can find the Open API specification for a Player Information here:
You don't need to register the player information to make PEP work, but you are going to have limited options in the CRM; for example, for segmentation or in template's customizable placeholders.
Delete Player
This section outlines the processes for deleting player data from the system. The deletion functionality is divided into two operations: Soft Delete and Hard Delete.
Soft Delete
The Soft Delete operation moves the player into a separate collection, effectively excluding them from:
- Queries
- Reports
- Any operational workflows
This ensures the player’s data remains in the system but is not actively processed or visible in any front-facing applications.
Hard Delete
The Hard Delete operation permanently removes the player’s data from the system. However, the deletion occurs 48 hours after the request is initiated, allowing time for cancellation if necessary.
Key Points:
- Cancellation Option:
- You can cancel the hard deletion request using the cancel-deletion endpoint within the 48-hour window.
- Canceling the hard delete retains the player’s soft delete status.
- Irreversible After 48 Hours:
- Once the 48-hour window has passed, the player’s data will be permanently removed from the database and cannot be recovered.
Notes
- Ensure proper authorization for all delete requests.
- Hard delete operations are irreversible once the 48-hour window has passed.
- Soft delete ensures data is preserved for compliance and auditing purposes.
Here the Open API Specs for player delete operations:
Additional Player Information
On the other hand, if you have additional information that is not listed in the basic player information, we have you covered. PEP has a custom data section for each player, so you can send any additional information that may be required for:
- Better Marketing campaigns targeting
- Improved Personalization
- Market Regulations
Our custom Player Data module allows you to send five kinds of data types:
string
: represents a sequence of characters. A string is used to store and manipulate text datanumber
: represents a numerical data value, including integers and floating-point numbersboolean
: represents a binary value indicating either true or falsedate
: represents a date data type expressed in RFC 3339 formatoption
: represents a data type that can be enumerable, like status, tags, etc
The custom player information can be added directly in the Players Integration API or using this specific API to add/updated player custom data.
Let's see it in action through an example:
Assume that you have a player registered with ID: 00000000-0000-0000-0000-000000000001


And you need to add the following properties to this player:
- Is VIP: data type boolean
- Max Bet Amount: data type number
- Account Status: data type option (enumeration)
Let's see an API request example to add those properties to the player and how those properties are displayed in PEP:
Show me the code!
import axios from 'axios';
const axiosInstance = axios.create(...);
/**
* Send a request to update player, adding extra properties
* for playerID: 00000000-0000-0000-0000-000000000001
* API Spec: @url: https://docs.gamanzaengage.com/docs-api/platform-rest-api/player/players-controller-upsert-player-custom-data
*/
this.axiosInstance.patch(
'https://customer-domain.gamanzaengage.com/api/players-data/v1/players/00000000-0000-0000-0000-000000000001/custom-data',
{
customData: [
{
name: 'is_vip',
type: 'boolean',
value: 'true',
},
{
name: 'maxBetAmount',
type: 'number',
value: '200',
},
{
name: 'accountStatus',
type: 'option',
option: {
selected: ['1'],
type: 'single',
allowedOptions: [
{
key: 'provisional',
value: '1',
},
],
},
},
],
},
);
The value of each property should be defined in the string representation.
Take into consideration that type validations are performed to ensure data consistency. For example, if you define
the maxBetAmount
as a number but you send a string value not numerical or a non valid numeric string value, the
request will end with an HTTP status code 400:
{
"message": "Bad Request Exception",
"request": {...}
"details": {
"faultCode": 400,
"fields": [
{
"field": "1.value",
"error": "value must be a number string"
}
]
}
}
Let's see the result in the Player Card in the Admin UI:


As you can see in the previous image, the three new properties have been added to the player (last three properties in the player data section in the player card). PEP is capable of understanding the data and giving the proper context if you define the proper data types, this happens in real time, and a lot of things are now enabled in the platform (more in a moment).
Custom Data - Data Types
Now lets go in depth through each property data type and see the capabilities that are enabled in the CRM.
Type boolean
From the previous example:
{
name: 'is_vip',
type: 'boolean',
value: 'true'
}
The name of the property can be any valid programming language variable format: CamelCase, PascalCase, snake_case, kebab-case, UPPER_CASE. Internally the PEP platform creates a proper human-readable display name as you can see in the following picture:


The next part is the type. The type defines how the platform handles the information internally and sets the proper type in the data store. It also enables the interactions for segmentation and email templating for the placeholders.
For example, this is what you can see in the Segmentation Builder for the property Is Vip:


At a glance, the CRM presents easy to use human-readable information for the operators to easily allow them to understand and interact with the data; the value is actually stored as a "primitive" boolean.
Type number
The type number represents any numerical value:
{
name: 'maxBetAmount',
type: 'number',
value: '200'
}


Internally PEP stores the value as a "primitive" number, int/float, enabling specific filter options for numerical segmentation:


Type date
The type date allows you to represent date property values:
{
name: 'lastSelfAssessment',
type: 'date',
value: '2024-03-27T23:18:59.911+00:00'
}


Internally PEP stores the value as a "primitive" date value, enabling specific filter options for dates in segmentation:


Type string
The type string allows you to represent text property values:
{
name: 'riskEvaluationResult',
type: 'string',
value: 'Low risk, healthy habits.'
}




This type of property is useful for sending specific campaigns and can be used in templates:


Type option
The type option is a special field to define enumerable properties. This data type allows you to send information that may be related to an internal database unique identifier, and you need to give some context to your admin operators to understand the data. Let's see an example.
Imagine that you have a property for your players called Account Status, this property is defined in a DB table in your system as follows:
ID | name |
---|---|
1 | provisional |
2 | active |
3 | blocked |
You can send the values as string or number properties, but you enforce your operators to manually set these values in segmentation. If you send the account statuses as options, you will reduce the usage complexity for your operators:
{
name: 'accountStatus',
type: 'option',
option: {
selected: ['1'],
type: 'single',
allowedOptions: [
{
key: 'provisional',
value: '1',
},
],
}
}


To give the proper context to the PEP data analyzer, you need to set the allowedOptions
in the option payload object,
you don't need to send all the available elements in your db in each request, PEP automatically tracks for changes, and
internally updates according to the data that you send.
This results in the following experience, for example, to create a new segment for players with specific account statuses:


🤗 The more context you define to the data, the better the experience will be for the Admin casino operators.
All the data that you send to PEP is read-only for PEP, which means we never allow operators to edit or modify this information from our Admin UI. You, the integrator, are the sole source of truth for PEP.
❗ We rely on you to keep the data in sync.
Data types are essential for handling information in programming and are used extensively in a wide range of applications. But more importantly, if you define the data types accordingly, you enable a great and easy user experience for the Admin Operators that may not have depth understanding of programming data types, and allow them to create anything from simple date calculations to complex scheduling algorithms and data analysis tasks. Understanding how to work with data types and perform data-related operations is crucial for developing engagement mechanics.
Happy integration!