An email address is how you reach a player. It is not who the player is. Two spouses with one inbox and two club cards are two players with two tiers and two offers, and a system keyed on the address cannot even hold both of them. The casino already has the key that can.
Every marketing database has one field that decides whether two records are the same person. General-purpose email tools use the email address, because it is the only identifier they have. A casino has a better one, issued at the players club desk and stamped on every rated hand and every comp since. The difference shows up first, and hardest, in the most ordinary household in the database: a couple who share an email address and do not share a players club account.
A primary key has four jobs, and it has to do all four or the data it holds together comes apart.
None of this is a criticism of email as a channel. It is a description of an email address as an identifier, which is a job it was never designed for.
It changes. People change jobs, change providers, abandon an address the spam got to, or simply start using the other one. In an email-keyed system, a player who comes back with a new address is a new record: a fresh profile with no history, no tier, and no memory of anything they told you. The old record does not go away either. It sits there, still receiving offers meant for a player who now exists twice.
Two players, one inbox. This is the big one, and it is why casinos in particular cannot live with an email key. In our experience a meaningful share of players club members share an address with a spouse. Each spouse has their own club account, because club accounts are personal: their own rated play, their own points, their own tier, their own host, and their own offer calculated from their own worth. One of them may be Platinum and the other Bronze. One may have opted out. One may be self-excluded. An email-keyed system has one record for that address, so it can hold one of those people, and it holds the one who happened to sign up first. The second spouse either cannot be enrolled at all, because the address is already taken, or overwrites the first. Either way, one player’s offers are being sent to another player’s profile, and the property has no idea which.
One person can have many. Beyond the second address most people carry, the
same mailbox comes in variants. Some providers ignore dots in the local part, so two
spellings of one Gmail address deliver to the same inbox. Subaddressing, described in
RFC 5233,
lets a user append +anything to their name and still receive the mail.
And the standard itself does not promise that case is irrelevant:
RFC 5321
says of the part before the @ that “the local-part of a mailbox MUST BE
treated as case sensitive,” while discouraging anyone from relying on it. A
system that keys on the raw string will file J.Smith@,
jsmith@ and jsmith+casino@ as three players. A system that
normalises aggressively will occasionally merge two who are not the same. Neither is
a good place to be.
It is missing from the records that matter. Rated play is recorded against the player’s club account, not their inbox. So are comps, points, tier changes, hosted status and the exclusion list. Many club records carry no email address at all, and many that do carry one that was current when the card was issued. An email-keyed marketing database cannot join to any of that without a lookup table that is itself keyed on the thing it is trying to avoid.
The failures above are not abstract. Each has a specific way of showing up on the floor and in the reports.
| What happens | Why | Who feels it |
|---|---|---|
| A Platinum host player gets the Bronze mailer | Their new address created a new profile with no tier, so the segment put them in the default bucket. | The player, in public, and then the host. |
| An opted-out guest keeps getting offers | They unsubscribed under the old address. The new address is a new record, and the record has no memory of the request. | The guest, and eventually whoever handles the complaint. |
| A self-excluded person receives a free-play offer | Exclusion attaches to a person. The marketing record attaches to an address, and the two were never joined. | Compliance, and the property’s reputation with its regulator. |
| A couple gets one offer, calculated for one of them | A shared address is one record, so one spouse’s worth drove the offer and the other spouse’s play, tier and host were never in the calculation. The free play went to whichever of them opened it. | Both players, the host, and finance, quietly, forever. |
| The second spouse cannot be added | The address is the key, so the address is already taken. The choice is to leave the second player out of marketing entirely or to overwrite the first. | The player who is never marketed to, and never knows why. |
| The database grows faster than the club does | Every address change is a new person. The counts in the board deck are counting profiles, not players. | Anyone making a decision from the numbers. |
A players club number is issued once, at the desk, to a person. From that moment the casino management system records everything about that person against it: every rated session, every point earned and redeemed, every comp, every tier evaluation, every host note, and if it comes to it, the exclusion. It does not change when the player changes their phone, their address or their surname. It is the one identifier in the building that already does all four jobs.
Keying the marketing database on PlayerID means the marketing record is the player record, extended. The couple who share an inbox are two records, because they are two players: each with their own tier, their own offer and their own suppression, each addressed by their own name, both landing in the same mailbox and neither interfering with the other. A changed email address becomes what it should always have been: an update to a field on an existing person, not the birth of a new one. Tier comes from the CMS, so the segment is right by construction. Exclusion comes from the CMS, so the suppression is right by construction. The counts count people.
One thing does legitimately attach to the address rather than the person, and it is worth being exact about. Under CAN-SPAM, a commercial message must give the recipient a way to ask not to receive future messages from that sender “at the electronic mail address where the message was received” (15 U.S.C. §7704(a)(3)). The legal minimum is address-level: the address that unsubscribed must stop receiving.
A PlayerID-keyed system honours that and goes further. The unsubscribe is recorded against the address, so the statutory obligation is met, and it is recorded against the person, so the same guest does not start receiving offers again at a new address six months later. In our experience the second half is what guests actually mean when they unsubscribe, and it is the half an email-keyed system cannot deliver, because to it the guest at the new address is a stranger.
This is how we do it, described so you can ask any vendor for the equivalent.
PlayerIQ Data Connect extracts patron data from the casino management system every night and merges it into PlayerIQ using PlayerID as the primary key: new players are created, existing players are updated, and nothing duplicates when a patron changes their email address. It works with IGT Advantage, Aristocrat Oasis, Konami SYNKROS and Bally, with field mappings configured per CMS. The same pipeline carries the compliance data, so self-exclusion and banned-patron lists arrive from the source and suppression happens automatically rather than whenever someone remembers to upload a spreadsheet. EmailIQ, the sending side, is keyed the same way, so segmentation, reinvestment tiers and offer eligibility come from the player record rather than from a list.
| Ask | What a good answer sounds like |
|---|---|
| What is the primary key of a contact? | “Your PlayerID.” If the answer is the email address, every other answer below follows from it. |
| Two spouses share one email address and hold separate club accounts. Show me both records. | Two records, two PlayerIDs, one address on each, each spouse’s own offer going to the same inbox under their own name. A vendor who has to explain a workaround has an email key. |
| A player changes their email address. What happens to their record? | It is updated in place, with tier, history and preferences intact. Not “we merge duplicates periodically.” |
| Does an unsubscribe follow the person or the address? | Both. The address, because the law requires it; the person, because the guest meant it. |
| Where does the suppression list come from? | From the CMS, on a schedule, without a person in the loop. A monthly CSV upload is a gap of up to a month. |
| Where does tier come from? | From the CMS, on the same sync. A tier that is typed into the email tool by hand is a tier that is wrong by the end of the quarter. |
How do you treat J.Smith@ and jsmith@? |
As a question about the person those addresses belong to, answered by the PlayerID. Any vendor who answers with a string-normalisation rule is keying on the address. |
Strategy9 has built casino and hospitality systems since 1999 and runs software at 70+ properties. The account above is drawn from how our own products are built and what we have watched go wrong at properties that keyed on the address first. The standards and statute cited are RFC 5321 §2.4, RFC 5233 and 15 U.S.C. §7704, each linked where it is used.
You will notice there is no figure here for how often people change their email address or what share of an email-keyed database is duplicates. Numbers like that are quoted freely in vendor material and we have not found one with a source behind it, so this page does without. If you want the figure for your own property, the query is simple: count club members with more than one marketing profile.
Nothing here is legal advice. The CAN-SPAM point is one sentence of a statute that has other requirements, and state and tribal rules on marketing to excluded or opted-out players vary. If you are making a compliance decision, read the rules that apply to your property and ask your regulator.
Data Connect syncs your CMS to PlayerIQ nightly, and EmailIQ sends from the player record. We will show you the merge on your own data, duplicates and all.