This page covers how to connect your event data to Xtremepush Intelligence and what to expect during the onboarding process.
The sequence diagram below shows the setup process end to end, from sending your event data through to your Xtremepush Intelligence suite being fully set up.
sequenceDiagram
participant Operator
participant Xtremepush
Operator->>Xtremepush: Send events
Note right of Operator: Via API, Kafka,<br/>Partner integration, or CDP<br/>(one process, several transport options)
loop Data integration
Xtremepush->>Xtremepush: Confirm events arriving correctly
end
Note right of Xtremepush: Needs 7-10 days<br/>of live event data
Xtremepush->>Xtremepush: Analysis & mapping
Xtremepush-->>Operator: Data mapping document
Xtremepush->>Operator: Event Configuration Sign-off Report
Operator-->>Xtremepush: Written confirmation to proceed
Xtremepush->>Xtremepush: Deploy data model
Xtremepush-->>Operator: Computed attributes live
Xtremepush->>Xtremepush: Enable dashboards
Xtremepush->>Xtremepush: ML model analysis
Note right of Xtremepush: Needs 90+ days<br/>of event history
Xtremepush->>Operator: ML Configuration Sign-off Report
Operator-->>Xtremepush: Written confirmation to proceed
Xtremepush->>Operator: ML models go live!Each part of this flow is covered in more detail in the Sending your data and Onboarding Process sections below:
Typical timeline
Phase | Typical duration |
|---|---|
Integration to first live events | 1 to 4 weeks (depends on integration type and complexity) |
Analysis and mapping | 3 to 5 business days (with data mapping form completed) |
Sign-off to data model deployment | 2 to 5 business days |
ML model analysis to deployment | 2 to 4 weeks |
Total time from a live integration to full Intelligence deployment, including ML models, is typically 6 to 10 weeks, depending on data quality and the scope of models included.
Sending your data
What data to send
For Intelligence to produce accurate metrics, your integration needs to include the following event types (Back-office events only). Front-end SDK or page-view events should not be sent under the same event names as transactional events.
The table below lists the event types Intelligence needs and the properties each one must contain:
Event type | Required properties |
|---|---|
Casino bet (wager) | Player ID, event timestamp, stake amount, bet/round ID, real-money or bonus indicator |
Casino win (payout) | Player ID, event timestamp, payout amount, bet/round ID |
Sports bet (wager) | Player ID, event timestamp, stake amount, bet ID, sport name, real-money or bonus indicator |
Sports payout | Player ID, event timestamp, payout amount, bet ID |
Bingo stake | Player ID, event timestamp, stake amount, game/ticket ID, room or game name |
Bingo payout | Player ID, event timestamp, payout amount, game/ticket ID |
Deposit | Player ID, event timestamp, deposit amount, transaction ID |
Withdrawal | Player ID, event timestamp, withdrawal amount, transaction ID |
Casino Events
Slots, live dealer, virtual sports, and table games should all be sent as casino events. Don't create a separate event type per game format.
To distinguish between them for reporting, include a game name field in the event payload. This is what powers the per-game breakdowns in the pre-built Intelligence datasets.
Flag real-money vs. bonus wagers on every event
Intelligence tracks real-money and bonus activity separately. The preferred approach is an
is_free_spin(or equivalent) boolean flag on the same event type. This allows a single event schema to cover both cases and enables accurate GGR calculation. Without this split, bonus stake inflates real-money GGR and the two cannot be separated retrospectively.
For full technical detail on what each event payload must contain and how events are classified, see Data Integration Requirements. That page is written for your technical integration team.
Ways to send your data
Intelligence is built on your player event data. Before Intelligence can be configured, your events need to be flowing into Xtremepush. There are several ways to do this.
1) API
Send events directly from your back-office system using the Xtremepush REST API. Events are sent in real time as they occur. This is the most common approach for operators with custom platforms.
For authentication setup and endpoint reference, see the Xtremepush Hit Event API documentation. For the specific field names Intelligence requires inside the event payload, see Data Integration Requirements.
Best for: If you have a custom tech stack and can push events server-side.
2) Kafka
If your platform already produces events to Kafka, Xtremepush can consume directly from your brokers, or you can push events to Xtremepush's own Kafka brokers.
For operators running on standard iGaming platform providers (GiG, Bede, OpenBet, EveryMatrix, and others), Xtremepush maintains pre-built Kafka transforms that handle format conversion automatically. This significantly reduces the integration effort for supported platforms.
For broker configuration and topic setup, see the Kafka Integration Guide and Topic Formats & Payload Requirements. For high-volume platforms, see Aggregating High-Volume Events. For the specific field names Intelligence requires inside the event payload, see Data Integration Requirements.
Best for: If you're a high-volume operator, or already using Kafka infrastructure.
3) Partner integrations
Xtremepush has pre-built integrations for many common iGaming platform providers. If your back-office system is supported, integration time is significantly reduced. Contact your account team to confirm whether your platform has a native integration.
4) CDP / Reverse ETL (Segment, Hightouch)
If you use a Customer Data Platform such as Segment or Hightouch, these can forward events and profile data to Xtremepush. This approach works well where your CDP is already your primary event routing layer.
CDP integrations cover the event flow but may require additional configuration to ensure the event structure is compatible with Xtremepush Intelligence requirements.
The onboarding process
Once your data is flowing, the Intelligence setup follows a structured process. Below is what happens at each stage and what's expected from you.
Stage 1: Data integration
Your events begin flowing into Xtremepush via your chosen integration pathway. The Xtremepush team confirms events are arriving correctly and at the expected volume.
Minimum data requirement
At least 7 to 10 days of live event data is required before analysis can begin. Less than this risks an incomplete picture of which event types are present.
What you need to do
Ensure your integration is live and test events are reaching the platform. Complete the data mapping form provided by your account team before or during your integration. This tells us which events carry monetary values, what your transaction IDs look like, and how you distinguish real-money from bonus activity
Stage 2: Analysis and mapping
The Xtremepush data team analyses your incoming event data for the following:
Which events are present
The properties each event carries
The values those properties contain
They also identify how your data maps to the Intelligence pipeline, including:
Which field holds the monetary value
Which field is the transaction ID
How each event should be classified
A data mapping document is then prepared for your review.
What you need to do
Respond promptly to questions about edge cases or data inconsistencies. The quality of the mapping depends on understanding your specific data.
Stage 3: Sign-off
The Xtremepush data team prepares an Intelligence Event Configuration Sign-off Report and shares it with you for review and approval before any models are deployed. This document covers:
Events tracked: A table of every event type that has been mapped into Intelligence, along with the computed metrics each event enables.
Events not tracked: Events present in your data but not mapped into Intelligence, with the reason for each. For example, insufficient volume, ambiguous structure, out of scope)
Key metrics enabled: The specific computed attributes that are now active on player profiles.
Known data notes: Any limitations or caveats in the underlying data. For example, historical events excluded due to schema changes, or events missing required properties.
What additional data could unlock: Where applicable, the team also flags any additional event types or properties that aren’t currently sent, but would unlock further metrics if added.
This is a required step. No models are deployed until sign-off is confirmed.
What you need to do
Review the sign-off report, raise any discrepancies with your account team, and provide written confirmation to proceed. Your technical and analytics team should review the Events not tracked section in particular to confirm any exclusions are expected.
Stage 4: Data model deployment
After sign-off, the Xtremepush team deploys your Intelligence data model. Computed attributes begin populating on player profiles. Pre-built datasets become available in your BI suite.
What you need to do
Validate that attributes are appearing correctly on a sample of player profiles. Confirm that GGR figures align with your internal reports.
Stage 5: Dashboard enablement
Your out-of-the-box dashboards are activated. The Xtremepush team configures the Campaign Performance dashboards and any other standard reports included in your contract.
Stage 6: Machine Learning model analysis
If ML models are included in your package, the Xtremepush data team analyses your historical data to assess model readiness. Each model has minimum data requirements, typically 90 or more days of event history and a sufficient active player population.
What you need to do
Work with your account team to confirm data availability and timeline.
Stage 7: ML sign-off
The Xtremepush data team prepares an Intelligence ML Configuration Sign-off Report and shares it with you before any models go live. This document covers:
Model status overview: A table showing the status of each ML model (Active or Revisit). A model is marked Revisit when the data volume or history is insufficient for a reliable deployment. It's assessed again at a specified future date as more data accumulates
RFM Segmentation: The full segment breakdown for your player base, showing the segment assigned to each group along with player counts and percentages. Segment names can be customised at this stage to match your own terminology.
Customer Retention Analysis: A cohort retention table showing month-by-month retention rates across acquisition cohorts, so you can validate the output before it's applied to targeting.
Player Lifecycle Analysis: The survival model output, which includes hazard ratios showing which player attributes most strongly predict churn risk.
Churn Classification: Model performance metrics (precision, recall, AUC) and the top features driving the model's predictions
What you need to do
Review each active model's outputs and confirm they're coherent with your understanding of your player base. RFM segment labels can be renamed directly in the platform to match your own terminology. Provide written confirmation to proceed.
Stage 8: ML models go live
ML models are deployed and begin scoring your player base. Results are written back to the platform and become available for segmentation and campaign targeting.