110 Analytics, a Maltese tech and AI company, joins an operator's player platform, payment providers, affiliate system, CRM and spreadsheets in one warehouse the operator owns. Each metric, such as an active player or a new depositor, gets one written definition agreed with your teams, and every dashboard reads from it. We do not build or sell gaming platforms, and your systems and their suppliers keep their jobs.
Signs your figures live in too many places
Operators with a platform, several providers and a growing BI layer may hear lines like these.
- Ask three departments for last month's active players and you get three answers.
- The affiliate report and the platform disagree on how many new depositors we had.
- Affiliates on revenue share are paid on a net revenue figure that never ties back to the board pack.
- Payment fees sit in each provider's portal, so margin per player is an estimate.
- The BI layer grew one report at a time, and nobody is sure which ones are still right.
- When the person who built the reports is away, the reports wait for them.
Many systems, and a different answer in each
An operator's numbers are spread across systems chosen for their own jobs. The player platform holds accounts, deposits, play and bonuses. Payments sit with one or more providers, affiliates in an affiliate system and campaigns in the CRM.
Each counts in its own way. An active player can mean a bet in one place, a login in another and a deposit in a third, so three teams can report three figures, each defensible on its own terms.
Revenue splits the same way. Net gaming revenue depends on what is taken off the gross, such as bonus cost and payment fees, and the platform, the affiliate system and finance can each take off something different. Affiliates are paid on one version and the board reads another; when nothing reconciles the two, nobody is sure which figure to act on.
One warehouse, one definition per metric
We read each system and load it overnight into one warehouse, built in your own cloud account and yours to keep. The platform, the payment providers, the affiliate system and the CRM carry on exactly as they are.
In the warehouse the same player is recognised across platform, CRM and affiliate data. Active player, new depositor, net gaming revenue and bonus cost are each settled once with your teams and written into the model, and every report inherits them. Where a contract sets its own revenue basis, as affiliate revenue share deals do, that figure is kept under its own name beside the board's, so the two can be compared.
Your BI team keeps its role and gains a foundation: it builds on one agreed model instead of reconciling exports. The executive view across brands, each team's reports and the AI layer all read the same figures.
Questions that need more than one system
Each of these draws on data held in at least two of an operator's systems.
Cost of a new depositor
Commission paid per new depositor, media spend and bonus cost set against first deposits recorded in the player platform.
Player value by channel
Deposits and net revenue per player, grouped by the affiliate, campaign or channel that brought each player in.
Margin after payment fees
Each provider's fees taken off revenue, per payment method or per brand.
Bonus cost against return
Bonus spend from the platform set against the deposits and play that followed, campaign by campaign.
Players who stop depositing
Deposit history from the platform set beside CRM contact history, so retention can see which lapsing players a campaign reached.
People costs beside revenue
Payroll totals set beside revenue by team or brand, visible only to the roles cleared to see pay.
Three versions of an active player become one
One board question, traced: what did a new depositor cost?
Picture an online gaming operator in Malta with two brands on one player platform, several payment providers, an affiliate programme and a CRM. A small BI team maintains a set of reports that has grown piece by piece. The board asks what a new depositor cost last month, by channel.
- Acquisition counts new depositors from the affiliate report, finance from the platform, and the two counts differ.
- Commission comes from the affiliate system, media spend from each ad platform and bonus cost from the platform.
- Someone joins the exports in a spreadsheet and chooses a definition along the way.
- The answer arrives mid-month, with a footnote explaining why it differs from last time.
- A new depositor is defined once, for instance a player's first successful deposit, and every system's data is read against that rule.
- Commission and bonus cost load overnight and are matched to each player; media spend is matched to its campaign and channel.
- Cost per new depositor appears by brand and by channel each morning, current to yesterday.
- Only the roles cleared for it see individual players; the board sees brands and channels.
- The BI team's month goes on new questions, not on rebuilding the same figures.
Nothing was replaced. The board's question now has one answer, and the footnote has gone.
The metric choices an operator settles once
Every operator makes these choices somewhere, often differently in each system. The audit lists them; your teams decide each one, and the model applies it everywhere.
| Metric | Where it usually starts | The choice to make |
|---|---|---|
| Active player | Platform, CRM and affiliate system | Which activity counts (a login, a bet or a deposit) and over what period |
| New depositor | Platform and affiliate system | Which first deposit qualifies, whether it counts on the day of the deposit or of registration, and under which brand |
| Net gaming revenue | Platform and finance | Which deductions come off the gross, such as bonus cost and payment fees |
| Bonus cost | Platform and CRM | Whether a bonus counts when it is granted, when it is played through or when it turns into cash |
| Cost per new depositor | Affiliate system, ad platforms and the platform | Which costs are included: commission, media spend, bonuses |
| Player value | Platform and payment providers | Over what period, and after which costs |
From first call to live dashboard
- Strategy callA free thirty-minute conversation with Glen. Name the systems the business runs and the figure that causes the most argument, and by the end you will know whether an audit is worth doing.
- Data auditRoughly three hours with your finance, acquisition, CRM and BI owners. Glen maps each system, export and spreadsheet behind the recurring figures, and a quote follows.
- BuildRead access to the agreed systems, overnight loads, player matching and the definitions your teams sign off, then the first dashboard. Allow three to four weeks from accepting the quote to seeing it live.
- Fractional data teamA senior team keeps the loads and the model current as providers and systems change, brings in new sources such as another payment provider, and takes on the next question. If the work outgrows a fractional team, our partner network adds capacity.
What we do not do
- We do not build, sell or run player platforms, payment services or affiliate systems.
- We do not replace your BI tools or your BI team. We give them one agreed model to build on.
- We do not write data back into the platform or any other system.
- We do not take custody of player data. The warehouse sits in your own account.
Glen Sultana founded 110 Analytics after a career built where the numbers move daily. Our people have run analytics for tier-one companies, S&P 500 firms and high-growth technology businesses. Glen is the person on the first call, and he runs every data audit himself.
- Built in your environment, under your account
- No lock-in: if we part company, it keeps running and stays yours
- Based in Malta
Straight answers
Do you replace our player platform or our BI tools?
No. The platform, the providers and your BI tools keep doing their jobs. We copy their data into a warehouse you own, agree the definitions with your teams, and report from there.
Can the warehouse be live to the minute?
No. It loads on a schedule, overnight, so the reporting built on it is current to yesterday. Minute-by-minute monitoring stays with the live tools you already run.
Who can see player-level data?
Access is set by role. Leadership can see every brand, while player-level detail reaches only the roles you clear for it. What is loaded at player level, and what only as totals, is agreed with you before anything is loaded.
We already have a BI team. Where do you fit?
Underneath it. We take on the warehouse, the loads, the matching and the agreed definitions, so your BI team's reports start from one model instead of several exports.
How do you connect to our platform and providers?
The audit confirms the route for each system: a standard connector, an interface the vendor offers for other software, a read-only database connection or a scheduled export. Our access is read-only wherever a system permits it.
Which reporting tool do you build in?
Where we build the dashboards, Power BI for a company that works in Microsoft 365 and Looker Studio for one on Google Workspace. The agreed definitions sit in the warehouse, not in a tool, so your BI team can keep using its own.
What does it cost?
The data audit ends with a quote, and the price turns chiefly on the number of systems joining the warehouse and the matching they need. Running costs for the warehouse are billed by the cloud provider straight to your own account.
Terms on this page
- Player platform
- The core system an operator runs on: player accounts, deposits, play and bonuses.
- New depositor
- A player making a first deposit. Your teams agree once which deposit counts and on which day.
- Net gaming revenue
- What remains of gross gaming revenue (stakes less winnings) after the deductions your business agrees, such as bonus cost.
- Player matching
- Recognising the same player across the platform, the CRM and the affiliate data, so their records join up.
- Tiered access
- Access set by role, so leadership sees every brand and player-level detail reaches only the roles cleared for it.