Home

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

ML readiness: six cells signed before a pilot

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 sandbox

This 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.

Six checklist cells for ML personalization

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.”

Too early versus ready to pilot
CellReady ifToo early if
EventsThe Event List emits progress, balance, purchase history, and session without touching combatEvents live in analytics and never reach the offer decision
EconomyHard Limits, SKU white/black lists, and price floors are signed in one placePrice is “up to the model,” discount has no cap
Offer spotsSpots already exist in the client; Smart Triggers may stay silentThe 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”
TechSDK / API, Fallback, kill the offer without a store resubmitThe offer is baked into the client; there is no rollback
ExperimentBaseline, A/B, D7/D30 next to ARPU, week-5 decision meetingConversion 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.

Who signs each readiness cell
RoleCellStop
ProducerA: signal scope, Hard Limits, spotsA: kill the pilot in minutes
AnalystR: event quality, baseline, volumeR: D7/D30 next to ARPU
CTO / developerR: Event List, SDK, FallbackR: rollback without a resubmit
LiveOps / economyR: SKU whitelist, frequency, seasonC: do not break live content
VendorC: comparable PJM cutsI 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

We use cookies so the site works correctly.