Android Monetization

Android Monetization

This is the monetization stage of the Android app pipeline. It runs after planning has chosen a product shape and before design builds screens, because a free ad-supported app, a one-time purchase, and a $6.99/mo subscription are three different products that need three different onboarding flows and paywall surfaces. Deciding the money model here means design doesn't have to retrofit a paywall onto screens that weren't built for one.

Pipeline position:

research  ->  planning  ->  > MONETIZATION >  ->  (replan)  ->  design  ->  MCP code  ->  polish

Core philosophy

1. Planning picks the model; monetization makes it real. Planning answered which of the five models. This stage answers exactly how it works - price, paywall, free tier, events, SDK, compliance.
2. The paywall is a product surface, not a popup. Where it sits in the flow (and what value precedes it) determines conversion far more than the price does.
3. Monetization can break the product - surface it. If the chosen model contradicts the loop, the retention curve, or the activation moment, that's a planning problem. Invoke the replan rule rather than quietly shipping an incoherent app.
4. Match the model to the retention curve. Subscriptions need a sticky daily/weekly loop to justify recurring cost; one-time purchases suit tools with a clear up-front value; ads need high session frequency to earn. A mismatch here is the most common monetization failure.

When this triggers

• Automatically after android-product-planning produces a spec (the spec's monetization field is the input).
• "How should this make money", "add a paywall", "what should I charge", "set up subscriptions".

When NOT to trigger: apps explicitly scoped as free/no-monetization (note it and move on), or pure design/code tasks.

Inputs from the planning spec

Read these fields from the planning spec before starting:

• Model - the five-way choice (free+ads / one-time / freemium subscription / IAP / B2B-strategic-free).
• Paywall placement - the high-level "after which value moment".
• Free-tier scope - what's free vs. paid.
• Compliance notes - anything Play Store / law requires.
• Plus the loop, retention targets (D1/D7/D30), and activation event - needed for the retention-vs-model check.

If a market-research brief exists, pull its monetization norms section for category-typical price points.

Step 0 - should this even be monetized?

First gate, before anything else: does this app need to make money at all? Plenty of apps - personal projects, simple utilities, throwaway builds, free-as-strategy - should ship free with no paywall, no billing SDK, no funnel. If so, record "Free - no monetization in v1" with a one-line reason and stop. Do not bolt a freemium machine onto an app that does not need one; that is the most common failure of this stage.

A rough revenue model - before you pick a model

If it should be paid, do crude arithmetic before choosing a model. With explicitly stated assumptions, estimate: monthly installs (order of magnitude), install-to-activation %, activation-to-paywall-view %, paywall-to-purchase %, the price, and for subscriptions an assumed monthly churn. Produce a back-of-envelope monthly revenue and rough LTV for each candidate model. Tag every input "assumption - confirm." Precision is not the goal; resting the model choice on numbers instead of vibes is. If the math shows a one-time unlock badly undercaps revenue versus a subscription, say so as an accepted trade-off rather than burying it under a fairness story.

The monetization decisions

Work through these and record each explicitly. Mark "N/A - reason" where a decision doesn't apply.

1. Model rationale. Why this model fits this loop, this retention curve, and the rough revenue model above - not just positioning (a fairness or differentiation story is positioning, not economics). If it doesn't fit, stop -> replan.
2. Price. Exact price(s). For subscriptions: monthly + annual, the annual discount, and any intro/trial. Note regional / purchasing-power-parity adjustments for major markets.
3. Free-tier scope. The precise line between free and paid. Free has to deliver the activation moment; paid has to feel worth it.
4. Paywall placement. The exact point in the flow, tied to a value moment the user has already felt. Hard wall, soft wall, or metered?
5. Paywall content. The value props shown, the plan layout, the primary CTA copy, and the "restore purchases" affordance (required by Play).
6. Funnel events. The events to instrument: install -> activation -> paywall view -> trial start -> purchase -> renew/churn. Name them so design and code wire them in.
7. Billing implementation. Google Play Billing directly, or a wrapper like RevenueCat (faster for subscriptions + entitlements + receipt validation). State the choice and why.
8. Compliance. Play Store subscription policy (clear terms, no dark patterns, easy cancellation), trial/intro disclosure, restore flow, and Data Safety implications of any ads/attribution SDK.
9. Experimentation. What to A/B first (usually paywall placement or price), and the metric that decides it.

The replan rule

If a monetization decision changes the product - e.g. a subscription requires onboarding the planning spec didn't include, or the model needs a feature that isn't in scope - stop and route back to android-product-planning. Don't silently expand scope. Name the conflict: "A subscription needs a recurring-value loop; the current loop is one-and-done. Either change the model or change the loop."

Output

Produce a monetization section that the design skill consumes:

• Model + rationale
• Pricing (with regional notes)
• Free vs. paid table
• Paywall: placement, value props, plan layout, CTA copy, restore affordance
• Funnel events to instrument
• Billing SDK decision
• Compliance checklist
• First experiment

Hand-off to design

Hand the paywall placement, content, and free/paid split to android-compose-design - it builds the paywall and any gated screens in the chosen visual style, and wires the funnel events into the UI. The billing SDK and event names flow into the MCP coding stage.