The field map

How the names your game sends become fields on the members of a community: the three states, the standard fields, and who approves what.

A game sends values and events under its own names: league_position, match_won. The field map is the list that says which of those names the community has accepted, and what each one is. A name is accepted by a member of the community's team, so the community decides what data is stored about its members. This page explains the map. Get the field map and Propose to the field map are the requests.

The three states

Every field and every event of a game is in one of three states.

State	What it means	What CEEJAY does with a value
`proposed`	CEEJAY has received the name, from a value your game sent or from a proposal, and nobody has decided yet	Stores the name and one sample value for the team to review, and returns `not_approved`. Nothing is written
`approved`	The team accepted it, and chose its name, type, choices and category	Writes the value to the member
`unused`	The team decided it is not wanted	Writes nothing, returns `unused` (an event: `not_approved`), and deletes the stored values

Only the community's team approves an entry. A key can read the map and propose to it, and cannot approve its own map.

The standard fields

Every game starts with the same 14 fields. A game fills only the ones it has. They do not count towards the game's 25 fields of its own.

Key	Name	Type	Category	Approved by
`std.player_id`	Player ID	text	progress	The first connection. Filled by CEEJAY, never by your server
`std.player_name`	Player name	text	progress	The first connection. Filled by CEEJAY
`std.signed_up`	Signed up	date	progress	The first value
`std.last_played`	Last played	date	progress	The first value
`std.level`	Game level	number	progress	The first value
`std.time_played`	Time played, in hours	number	progress	The first value
`std.sessions`	Sessions	number	progress	The first value
`std.rank`	Rank	ordered	progress	The team, who sets the choices and their order
`std.platform`	Platform	choice	progress	The team, who sets the choices
`std.account_status`	Account status	choice	progress	The team
`std.total_spend`	Total spend	number	purchases	The team
`std.purchases`	Purchases	number	purchases	The team
`std.last_purchase`	Last purchase	date	purchases	The team
`std.country`	Country	text	location	The team

Approved by the first value. The seven fields marked so need no choices, are in the progress category and are never sensitive. A standard field is approved automatically when its first value arrives, so a studio can send progress data the day its game is set up. Everything else needs approval from the team: every field of the game's own, every list of choices, and everything about purchases or location.

A name your game uses that is a known alias of a standard field becomes that field. level, player_level and lvl are Game level. last_seen and last_login are Last played. lifetime_spend and ltv are Total spend. An alias that could mean something else is not on the list. To name a standard field yourself, send it as standard in a proposal.

A standard field is one member field for each game. When the community already has a field of that name, the new one is called "Name (Game)", for example "Last played (Rugby Manager)".

Fields of the game's own

A game can have 25 approved fields of its own, 25 approved events, and up to 50 proposed entries of each kind at a time. Each field has:

A key, made from the name: League Position, leaguePosition and league-position are all league_position. It is up to 40 lower-case letters, digits and underscores, and it is the key you read back in Get a player.
A name on CEEJAY's screens, which the team can change.
A type: text, number, date, choice (a dropdown of up to 50 choices), yes_no, or ordered (choices that have an order, so "at least Gold" means something).
A category that decides whether the member has to consent to share it: progress, purchases or location.
An optional unit (up to 20 characters), a scale (what your number is multiplied by: 0.01 turns cents into dollars), and a value map that maps your game's values to the field's choices.
A sensitive switch, set by the team.

The type of a proposed field is inferred from a value by fixed rules, with no AI model: true and false are yes or no, a number is a number, text that reads as a date is a date, and everything else is text. The team changes it before approving. A field's type never changes once it is approved. If it was wrong, the team leaves the field unused and a new field with a new key takes over the name.

Events

An event has a key, a label shown in CEEJAY's dashboard ("Won a match"), a switch to store the quantity you send with it (off by default, because the member history has no sensitive switch), and a reward mode for the reward it may earn: once to each member, or each time it happens. An event stays out of the member history until it is approved. See Player data.

How a name gets into the map

Your game sends a value or an event with a new name. CEEJAY adds it as proposed, with one sample value truncated to 80 characters, and returns not_approved. The community's team is notified when the map gains an entry, at most once a day for each game.
Your server proposes ahead of time. Propose to the field map takes names, with example values or with more detail. It never changes an entry that is approved or unused.
A standard field is approved automatically when its first value arrives, for the seven fields above.

What approval does

A member of the community's team opens the proposal in the dashboard and sets the name, the type, the choices and their order, the value map, the unit, the scale, the category and whether the field is sensitive. Approving creates the field on the community's members, tied to the game. From then on:

The field is read-only everywhere else: nobody can enter a value by hand, and your game's values are the only ones stored.
It shows on the member's profile with the game's name beside it, in the Members table and filters, in segments, and in exports. A sensitive field appears in none of these.
It does not count towards the community's own limit of fields.

When the community already has a field of the same name, and one called "Name (Game)" as well, the approval is refused with the code field_name_taken and names the field to rename. No request a key makes can approve a field, so no key can receive this code today.

Leaving an entry unused

The team can mark an entry as unused. Its field is archived, which means no value is written to it, and CEEJAY deletes the stored values within about an hour. Your game can keep sending the name: each value gets the status unused, and an event gets not_approved. A proposal for an unused name is listed in skipped with the reason unused; the team decides whether to reinstate it.

The map is not a store of values

The map your key reads contains no player values and no samples: a sample is a real player's value that nobody has marked as sensitive or not. Only the community's team sees them.

Player data
Get the field map and Propose to the field map
The TypeScript SDK has ceejay.fieldMap.get and ceejay.fieldMap.propose.

On this page