An overview of all your automated projects in one place. Here's a run through of the awesome components that make up your lifecycles.
Automated projects naturally fall into categories and so we organised it just so. Here you have all your automated lifecycles handy in one place to give you the ultimate control. All lifecycle projects will belong to one of the following categories;
We understand that flexibility is important. If you're not sure exactly which category your latest project falls into, you can choose to build a custom lifecycle instead.
We’ve created pre-defined templates already set-up for you to easily build your lifecycle. They define the flow of the lifecycle and are customisable to your needs.
Lifecycle templates are there to provide inspiration. We believe they capture the most important aspects of the player journey. If you don't know where to start, take a look at the templates available and start incorporating them into your CRM activity.
In case you already have a pretty good idea of what you want to create; take a template and modify or create your own from scratch.
Depending on the template selected, the lifecycle entry conditions will differ.
The Launch trigger and segment, or Entry Conditions, are the defining actions that allow players to enter the lifecycle. Lifecycles need a trigger and segment in order for them to work. This is the activity that allows players to enter your lifecycle.
Depending on the template you select, the trigger and segment may have a default selection or may need to be defined. Regardless, you can change that according to how you want the settings that feeds players into your lifecycle.
Example: NRC to NDC templates comes with default entry conditions of Successful Registration (trigger) and All Players (segment).
You can change the segment to select only players from a particular country of registration, as we advise to set-up onboarding lifecycles per market.
Create different versions of your lifecycle as you keep getting better. You can set up multiple versions of one lifecycle as you evolve, if you want to AB test or simply to keep up with changes.
In Lifecycles we work in versions. The first version created within a new Lifecycle will automatically be called Version 1. Makes sense right.
Change the name of the lifecycle or version whilst in IN DEV to highlight to others what is inside. It is good practice to name Lifecycles and each version clearly to make it clear what is inside and what makes it different from other versions.
Once a version is approved from QA it should not be edited. Instead we make changes to a new or cloned version and run the new version instead. We understand that over time things can change. As it does, create a new version of the lifecycle to start using instead of or alongside version 1. You can create multiple versions of your lifecycle and use more than one at any time.
Found out more;
Lifecycles are made up of events that define a moment in time when something occurs.
Each event consists of the trigger, split audience and activity slot;
To give you a helping hand, some events in each lifecycle are already outlined, if you choose one of the pre-defined templates. These are the events that we think are important. Edit, add, drag and drop and delete to customise the lifecycle exactly as you want to have it.
An entry event adds the player to the lifecycle (e.g. successful registration) and the exit event is the action that removes the player from in the lifecycle (e.g. successful deposit). All the events (entry events, during events and exit events) are customisable to your needs.
Learn how to build lifecycles;