Use out-of-game campaigns to encourage players to return to your game. For example, send campaigns as email or push notifications to incentivize players with a gift or reward.

Before you create the campaign you’ll need to create at least one campaign action, and any player segments you wish to target with this campaign.

You can configure sequences of actions, a conversion event and even looping campaigns.

Creating an out of game campaign

Click Create Campaign on the campaign management page, select the type of campaign you would like to create, and you’ll be brought to the campaign creation wizard.

Note: If you still see the legacy UI, each campaign type will have their own individual campaign management page.

The campaign creation wizard guides you through the steps needed to launch a campaign.

Creating an out-of-game campaign

To create a new campaign:

  1. In the Campaign Management page, select Create Campaign.
  2. Choose the type of campaign you want to create.

Follow the steps in the sections below to set up your out-of-game campaign.

Name and description

Give your campaign a name and description that will be relevant in your analysis and reporting.

Selecting eligible players

Specify which players are eligible for your campaign.

The segment is which players to target in the campaign – in this case we have selected all players.

The exclusion segment is which players to exclude from the campaign – in this case ‘Whales’ who have spent more than $100 in the game.

You can also exclude players who are not eligible for specific out of game actions – in the example above we have excluded players who are not eligible for push notifications.

Note: For out of game campaigns, when users exit a segment they’re no longer eligible for the campaign.

Campaign timescale and delivery time

You can configure campaigns to start immediately or some time in the future, set to run until a defined date or forever (until you pause or delete it) and the delivery timezone can be set.

Important: Campaign timescale dates and times run in UTC, but the date time selectors in this interface will reflect your local time, so remember to offset any time settings if you need to.

Campaign priority and player reset conditions

The Player Progress Reset option resets a player’s progress in a multi-step campaign. This effectively removes them from a campaign and resets them back to the start.

The rules of engagement priority score lets you prioritize the order of your campaigns, lowest to highest, as a player may qualify for more than one campaign but your global rules of engagement may specify that only one message can be delivered per day.

A/B testing

You can specify if your campaign should run as an A/B test or not by toggling the A/B Test button.

If you enable A/B testing a second panel will appear with options that will let you define the number and size of the variant groups in your test. The variant size of all groups must add up to 100%.

The variant properties option lets you define properties that will be used by the dynamic replacement engine when your content is delivered. For example, you might have two teams: “Cops” and “Robbers” and you could use the variant properties to populate part of the message text based on your A/B test variant properties.

Specifying campaign actions

Each campaign can have multiple steps and each step can have multiple actions. Use the Add Action and Add Step buttons to populate the steps and actions.

Our example campaign is an A/B Test with different content created for each variant. On Step 1 we have separate iOS and Android content to deliver and we have two versions of each, A and B. The content delivery setup for step 1 will look like the following:

We’ll consider the campaign a success if the player returns and starts playing the game, so the conversion event for Step 1 will be for the player to record a gameStarted event after receiving this message. This can be set on the Conversion tab for Step 1.

You can also use the “Add Criteria” button to add further refinements to your conversion event. For example, a message to encourage the player to purchase a particular offer item may look for a transaction event as the conversion event and have an additional productID == XYZ criteria attached to ensure the player only converted if they bought the offer item.

The conversion window allows you to define the period in which the player is eligible for conversion. For example, you might want to specify that the user can only convert three days after receiving the message or offer. This can be used in combination with the “Cooldown Calendar Days” and “Cooldown Play Days” fields in the step behaviour tab to define complex step lengths and conversion windows.

Having a cooldown allows you to define the time the player should be left in the step before moving to the next step. This is independent of the conversion window but they can be used in unison.

The cooldown calendar days is the number of calendar days the player should stay in the step before moving on whilst the cooldown play days is the number of days the player must be active before moving to the next step. An active day is any calendar day in which a gameStarted event is received for that user.

The cooldown period is added to the conversion window and this defines the entire step length. Naturally, this can change depending on which cooldown limit is hit first – the play days limit can be hit before the calendar limit and at this point, the player would move to the next step.

Our campaign is going to have three steps with escalating offers to each variant. Click + on Step 2 to create an empty Step 2, then populate it with actions and conversion details, Do the same for Step 3. With each new step added, the number of days to wait since the previous step can be specified. We’re going to say two days to progress through the steps on alternate days.

There is an additional Add Action button within the conversion tab. This will let you trigger actions to each variant, if the player converts. This can be used for a delivery confirmation, reward or a thank you message.

You can add as many steps as you need. Save your campaign and check the details on the confirmation page before pressing START.

Tip: You can save a campaign and return to it later to make changes. This is useful if you need to confirm some of the settings or if multiple people are working on the configuration. However, the campaign will not run until you select start.

Once a campaign is running you can use the report builder at the bottom of the campaign summary page, or any of the analysis tools to build reports based on this campaign. Out-of-game messaging uses a variety of automated events to track campaign targeting, delivery, open rates etc. Make sure you have the relevant events in your event schema so you can build analysis and reports on your campaigns:

  • an outOfGameSend event is sent automatically each time the Out Of Game messaging system tries to send an email or push notification message. It’ll contain details on the player, campaign, cohort, action, step ID, message type and crucially the communicationState and communicationDetails parameters will reveal if the message was SENT or a FAIL and reveal the reason if there was failure. If a user is selected by a campaign but doesn’t have a necessary identified for the specific Action type the communicationSender field of the outOfGameSend event will be populated with a value of UNMAPPED. For example, if a player is picked up by a lapsed user campaign and scheduled to receive an iOS push notification but they don’t have a pushNotificationToken.
  • a sendGridEmail event will be sent automatically from the sendGrid email platform to indicate delivery success or failure along with other state changes such as Open, Click etc. This event can be used to measure the click through rate and conversions on your campaigns.
  • notificationOpened events will be sent be the deltaDNA SDKs when your game is launched from a push notification. This event will also contain a campaignID parameter if the game launch was a result of a push notification originating from deltaDNA. Please note, that this event can also be triggered by push notifications that originate from other push notification suppliers. Be aware that some other SDKs, particularly from attribution companies, will use push notifications to track uninstalls. They might also try to hijack the notification callback methods in the game. Be sure to test on DEV for your particular game configuration.