Home

How to Find Future Paying Players Before the First Purchase

Future payers: signals before first purchase, not the receipt

UA sees D1 ROAS from first payments and kills the creative. The analyst sees that payers showed up on day seven, after the campaign is already off. The producer sees that the post-defeat offer catches people who would have paid anyway. The creative is not what broke. The scoring moment broke: player quality is measured by a payment that does not exist yet.

Get sandbox

This is a MOFU brief for UA Lead, CMO, Performance Marketer, analyst, and studio lead. You leave with four pre-conversion signals and a rule: predictive value is behavior, not a receipt. 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 “future payer” actually means

A future payer is not “a player who looks like a whale in the creative.” It is a player who already has a stable set of signals before the first purchase: they return, they clear progress gates, they spend a resource in a meaningful place, they look at the shop without panic. MONE describes a closed loop: collect data → read behavior on Player Journey Maps (PJM) → issue an offer inside designer rules → calibrate in an A/B test. A score before first purchase answers a different question: whom may UA and monetization treat as valuable while the cash register is still silent.

Four pre-purchase signals: return, progress, resource, intent

If the score is built only on payment, you optimize the tail. Historical SandBox exists for this: six months of events can show who paid later and which signals were visible on D0–D3, while the analytics layer on the site is $0 (site claim). Connecting personalization makes sense when the analyst can name the signals and UA can say where that score is allowed to travel.

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 UA and analytics agree what “valuable before payment” means.

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 of signals, not as a promise that the model will “find whales” on thin traffic.

Four signals that are visible before the till

A signal is not “one more Amplitude event.” It is a field that changes the payment forecast before a receipt exists. If the field appears only after purchase, that is a description of payers, not a search for future ones.

SignalVisible before purchase ifNot a predictor if
Return / sessionD1 return, session depth, a second session with no paymentCPI and an install with no session
ProgressCleared a gate, tutorial, PJM layer that usually precedes paymentA vanity level with no link to the economy
ResourceBurns energy / attempts in a meaningful place, not in panicA fail streak as the only “ready to buy” signal
IntentOpened the shop, viewed a SKU, closed without buyingAny banner click = “hot lead”

Return and session are quality UA can see before ROAS

The first payment is late for the optimization window. D1 return, session length, a D2 re-entry — that is what the campaign can still see. If UA cuts on 1st Pay Conv. in the first 24 hours, it cuts cohorts that pay on D3–D7.

Lock:

  • The window in which the score must be ready (not “when LTV accumulates”).
  • The denominator: unique player, not click.
  • What stays out: children, special categories, unidentifiable traffic after privacy limits.
  • The link to creative: a score does not replace attribution; it says whom in the cohort is worth feeding an offer, not “which channel is magic.”

An install with no session is not a future payer. It is a click price.

Progress is the gate after which payment even makes sense

A player who has not reached the gate is not “not a whale yet.” They have not seen the economy. A progress signal for a predictor is the PJM layer that usually sits before first purchase: end of tutorial, first upgrade, entry into the energy loop. Without that, the score trains on people who merely opened the app.

Demand:

  • A named gate, not “any level_up.”
  • Alignment with the map: the same layer the producer uses to place an offer.
  • A window after the gate: how many hours you wait for behavior before calling the player “cold.”
  • A ban on substituting payment for progress: “they reached it because they paid” leaks the future into the past.

Resource is pressure that is not panic yet

Energy running out after a meaningful session and a defeat streak are different signals. The first can precede an honest purchase. The second trains the player to wait for a discount. Finding future payers needs the first: the player invested in the loop and hit a design limit, not a wall of frustration.

Lock:

  • Which currencies and caps enter the score. Everything else is noise.
  • A cap: resource-in-panic does not raise the score.
  • Retention-First: a signal that appears only after three fails does not enter the first-purchase predictor.
  • The link to the offer: a high score is not a right to raise the discount above Hard Limits.

Shop intent is “looked,” not “paid”

Opening the shop, viewing a SKU, closing without a payment — that is pre-conversion behavior. It is stronger than a banner. It is weaker than a receipt. Studios often drop it because “they did not pay.” That is exactly the signal to keep: the closest thing to the till without the till.

Demand:

  • An “opened / viewed / closed” event, not only `purchase`.
  • A ban on treating any offer impression as intent: the impression is yours, not the player’s.
  • A split between first purchase and repeat: whale intent and newcomer intent are different inputs.
  • Consent and PII closed before the export, not “we will sort it at integration.”

Score from behavior, not from a payment that already happened

Payments describe people who already converted. For UA and early monetization that is too late. Predictive value is the probability that the player will pay in a window, from signals that were available before the window.

Payments-only scoring versus behavior before purchase
ApproachWhat it optimizesWhere it breaks
Payments onlyPeople who already boughtThe campaign dies before D7; the offer feeds whales
Lookalike on the receiptPeople who look like last month’s payersMixes creative, geo, and behavior
Behavior before purchasePeople who have not paid yet but walk the same pathNeeds an Event List and a window, not “ML magic”

A model with no window is a slide. Name the horizon (24 hours, 72 hours, 7 days) and the metric the score must predict: 1st Pay Conv., not whale ARPU. ARPU after purchase is a different job, closer to a dynamic offer.

The site’s public window (site claim): 4 weeks of learning and measurement, then 3–5 days of evaluation. Do not mix that with “Sandbox in 48 hours” on the first screen — that is a different stage. A score before first purchase can live on six months of SandBox history before you turn personalization on.

When this is not a predictor, but a UA folktale

Name the red cell out loud before the ad account names it after you killed the best creative.

  • The score is built on `purchase` and issued as “quality before payment.”
  • The only signal is a fail streak or a discount.
  • There is no denominator: “score 0.8” with no window and no unique player.
  • UA optimizes CPI, analytics counts LTV, the producer places the offer — three different “payers.”
  • Traffic is below the site floor, but the slide says “ML will find whales.”
  • Privacy: the identifier is gone, and the score is still “user-level,” not aggregate.

If any line is you, you are in a signal audit. That is what SandBox is for: see which events even reach a decision, 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 feed the model payments as the only label.

Who uses the score, not “the model will figure it out”

The cycle dies when the score is “for everyone” and for no one. Use a RACI-style split. R = does the work, A = owns the call, C = consulted, I = informed.

Who uses the pre-purchase score
RoleScoreStop
UA / performanceC: the window; where the score must not enter the ad account before it is readyA: do not kill a cohort on a payment that is too early
AnalystR: signals, label, window, event qualityR: do not train the model on payment as an input
ProducerA: which offer a high score sees before first purchaseA: Hard Limits, not “a discount for anyone who looks like a whale”
LiveOps / economyC: do not break live content with frequencyC: impression cap
VendorC: comparable PJM cutsI until the studio expands

Checklist (print this)

  • Four signals are named and available before `purchase`. Payment is the window label, not a score input.
  • The prediction window and the denominator (unique player) live in one place UA and analytics can read.
  • Progress is tied to a PJM layer, not to any level_up.
  • Resource-in-panic and a fail streak do not raise the first-purchase score.
  • Shop intent is logged separately from the offer impression.
  • A high score does not widen the discount beyond Hard Limits. Retention-First stays on.
  • The unique/month floor is named; below it — explicitly “signal audit only.”
  • The score has an A. “The model will find whales” is a red cell.

The point

  • A future payer is visible before the receipt: return, progress, resource, intent. Payment describes the past.
  • A score trained on `purchase` as an input does not find future payers. It retells the till.
  • UA that cuts on ROAS that is too early throws away cohorts a score could still have fed an offer.
  • A high score is a right to show a relevant offer inside the corridor, not a right to break the economy.
  • SandBox can show signals on history while analytics on the site is $0. Scale still needs a window, a label, and an A/B with D7/D30.

Ask for SandBox, not a license

If you have about six months of events and an analyst who can lock a prediction window, the next step is a historical audit: which signals preceded first purchase, where UA cuts too early, which offer spots make sense before the till. 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

  • How to connect in-game monetization with User Acquisition and ROAS
  • Is your mobile game ready for ML personalization: a team checklist
  • Dynamic offers in mobile games: how to match a proposal to a specific player
  • From Audit to Scale: monetization personalization in one cycle
  • Mobile game analytics in the privacy era: which signals remain after identifier limits

We use cookies so the site works correctly.