Basic concepts and entities

This section provides a description of the concepts

  • Clients
  • Reward points
  • Badges and quests
  • Tags, events
  • Products and product categories
  • Variables


One of the key features of the SailPlay platform is the ability to work with your customer's data. The SailPlay CRM works with the following principles:

  1. The primary client identifier - phone number (user_phone) or email (email) is used depending on the main identifier you have selected. To change the primary identifier, please contact our support team.

  2. Additionally, the origin_user_id parameter can be used if clients have a unique customer ID in your system. SailPlay applies no constraints on this parameter, so it may contain any number or a string. The only limitation is the uniqueness of this field for each individual client. As origin_user_id we recommend the use of the following value: md5(ID in your system + md5(public_key)).

  3. All API requests for customer identification can utilize phone, number or Email, depending on the chosen primary identifier. If the origin_user_id is not tied to a phone number or email, you will need to add a matching phone or email in order to allow the client to log into their account. 

  4. For all new phone numbers, emails or origin_user_id, which were not found in SailPlay, the system will create accounts that are in an unconfirmed state. These accounts will be confirmed after the user confirms the possession of one of their IDs.

SailPlay offers two ways to work with your user base:

  1. Through your affiliate account on

  2. Through the SailPlay API.

Reward points

SailPlay has a mechanism for bonus points calculation for any user action. An example is a customer review, social action, or any other action on the client's side.

There are two options for point scoring:

  1. Manual addition through the partner's office

  2. Bonus point accrural implementation through the SailPlay API.


Tags and events in the SailPlay system are different applications of one entity and are closely linked to triggered chains.

Tags are specific qualities that can be assigned to customers. Tags are used for customer segmentation and triggered chain activation.

Tags come in three types:


Flag tags can be assigned to a user only once. If the flag is sent to the user account for the second time, all actions associated with it will be skipped. Typical applications include the following events: registration, first purchase, subscription, etc.


Counter tags can be assigned to users several times and collect information about the number of times the tag was assigned. Moreover, triggered chains associated with counter tags will be fired every time the tag is assigned again. Typical applications include the following events: making a purchase, leaving a comment and purchasing a product from a specific category.


Sum tags are utilized in the same way as counters, however, instead of storing the number of times they were assigned, they store the value that was passed with the assignment request. Typical applications include the following tags: the sum of purchases, total sum of bonus points earned, etc.

Badges and quests

Badges and quests, along with bonus points and events, are based on the service gamification.

Badges   - A virtual reward that the customer may receive. Badges may be created in groups (chains) or be single. If the badges form a chain, they should be acquired sequentially, meaning that the third badge in the chain cannot be acquired before the second, second - before the first and vice versa.

Events - events are the actions that occur on the client's side or in any place that they can be captured (e.g. in a mobile application) - customer registration, a comment being posted, etc.

Customer events - a list of all events that have been performed by the user.

Badge acquisition rules  - a set of rules, after completion of which the user will receive an appropriate badge. Rules can be chosen for all types of tags, it the flag tag is chosen, the customer will meet the rule by possessing said tag, for counter and sum - by surpassing a specific threshold. After all rules associated with the badge are met, and all badges preceding the badge in the badge chain are received, the customer will receive the next badge.


Cart and product categories

SailPlay implements a mechanism for working with product categories and product carts. Integration with this mechanism is necessary in the following cases:

  1. When it is necessary to implement the logic for different rules of bonus points acquired for different products or different categories.

  2. To conduct analysis and statistics related to the cart content.

Principle of operation

Each item in SailPlay should have the appropriate product identifier in your system (SKU). Similarly, each category in the SailPlay system have the appropriate category identifier.

For each product category, you can specify the following:

  1. Name

  2. Identifier

  3. The custom conversion rate of dollars to points for the purchase of products from this category

  4. Picture

All purchases sent to SailPlay should include the information about the cart content in order for the system to calculate the bonus points correctly (see. here).

When the cart is parsed by the system, the following rules apply:

  1. If an item with the SKU or a group with the ID is not in the system - they are created automatically (without names and attributes).

  2. Custom point conversion rates are used for products in the following priority: product conversion rate - category conversion rate - default conversion rate.


One of the basic features of SailPlay Sender is the ability to assign variables to users.

Variable is a stored string value that can be used in emails and triggered chains.

For example, the variable $[first_name] will be replaced by the recipient's name when used in the Email.

Variables can be used in Email and SMS campaigns, as well as the triggered chains.

Variables can be used anywhere in the message - body, title, or link addresses.


SailPlay system implements four types of variables:

  • System Variables - contains general information about the client and actions performed.

  • Custom variables - contains additional information about the customer. Variable values ​​are stored separately for each client.

  • Variables linked to the tags - contains additional information necessary for the operation of a specific tag. The values ​​of these variables are stored separately for each tag.

  • Global variables - contains information that is not tied to any tags or users.

When using any variable, you can specify a value that will be substituted if the variable is missing or its value is not defined.

Also, a replacement mechanism can be implemented through the conditional construct.

replacement syntax:

$ [Var | replacement]

Where var - variable identifier

replacement - string which will be substituted for the variable value

Example of use:

$ [Global_vars [ "var1"] | replacement text]

For the advanced usage tutorial, refer to markup templating