Is Your Mobile Game Ready for ML Personalization: a Team Checklist

A studio buys a “smart model” because the shop window stopped moving ARPU. A quarter later the offer is still one SKU, the SDK sits in the backlog, and the producer cannot kill a discount without a client build. The algorithm is not what broke. Readiness broke: events, economy, offer spots, volume, tech, and experiment live in different chats, and no cell is signed.
Get sandboxThis is a MOFU/BOFU checklist for Founder, Producer, CTO, and the analytics lead. You leave with six cells you can print before a pilot. Timelines, the 5,000 unique players per month floor, and “analytics at $0” below are site claims from mone.tools, not a promise for your title. Do not treat unnamed genre cards as proven results.
What “ready for ML” actually means
Readiness is not “we have Amplitude and a vendor wishlist.” It is six cells, each either green or still too early for a pilot. MONE describes a closed loop: collect data → read behavior on Player Journey Maps (PJM) → issue an offer and a spot inside designer rules → calibrate in an isolated A/B test. The checklist answers a different question: do you have the right to enter that loop now.

If any cell is red, the model will optimize noise. Historical SandBox exists for this: six months of events can show which cells are missing, while the analytics layer on the site is $0 (site claim). Connecting personalization makes sense when the producer can name a corridor and the metric the test must beat.
The site’s public pipeline (site claim): SandBox in 1–2 hours at the audit step, telemetry in 1–2 days, personalization launch in 2–3 days once Hard Limits and cohorts exist. Full personalization connection is less than a week (site claim). Those hours do not replace the meeting where the six cells get an owner.
Minimum for an ML personalization pilot on the site: 5,000 unique players per month. Below that floor the cycle is still useful — as an audit and a map, not as a promise of a significant A/B.
Six cells without which a pilot is a lottery
A cell is not “one more readiness slide.” It is a condition without which you cannot honestly call the offer personalization. If the condition is missing, stop at audit. Do not call it “the model will catch up in prod.”

| Cell | Ready if | Too early if |
|---|---|---|
| Events | The Event List emits progress, balance, purchase history, and session without touching combat | Events live in analytics and never reach the offer decision |
| Economy | Hard Limits, SKU white/black lists, and price floors are signed in one place | Price is “up to the model,” discount has no cap |
| Offer spots | Spots already exist in the client; Smart Triggers may stay silent | The pilot needs a new popup, or the only spot is panic |
| Volume | ~6 months of history and a unique/month floor — or explicitly “audit only” | A week of logs and a hope that ML will “see segments” |
| Tech | SDK / API, Fallback, kill the offer without a store resubmit | The offer is baked into the client; there is no rollback |
| Experiment | Baseline, A/B, D7/D30 next to ARPU, week-5 decision meeting | Conversion up with no retention guardrail |
Events are what change the offer, not “more logging”
An event for ML personalization is a field that changes mix, price, or moment. Progress, balance, purchase history, session. If the field does not change an output, that is dashboard logging, not readiness.
Demand before a pilot:
- An Event List dictionary a developer can emit without rewriting combat.
- Four signals named. Two hundred extra events with no output do not add readiness.
- Windows and quality: duplicates, holes, timezones, children and special-category data out of scope.
- Consent and PII closed before the export, not “we will sort it at integration.”
Events in Amplitude with a shared shop are analytics. Events in the offer decision are the cell.
Economy is a corridor a producer can read
A model without a corridor is a fire-sale bot with a confidence score. Hard Limits, SKU white/black lists, discount floors and ceilings, Impression Caps live in the Management Console not as a vendor checkbox, but so a producer can read what this player may see at all.
Lock:
- Which currencies and SKUs are in the pilot. Everything else stays out of the offer.
- A different discount cap for first purchase and for Whale.
- Retention-First: a show that teaches players to wait for a sale is banned.
- A stop in minutes, without a client build.
If economy is “later,” you are not ready for ML. You are ready for a shop window with a personal headline.
Offer spots are spots that already exist
A pilot that needs new UI is a different project. On the site, spots live inside the PJM: defeat, resource dry-up, upgrade complete, new stage. Smart Triggers pick from the signed list and may stay silent if a cap or Retention-First said no. Silence is a valid offer.
Demand:
- A list of live UI surfaces. No new popups.
- A panic ban: a fail streak does not open a discount above the cap.
- Caps per player and per session.
- Fallback: if telemetry is silent, the player sees the default shop.
Volume is history and a traffic floor, not “the model is smart”
The site calls for roughly six months of events for SandBox and a minimum of 5,000 unique players per month for an ML pilot (site claims). Below the floor the cycle is not forbidden — it must be named an audit, not an “ML A/B.”
Lock:
- An export the analyst treats as complete (the funnel reads, not “three shop events”).
- The unique/month floor said out loud. If below it, the calendar says “audit / map only.”
- The segments you want to personalize actually appear in history.
- Kids titles and special-category data out of scope.
Low traffic plus “turn the model on” is how you get a LiveOps anecdote and call it personalization.
Tech means kill without the store
Tech readiness is not “the vendor will send an SDK.” It is: Event List, a show point, Fallback, config rollback without a resubmit. On the site, integration must not rewrite combat or economy. If the offer cannot be killed in minutes, the cell is red.
Demand:
- An SDK / API path that does not touch combat.
- Fallback tested on a stand: the model is silent — the shop is live.
- Console roles: who publishes config, who rolls back.
- The pilot does not depend on a new UI surface.
Experiment is a memo before week 1
A pilot without a baseline is a demo. Register ARPU/LTV, 1st Pay Conv., D7/D30, window, denominator. One primary metric. Retention is a guardrail, not a vanity chart. The week-5 decision meeting is on the calendar before week 1 starts: scale, iterate, or stop.
The site’s public window (site claim): 4 weeks of learning and measurement, then 3–5 days of review. Do not mix this with “Sandbox in 48 hours” on the first screen — that is a different step.
When this is still too early
Name the red cell before a player names it in the store or finance names it after a quarter.
- Events exist, the offer decision does not: the model watches payment or panic.
- No price floor or SKU list a producer can read.
- The only spot is after a fail streak.
- The offer cannot be killed without a build.
- “A/B” without D7/D30 and without a rollback owner.
- Traffic below the site floor, but the slide says “ML pilot.”
If any line is you, you are in audit. That is what SandBox is for: see leaks and missing cells, not buy a license early. On the site, personalization payment starts after confirmed ARPU uplift (site claim) — that is a commercial frame, not a reason to skip the checklist.
Who owns the cell, not “the model will figure it out”
The cycle dies when readiness is “tuned by the vendor.” Use a RACI-style split. R = does the work, A = owns the call, C = consulted, I = informed.

| Role | Cell | Stop |
|---|---|---|
| Producer | A: signal scope, Hard Limits, spots | A: kill the pilot in minutes |
| Analyst | R: event quality, baseline, volume | R: D7/D30 next to ARPU |
| CTO / developer | R: Event List, SDK, Fallback | R: rollback without a resubmit |
| LiveOps / economy | R: SKU whitelist, frequency, season | C: do not break live content |
| Vendor | C: comparable PJM cuts | I until the studio expands |
Checklist (print this)
- Four signals are named and reach mix, price, or moment. Extra events with no output do not count as readiness.
- Hard Limits, SKU lists, and caps live in one place a producer can read. Stop in minutes.
- Pilot spots already exist in the client. No new popups. Smart Triggers may stay silent.
- ~6 months of history on hand, or the NDA path is agreed. The unique/month floor is named; below it — explicitly “audit only.”
- Fallback is tested. The offer is killed without a store resubmit. Combat was not rewritten.
- Baseline pack: ARPU/LTV, 1st Pay Conv., D7/D30, window, denominator.
- The week-5 decision meeting is on the calendar before week 1 starts.
- Every cell has an A. “The vendor will figure it out” is a red cell.
The point
- ML readiness is six signed cells, not a model purchase. Events, economy, offer spots, volume, tech, experiment.
- A red cell stops the pilot. A model does not fix a missing Event List, corridor, or A/B.
- A spot that is not in the client, and an offer you cannot kill without the store, is a different project — not personalization.
- A traffic floor and six months of history are conditions of an honest experiment or an honest audit. Do not mix them on a slide.
- SandBox can show which cells are missing while analytics on the site is $0. Scale still needs an A/B memo with D7/D30.
Ask for SandBox, not a license
If you have about six months of events and a producer who can lock a corridor, the next step is a historical audit: segments, PJM, offer spots, missing cells, and a report you can hold next to the current stack. Start from the MONE audit / SandBox path or from the pipeline. Studio console: dash.mone.tools. Analytics is the free layer; personalization payment, on the site, starts only after an A/B test confirms ARPU uplift.
Read also
- From Audit to Scale: monetization personalization in one cycle
- Dynamic offers in mobile games: how to match a proposal to a specific player
- How to keep control of the game economy when you use AI
- Player Journey Map for mobile games: how to turn the player path into a monetization tool
- How to run a monetization A/B test and prove real revenue lift
