How to build a controlled casino loyalty campaign

Apply player eligibility and contact permissions before you build an audience. Record who was eligible, assign a comparison group when the campaign permits it, and check eligibility again at send time. Evaluate repeat visits and net contribution alongside delivery and redemption.

Separate the campaign rules from the audience model

The campaign owner decides the event or loyalty objective, property, channel, approved budget, offer terms and evaluation window. The responsible gaming and compliance teams own the applicable restrictions. Use a rules engine for approved age and jurisdiction eligibility, consent, opt-outs, exclusions and contact limits. Store only the suppression status needed for the campaign, with restricted access to the underlying record.

Cher-Ae Heights announced a launch of segment-based campaign tools with its casino management system. Optimove also documents use of a comparison group in its casino campaign reporting. The American Gaming Association’s code provides an industry reference for responsible conduct. Configure your actual controls with the operator’s compliance owner. Cher-Ae Heights launch · Optimove campaign reporting · AGA responsible gaming code

Record a decision at each handoff

What to automate

Register a campaign and its approvals

Create a versioned campaign brief before assembling members. Record the campaign ID, property, channel, objective, offer limits, budget, send window and outcome window. Attach the approved restrictions, rules version and campaign owner's decision. Require review when changes affect the offer, audience, budget or measurement design. Freeze the version used to generate each release candidate so results can be reproduced.

Assemble the eligible population from approved feeds

Read the certified player crosswalk, channel preferences, and eligibility and suppression decisions available to the campaign team. Join by approved property and player identifiers and check each source's freshness. Store the effective decision version and a limited reason code with each candidate. Hold unresolved identities, missing permissions and stale restrictions for the owning team. Reconcile the total eligible, suppressed and held counts against the reviewed population.

Assign groups and protect the comparison

After eligibility review, assign a comparison group from the approved population using a reproducible method and record the seed and version with the membership snapshot. Check the counts and the campaign owner's agreed balance criteria. Put contact limits and competing offers on the calendar before launch. The owner decides whether overlap or group sizes would undermine the comparison and records changes before release.

Check every recipient again at release

Build a draft export with the campaign version, recipient token and approved message reference. Refresh the contact decisions immediately before each batch and suppress any record that no longer passes. Keep a release key per campaign, member and channel so a retry cannot send twice. Reconcile attempted, accepted, held and rejected rows to channel acknowledgments. Keep unavailable source or ambiguous acknowledgment cases on hold for the authorized reviewer.

Measure visits and costs from the assignment snapshot

At the approved outcome cutoff, join observed visits, redemptions and recorded costs to the original assignment. Show assignment counts, tracked outcomes, missing data and incremental cost on the agreed measurement basis. Review both the difference in visit rates and net contribution after approved variable and offer costs. The campaign owner reviews uncertainty and overlap with Finance before deciding whether to repeat the campaign.

Use rules to determine who can be contacted. A model can draft approved copy variants or summarize results for a reviewer. Keep model output outside the eligibility and release decisions.

Test the campaign with a synthetic cohort

Create five member IDs. One is contactable, one has opted out, one is suppressed, one is awaiting an identity review and one has a stale eligibility record. Only the contactable member should enter the candidate audience. Change that member’s status after approval and before dispatch. The send should be held and the decision should record the later status version.

For a larger synthetic measurement, suppose 40 of 200 assigned treatment members visit, compared with 30 of 200 assigned comparison members. The observed rates differ by 5 percentage points. If the test was randomized and the groups remained comparable, estimate the change with an uncertainty interval. Apply an approved margin definition and include total incremental offer and delivery cost before evaluating whether the campaign paid off. Keep conversions, revenue and net contribution in separate columns.

Build an eligibility and suppression ledger

Store one versioned campaign_candidate(campaign_id, player_key, rule_version, evaluated_at, input_snapshot_id, decision, reasons). Keep eligibility computation, final suppression and outbound delivery as separate jobs. Route synthetic test campaigns to a sink that cannot contact players.

1. Freeze the eligible activity definition and compare segment counts to the campaign brief. Confirm that identity keys from the player system and contact system represent the same profile. Route conflicting identities, jurisdiction and status to the authorized owner.
2. Join approved exclusions from their authoritative systems at evaluation time. Recheck the current suppression status immediately before activation. Keep an unavailable or expired suppression feed as a hard hold, and retain the rule and source versions that explain every exclusion.
3. Approve the list and permitted contact channel independently. Record a release key scoped to campaign, recipient and channel. If the destination request times out, inspect its acceptance receipt or downstream logs before permitting a repeat.
4. Exercise a candidate who becomes excluded after segmentation, a missing suppression snapshot, and a rerun after delivery. Expect no send for the first two and exactly one accepted delivery for the third. Verify the audit log stores only the access-controlled references required for review.

def release(segment_pass, excluded, snapshot_current, approved):
    return segment_pass and snapshot_current and not excluded and approved

assert release(True, False, True, True)
assert not release(True, True, True, True)
assert not release(True, False, False, True)
assert not release(True, False, True, False)

Use code to apply approved restrictions and eligibility. If AI drafts a campaign summary, give it synthetic rows or approved aggregate counts and keep it outside the delivery path.

Implement the work step by step

Freeze the approved audience criteria and comparison cohort before dispatch. Recheck contact restrictions at release, reconcile delivery, and compare visits and contribution over the same window.

1. Define campaign

• CAS-01.01.01 Approve scope and outcome. Version approved inputs. AI may draft briefing. Read Campaign brief, budget and calendar. Record Approved brief to analyst. Owner Marketing and Compliance approve campaign rules. Check The release brief fixes the outcome, observation window and contribution basis.
• CAS-01.01.02 Approve restrictions and content. Enforce rules version and stale source checks. AI draft wording for review. Read Rules, permitted channels, copy, approved terms. Record Signed rules and content version. Owner Compliance owns restrictions and approves final policy and copy. Check Only the approved eligibility, content and restriction versions can enter review.

2. Build audience

• CAS-01.02.01 Resolve eligible source keys. Join source namespaces, hold uncertain records and reconcile total. Read Certified identity feed from CAS-03, memberships and campaign rules. Record Eligible candidates with traceable reasons. Owner Steward handles identity decisions in CAS-03. Check An unknown identity or unresolved account link produces an exclusion reason.
• CAS-01.02.02 Apply suppression and assign cohort. Fail closed on stale status, perform seeded assignment and retain snapshot. Read Current permission feed and approved audience. Record Draft audience and comparison assignment. Owner Analyst reviews cohort skew and any permitted design changes. Check Repeated assignment leaves each eligible subject in one stable cohort.

3. Release outreach

• CAS-01.03.01 Review and approve campaign. Lock the approved version and require recorded approvals. Read Draft audience, exceptions and final offer budget. Record Approved campaign snapshot to delivery. Owner Loyalty manager approves or returns for corrections. Check An edited audience, channel, content or offer invalidates approval of the previous version.
• CAS-01.03.02 Recheck and reconcile dispatch. Confirm rules freshness, use send IDs, hold new ineligible records and reconcile delivery. Read Approved snapshot, current suppression and delivery receipt. Record Acknowledged sends and hold reasons. Owner Operator handles rejection and approved retry. New offer needs approval. Check A newly restricted member stays held at dispatch and the receipt accounts for each attempted send.

4. Evaluate results

• CAS-01.04.01 Join responses and contribution. Reproduce intent-to-treat estimates, missingness and intervals. Read Assignment, visits, redemptions, agreed costs. Record Reviewed results and evidence to owner. Owner Analytics verifies cohort integrity and approved margin definition. Check Missing outcomes remain visible on the fixed cohort denominator and costs use the same window.
• CAS-01.04.02 Decide whether to repeat. Prepare next decision report. AI summarize with links. Read Results with uncertainty and responsible-gaming review. Record Documented decision for next cycle. Owner Manager approves continuation or returns for experiment redesign. Check An inconclusive outcome remains inconclusive and the next run records the approved decision.

Build it yourself with AI

Create fake members.csv, contact_decisions.csv, outcomes.csv and a campaign-playbook.md with the approved gates, expiry windows and sign-off steps. Use five fake member IDs. Make one eligible, one opted out, one suppressed, one unresolved and one stale. Keep real member records and restrictions in approved systems.

From this playbook and synthetic CSV schema, build a Python dry run that creates
eligible.csv and holds.csv with a reason and decision version for each member.
Use only the supplied decisions. Reject missing or stale eligibility data.
Build stable cohort assignment for the eligible rows using the supplied seed.
Emit a separate assignment snapshot and reconcile the input and output counts.
Do not call a messaging endpoint.

Build the release check separately so it can evaluate a later eligibility state. Give the assistant sample receipt and suppression events and have it write idempotency tests.

Build a release preview that reads a frozen assignment and fresh contact
decisions. Require the supplied release approval and hold any changed or
unverifiable status. Simulate a retry and duplicate acknowledgment and verify
the same campaign-member-channel key is counted once. When an acknowledgment
is ambiguous, return a review state. Keep the release file synthetic.

Expect only one member to qualify in the first pass. Change that member to ineligible before the release preview and expect zero dispatchable rows. Use a separate measurement fixture with 40 visits among 200 assigned treatment members and 30 among 200 comparison members. Expect rates of 20% and 15%, then check that missing visits and campaign costs are reported separately.

Draft a review packet from the precomputed cohort totals, costs and missing
tracking counts. Cite the source rows or aggregate IDs. Keep visit rate,
redemptions and net contribution separate. State where the supplied data
cannot support a causal claim. Leave eligibility and release decisions to
the approved policy and reviewers.

Have the campaign and compliance owners compare the outputs with a previous approved workflow. Require named release approval and verify the suppression behavior in a controlled dry run before connecting a channel.

Need help automating this?

Explore the related casino workflows for reconciling player activity and preparing reviewed loyalty worklists. Explore Mage's casino loyalty workflows.