Lesson Goal

In Lesson 4 you built your first store and IAP flow and wired basic events.

In this lesson you will:

  • Turn that raw data into a simple monetization dashboard.
  • Learn which metrics matter at this stage (and which do not).
  • Decide what to keep, tweak, or remove without breaking player trust.

You are not optimizing a live service yet β€” you are learning to read the room before making big changes.


Step 1 – Reconstruct the Funnel You Actually Shipped

Start by writing down the real funnel your players go through now, not the one in your head.

For example:

  • Launch game β†’ Main menu β†’ Press β€œPlay” β†’ Play run β†’ Results screen β†’ See β€œShop” button β†’ Open store β†’ See Starter Pack β†’ Start purchase β†’ Complete purchase.

Mark each step that you already track with events:

  • session_start
  • store_open
  • offer_view
  • purchase_start
  • purchase_complete

If there are steps without events, note them β€” you may need to add tracking later.


Step 2 – Collect a Small but Honest Dataset

Before analyzing:

  • Aim for real players, not just yourself:
    • Friends, coworkers, fellow devs.
    • A tiny closed test or free demo.
  • Set a time window (for example, 1–2 weeks of test data).

You do not need millions of events. You need:

  • Enough sessions to see basic patterns.
  • Enough variation to notice obvious issues (for example, nobody opens the store).

Make sure your data source:

  • Deduplicates obvious test accounts or bot traffic.
  • Separates dev/debug sessions from player sessions if possible.

Step 3 – Build a Minimum Monetization Dashboard

In a spreadsheet or lightweight BI tool, create a tab with:

  1. Session-level metrics:
    • Number of sessions.
    • Average session length.
    • Sessions that ever open the store.
  2. Funnel metrics:
    • Store open rate = store_open / sessions.
    • Purchase start rate = purchase_start / store_open.
    • Purchase completion rate = purchase_complete / purchase_start.
  3. Money metrics (even if simulated):
    • Number of purchases per offer.
    • Revenue per offer (use real or test prices).
    • Simple ARPPU (average revenue per paying user) if you have any payers.

Make it boring and clear:

  • One table with counts and percentages.
  • One or two simple bar charts if you like.

You should be able to answer:

  • Do players see the store?
  • Do they try to buy something?
  • Do purchases succeed or fall apart?

Step 4 – Look for Red-Flag Patterns First

Before chasing optimization, check for:

  • Store open rate extremely low:
    • Players are not finding or not caring about the store entry point.
  • Purchase start rate high, completion low:
    • Pricing, UX, platform issues, or payment friction.
  • Only one offer ever sells:
    • Other offers may be badly positioned or redundant.

Write down plain-language diagnoses, for example:

  • β€œMost players never open the store β€” entry point is too hidden or not compelling.”
  • β€œPlayers start purchases but often fail β€” we may have bugs, payment issues, or confusing confirmations.”

At this stage, you are mainly trying to catch obvious problems, not tune tiny percentages.


Step 5 – Decide on 1–2 Safe Iterations

From your diagnoses, pick one or two changes you can make safely, such as:

  • Visibility tweaks:
    • Move the store button to a more natural break (results screen, hub).
    • Add a subtle highlight or β€œNew!” tag.
  • Offer clarity:
    • Polish names and descriptions so the value is obvious.
    • Show contents more visually (icons, item counts).
  • Friction reduction:
    • Reduce the number of confirmation steps if they are redundant.
    • Fix known bugs around cancellations or timeouts.

Avoid:

  • Radical price changes based on tiny sample sizes.
  • Aggressive new placements that might feel pushy or spammy.

Think like this:

β€œWhat small, reversible changes can I make that clearly improve clarity or access without harming trust?”


Step 6 – Run a Second Test and Compare

After you implement your chosen tweaks:

  1. Run another short test window (similar length to the first).
  2. Collect the same metrics on the same dashboard.
  3. Compare:
    • Store open rate.
    • Purchase funnel conversion.
    • Distribution of purchases by offer.

Ask:

  • Did the change move the numbers in the direction you expected?
  • Did you introduce any new red flags (for example, complaints, lower retention)?

If the answer is:

  • Yes and no new issues β†’ keep or extend the change.
  • No improvement or new problems β†’ roll back or adjust.

The goal is to build a habit of experimentation, not chase a perfect result on the second build.


Step 7 – Keep Player Trust as a Hard Constraint

Throughout this process:

  • Treat player trust as a non-negotiable:
    • No surprise paywalls where none existed before.
    • No β€œoops, we doubled prices overnight” without a clear plan.
    • No manipulative placements during high-stress moments.

Use your data to:

  • Make the experience clearer and fairer, not just more profitable.
  • Identify offers that genuinely solve problems or unlock fun.

Healthy monetization:

  • Increases options for engaged players.
  • Does not punish those who cannot or do not want to spend.

Quick Checklist

Before moving on, make sure you have:

  • [ ] A clear diagram or description of your current monetization funnel.
  • [ ] A simple dashboard showing store opens, purchase starts, and completions.
  • [ ] A short list of red-flag patterns you want to fix.
  • [ ] 1–2 safe iteration ideas that you have now tried and measured.

In the next lesson you will start looking at longer-term KPIs and live ops, connecting monetization changes to retention, player satisfaction, and sustainable revenue instead of short-term spikes.