Identifiers and Data Flow

Optimove Personalize can only connect customer activity to recommendable inventory when both integrations use the same canonical identifiers.

The join in one sentence

Inventory publishes an item under a stable key; a Real-Time Event reports customer activity using that exact key; Personalize uses the match to learn from and recommend inventory.

Stage	Gaming example	Sports example
Publish inventory	A game has `game_code: "slot-1042"`	A selection has `selectionKey: "sel-9001"`
Observe activity	Game Launch sends `ootb_game_code: "slot-1042"`	Bet Placement sends `ootb_selection_key: "sel-9001"`
Resolve customer	The event's top-level `customer` identifies the player	The event's top-level `customer` identifies the bettor
Use in Personalize	Activity is attributed to the published game	Activity is attributed to the selection and its hierarchy

Identifier rules

Apply these rules to every key:

Preserve the source value exactly, including case, punctuation, and leading zeroes.
For Gaming, do not use apostrophes in game_code; the current Inventory processor normalizes apostrophes in top-level keys to hyphens.
Send keys as strings even when the source system stores a numeric identifier.
Do not translate keys. Translate display names only.
Do not reuse an old key for a different item.
Keep keys stable when names, prices, status, or other attributes change.
Use the same identifier source in inventory and events.
Reconcile unknown event keys and orphaned inventory records as operational errors.

Gaming identifier map

Concept	Gaming Inventory field	Real-Time Event field	Rule
Game	`game_code` and the top-level object key	`context.ootb_game_code`	All three values must match exactly
Game session	Not an inventory key	`context.ootb_game_session_reference`	Use one stable reference to correlate launch and session activity
Customer	Not stored in Gaming Inventory	top-level `customer`	Must identify the customer known to your Optimove tenant

The outer key and game_code in every Gaming Inventory record should be identical:

{
  "slot-1042": {
    "game_code": "slot-1042",
    "game_name": "Example Adventure"
  }
}

Gaming availability context

Availability filtering is separate from the Real-Time Event identifier join. Gaming Inventory can restrict a game through skin_id, regulation, inclusions, and exclusions; Personalize evaluates those values against the configured customer/site context used when recommendations are resolved.

Gaming Inventory field	Must correspond to
`skin_id`	The configured skin value available to the recommendation request
`regulation`	The configured jurisdiction/regulation value available to the recommendation request
`inclusions`	Matching configured context keys and allowed values
`exclusions`	Matching configured context keys and denied values

These are not Game Launch or Game Session context-field mappings. Agree the context names and vocabularies during onboarding.

Sports hierarchy identifier map

Sports events use betting terminology for two inventory levels: discipline maps to Category and meeting maps to Type.

Hierarchy level	Sports Inventory key	Bet event context key	Must match
Category / discipline	`categoryKey`	`ootb_discipline_key`	Yes
Class	`classKey`	`ootb_class_key`	Yes
Type / meeting	`typeKey`	`ootb_meeting_key`	Yes
Event	`eventKey`	`ootb_event_key`	Yes
Market	`marketKey`	`ootb_market_key`	Yes
Selection	`selectionKey`	`ootb_selection_key`	Yes

The matching name fields provide content and diagnostic context, but they are not substitutes for keys:

Sports Inventory name	Bet event context name
`categoryName`	`ootb_discipline_name`
`className`	`ootb_class_name`
`typeName`	`ootb_meeting_name`
`eventName`	`ootb_event_name`
`marketName`	`ootb_market_name`
`selectionName`	`ootb_selection_name`

Customer identity

The Server-Side Events API supports a general event envelope, but Personalize activity must be attributable to an identified customer. Send your Optimove customer identifier in the top-level customer field.

Do not put the customer ID only inside context, and do not substitute a browser or device visitor identifier for the known customer ID.

Time and ordering

Use the event contract's timestamp fields and formats exactly.
Preserve the real order of launch, session, placement, and settlement activity.
Do not rewrite old events with the current time during replay.
Keep inventory changes ordered for the same item. Concurrent requests can produce stale final state.

Reconciliation metrics

Monitor at least:

Metric	Why it matters
Percentage of required events with a non-empty `customer`	Shows whether activity can be attributed
Percentage of event item keys found in the latest successful inventory	Direct measure of join health
Unknown keys by source system and event type	Locates mapping or timing faults
Inventory item count by run and record type	Detects truncated feeds and accidental deletions
Age of the latest successful inventory load	Detects stale recommendable content
Required event count by hour/day	Detects event-stream outages

Set thresholds from your normal production volumes and expected inventory cadence rather than relying on one fixed threshold for every brand.