Player Cohorts & Email Campaigns

Two tools let operators act on groups of players instead of one at a time. Cohorts are saved groups of players defined by rules. You can grant a benefit to a cohort and measure whether it worked. Email campaigns send a message to a cohort, optionally with a gift. Both live in the Players & risk section of the backoffice.

Cohorts

A cohort is a name plus a list of rules. A player is in the cohort when all rules are true. With no rules, every eligible player is in. A cohort can have at most 20 rules.

Rules are added row by row in a builder. Each row is a field, a test and a value:

Every field is answered from the main database, so cohorts work without the optional analytics store. A live count of matching players updates as you edit the rules, together with how many players are always left out.

Always left out. Players whose account is not active and players who are self-excluded right now are never counted and never granted to, whatever the rules say. The editor shows both numbers.

Dynamic and static

The kind is fixed when the cohort is created. A cohort can be archived: it leaves the list and can no longer be changed or granted to. Grants already made and their results stay.

Granting a benefit to a cohort

Staff with the Grant bonuses power can give one benefit or catalog reward to everyone in a cohort. The form asks for:

• The benefit or reward. For bonus money, also the currency to pay in.
• Holdout percentage, from 0 to 50. This share of the cohort is left out on purpose so you can tell later whether the grant changed behaviour. Who is held out is drawn at random when the grant runs. With a holdout of 0 the grant cannot be measured, and the form says so.
• A reason, recorded on every player's grant and in the audit log.

Before you confirm, the form shows how many players are in the cohort, how many are held out, how many will receive the grant and its estimated cost in USD (players receiving it times the reward's top value).

Grant budget cap. Each grant is limited to an estimated cost of USD 1,000 by default. A grant over the cap is refused, so one mis-clicked grant cannot spend an unbounded amount. The cap applies to every cohort, per grant, and only an admin can change it (on the Cohorts page).

How it runs. Confirming queues the grant, and a background job picks it up within a minute. It pays each player in turn and checks them again at that moment. A player who has become inactive or self-excluded since is skipped. A player who hit a grant limit is recorded as failed. Every payment carries a stable request id, so a job that stops and restarts never pays anyone twice. The cohort page lists each grant with its status (queued, running, done, failed) and counts of delivered, skipped and failed players.

Measuring results

For each grant, a results page compares the players who got it with the holdout. It becomes available 7, 14 or 30 days after the grant started, and shows per player:

• the share who played again,
• deposits (USD),
• NGR (USD).

Players with no activity count as zero. A difference is called higher or lower only when its 95% range clears zero. Otherwise the page says too close to tell, and with fewer than 30 players in either group it says too few players to tell. Simulated players count like any other.

Email campaigns

A campaign sends one email to a saved cohort. It is built in five steps:

1. Audience. A name (staff only) and the cohort. The page shows how many players will actually receive the mail and why the others are left out.
2. Content. A subject (one line, up to 150 characters) and plain text (up to 5,000 characters; a blank line starts a paragraph). The greeting is the player's username, else first name, else "Hi there". The last name is never used, and there are no merge fields.
3. Offer. An optional button that opens a live promotion in the casino lobby or a page on your own site. The click never changes anything for the player. An optional gift gives the audience a benefit or catalog reward first, with the same holdout, reason and budget cap as a cohort grant. Gifts need the Grant bonuses power.
4. Schedule. Send now or at a set time (UTC).
5. Review. A preview of the email as the player gets it, a test send to your own address (it does not run the gift), and a checklist.

Campaigns need the Email campaigns area on the staff member's role.

Consent rules

Marketing mail is sent only to players who pass every rule below. The audience estimate reports how many were left out for each reason.

The rules are checked again for each player at the moment of sending, so a player who unsubscribes after launch is not mailed. Holdout players get neither the gift nor the email, and with a gift only players who actually received it are emailed.

Marketing consent by region

Players in the EU, the EEA and the UK start with marketing email off, because those regions require opt-in consent. Everyone else, including a player whose region could not be determined, starts opted in. Existing players in those regions were opted out when the rule shipped. Players change the setting in their Preferences.

Unsubscribing

Every campaign email carries an unsubscribe link and the standard one-click unsubscribe header, so mail clients can offer an Unsubscribe button. The link opens a public page that needs no sign-in and asks the player to confirm. Opening the link alone changes nothing, so mail scanners cannot unsubscribe anyone by accident. Confirming turns off the player's marketing email. A spam complaint does the same automatically and suppresses the address.

Sending and results

Launching a campaign freezes the audience at that moment: the cohort is picked again, the gift (if any) runs, and then each player who received it is mailed. A background job runs every minute to launch due campaigns and send queued mail in pages. Sending is at-most-once: a send whose outcome is unknown is closed as failed rather than repeated.

A scheduled campaign can be canceled until it launches. Canceling one that is already sending skips the mail not yet sent; mail already out and a gift already delivered stay as they are.

The campaign page shows sent, delivered, bounced, complained, clicked and unsubscribed counts, who was not mailed and why, failed sends, the gift's results and the email exactly as players received it. Delivery, bounce and complaint figures come from the mail provider's notifications and are filled in only when those are connected. The list of campaigns can be filtered by status, audience cohort and gift.

Granting to selected players

Cohorts are for groups defined by rules. To reward specific players, select them in the Players list and choose Grant benefit. One action grants a benefit or catalog reward to up to 100 selected players with a single reason. Each player is granted separately and idempotently, and a player who cannot be granted (for example one who hit a grant limit) is reported without stopping the others. Every grant is announced to the player and written to the audit log. See Gamification & Rewards.

Scope & Roadmap

Implemented. Dynamic and static cohorts with the rule builder and live counts. Benefit and reward grants to a cohort with a holdout, a pre-run cost estimate, an admin-set budget cap, an idempotent background run and results at 7, 14 and 30 days. Email campaigns with audience estimate, preview, test send, optional button and gift, scheduling, cancellation and delivery stats. Consent checks, region defaults, bounce and complaint suppression, and public one-click unsubscribe. Selecting players in the list to grant them a benefit.

Partial. Delivery, bounce and complaint tracking depends on the mail provider's event notifications being connected. Cohort rules read the main database only, so there is no rule on in-play behaviour such as favourite sport or game.

Not built. The only grant type is a benefit or catalog reward. A cohort cannot be used as a trigger for ongoing, automated messages. Campaigns are single emails, with no sequences, no A/B variants and no SMS or push channel.