ChilliConnect's Live Ops tools allow you to dynamically alter your game's Catalog at runtime for specific player segments. This can be used to deliver different in-game assets to specific device types, toggle country or locale specific features, perform tests to optimise KPIs, or run time-limited offers and promotions.
ChilliConnect offers three key features that allow you to run Live Ops:
|A/B Tests||Designed for running optimisations on a limited group of players, recording and analysing the affect on KPI metrics, before you roll changes to your whole player base||Modifying the amount of starting currency each player receives, or the rate at which they accumulate currency, to determine which has the most positive affect on conversion rate and retention.|
|Permanent Overrides||Used to make changes to your Catalog at runtime based on player attributes that are "permanent", and not time bounded.||Disabling certain features by locale, or making certain offers available to players once they have spent a certain amount in game.|
|Scheduled Events||Running time-limited promotions, offers or seasonal events||Running a weekend sale in a particular territory, or offering free gifts to players during a holiday season.|
By design, a player can only be assigned to a single AB Test at a time, but can have multiple Permanent Overrides and Scheduled Events defined. These three functions are loosely referred to as Campaigns and each share a similar workflow that is described below.
The general workflow for Campaigns is the same. On login, players are assigned to available Campaigns based on the campaign status and the configured Segmentation settings. Once assigned, any Catalog Overrides defined by those campaigns are layered on top of the base Catalog definitions to form the definitions that the Player receives in-game. For a simple setup it could be that a couple of sets of definitions are in use for an entire player-base, equally more complex systems could see hundreds of Override combinations, all of which ChilliConnect handles seamlessly for you.
The set of assignments holds constant for the duration of their Session. This way the Catalog definitions can be downloaded and cached on the device, and interactions with the server will be consistent.
Catalog definitions are the combination of the Campaign Overrides layered on top of the base Catalog. Definition conflicts and priority are handled at Campaign creation time.
The segments tab allows you to filter a Campaign to specific players only. By default, the Campaign will match all players and segment criteria must be specified by selecting the check box next to each category. To be included in a Campaign, a player must match at least one criteria in all categories.
ChilliConnect supports a number of built-in segmentation properties out of the box:
|Location||The location of players to take part in this campaign. Locations can be inclusive ("Only players in these countries") or exclusive ("Every player apart from those in these countries")|
|Device Types||Device Types that are to be included in this campaign. Player must have at least one of the selected device types to be included. For example, a player that has recorded both iOS and Android would be included in an Android only test and an iOS only test, regardless of what device they are currently logging in with.|
|Platforms||What device platforms should be included in the campaign. As with Device Types, it is important to remember that a player who has matched against any platform previously will be included - the check is not limited to the device the player is currently logged in with. This is to ensure data consistency for the player if they are playing on multiple devices.|
Device Models to be included in the campaign. This is provided free form so rather than specific models being selected, one or more patterns can be defined. Like other categories, the player just needs to match at least one pattern. So to include Samsung and LG devices, you could add 2 separate criteria for
|Install Date||The original date that the player first installed the game, specified in UTC, with optional time. Can be defined as absolute or relative time period. If using relative, ChilliConnect defines a "day" as 24 hours.|
|Previous Login||The players last login date, excluding the current login. This can be used to target players that have returned to your game after a long absence. Can be defined as absolute or relative time period. If using relative, ChilliConnect defines a "day" as 24 hours.|
|First Purchase Date||The date that the player first made a purchase, specified in UTC. This criteria will exclude players that have never made a purchase. Can be defined as absolute or relative time period. If using relative, ChilliConnect defines a "day" as 24 hours.|
|Last Purchase Date||The date that the player last made a purchase, specified in UTC. If a player has only made one purchase, this will be the same as First Purchase Date. Can be defined as absolute or relative time period. If using relative, ChilliConnect defines a "day" as 24 hours.|
|Conversion||Whether or not the player has converted.|
|Total USD Spend||The total amount of real world currency, converted to USD at the time of purchase, that the player has spent in game.|
|Purchased Store Item||Whether or not a player has purchased a specific IAP, specified by the store item name. Can specify if a player has purchased a specific item once, more than a number of times, less than a number of times, or never. If multiple criteria are specified, the player must match all of these.|
In addition to the core segmentation properties defined above, it is also possible to segment players based on custom, game-specific properties using Player Properties. Depending on the type of the Player Property, the following segmentation options are available:
|String Properties||Can specify that the property string value must match one or more of the defined patterns.|
|Date Properties||Can specify that the date must match the defined criteria, including on specific date, before a date, after a date, or between a range of dates. Can be defined as absolute or relative time period. If using relative, ChilliConnect defines a "day" as 24 hours.|
|Integer Properties||Can specify the integer value equals, is greater than, less than, or within a specific range.|
|Boolean Properties||Can specify if the boolean value should be true or false.|
Overrides allow you to easily define changes to the Catalog. Items can be added, removed and updated. Overrides are automatically applied for Players based in their assigned Campaigns when retrieving the item definitions or downloading the Catalog package file. This means that no additional logic is required in your game to support overrides. For a detailed example, see our A/B Testing tutorial
Items can be added to the list by clicking on the Add Override button, clicking on the type of the item and then clicking on the item name.
Items can be edited by clicking the text in the table for the item you want to change and the group you want to change it for.
Changes to the catalog can be viewed by clicking the Diff button below the test. This will open a dialog with two JSON representations of your catalog. The one on the left is the original and the one on the right is with the overrides applied.
Two Campaigns are in conflict if they have an override for the same Catalog item. As you can imagine layering multiple sets of Overrides there is the possibility that some of those Overrides may conflict with one another. When a set of Overrides is created (usually on Campaign creation) ChilliConnect calculates a list of these conflicts. This list is presented in the Prioritisation tab.
Campaigns are assigned in the order defined in the Prioritisation list. Where conflicts occur the first Campaign will take precedence and subsequent conflicting Campaigns will not be assigned. For example, two Permanent Overrides A and B conflict on a definition. Permanent Override A is prioritised above B. For players that meet the criteria for both Campaigns will be assigned A and not B.
This conflict behaviour applies between different types of Campaigns equally. However an A/B Test will only be considered for assignment if the Player isn't already assigned to an A/B Test. Assignments continue down the prioritisation list following a conflict, observing the same conflict resolution behaviour for any additional conflicts detected.
Players are assigned to Campaigns upon login and initial creation. A player is assigned a Campaign for the duration of their session. Assignment will occur again at the next login event, at which point a additional Campaigns may be assigned, and existing ones unassigned in the case of Permanent Overrides and Scheduled Events. Once a player is assigned an A/B Tests, they are only unassigned once the test ends, regardless of changes to the segmentation criteria.
Cloud Code "Logins"
In some cases, it's possible to run Cloud Code under the context of a player - such as Event Scripts (Match Started, or API Events for example) or through the Scripting API asPlayer method. Like all sessions these perform a Campaign assignment event, however as they are not a device session, a notable difference is that these sessions will not have the session-start segmentation parameters available to them (device type, platform, etc).