Monetization Review for Competitive Games

A monetization review for a competitive game answers three questions in order. Does the money path change who wins a match? Does a player see the real price before they pay? Would the store hold up if a platform reviewer or a consumer authority read it line by line? Answer those three and most of the usual monetization argument resolves itself, because almost every bad store decision fails at least one of them.

This is the review ProGameX runs before a competitive game commits to a content pipeline. It is not a pricing workshop and it is not a revenue forecast. It is a read of the store from the player’s seat, then from the reviewer’s seat.

Quick answer: A monetization review reads four surfaces of a competitive game. What each purchase changes inside a match, whether the player sees the real money price before paying, whether randomised items meet the odds-disclosure rules Apple and Google enforce at submission, and what you will measure once the store is live. Run it before the content pipeline is committed, because the findings usually change art scope. Access sales are the category teams misjudge most: in a game built on counters, selling access is selling matchups.

Contents

• What a monetization review actually checks
• Does the store change who wins?
• Can a player see the real price before they pay?
• Do your random items meet platform disclosure rules?
• Would your purchase flow survive a regulator reading it?
• What the review measures after launch
• The checklist
• Where this fits in production
• FAQ
• Sources checked on 1 September 2026

What a monetization review actually checks

Most monetization documents describe what the game will sell. A review checks what the selling does to the game. Those are different questions and they produce different work.

Four surfaces get read. The competitive surface is what a purchase changes inside a match. The price surface is what a player understands they are paying before they pay it. The compliance surface covers platform policy and consumer law as they apply to the store you built rather than the store you described. The measurement surface is what you watch after launch to know whether the store is working or quietly eroding the player base.

Teams often run the first surface informally and skip the other three until a storefront review rejects a build. That is an expensive order to work in. A store rebuilt after submission usually means reworked UI, reworked currency maths, and a delayed patch.

The paid version of this work sits on the game monetization review page. The checklist below is the same one, written out so a team can run it internally.

Does the store change who wins?

Arena play teaches a specific way of reading a match. Games are decided in pressure windows, the short stretches where one side has cooldowns available and the other does not. A player who wins consistently is a player who creates those windows and answers the other team’s.

Read your store the same way. Ask what each item does to a pressure window. A skin does nothing. A faster progression track does nothing inside the match, though it changes who is standing across from you at a given rank. Direct stat increases obviously matter. The category teams argue about most is access.

Character, hero, deck or loadout access is a power sale in any game built on counters, whatever the shop copy calls it. If a common composition has one clean answer and that answer sits behind a purchase or a long grind, the ladder is selling matchups. Players notice this faster than any other monetization problem, because they meet it as a loss rather than as a price.

Run three checks before the store design is locked:

• Can a non-paying player reach the same competitive ceiling, and how many hours does that take at realistic play rates? Write the number down. If nobody on the team can produce it, that is the finding.
• At equal rank, does the paying cohort win more? Instrument this before launch rather than arguing about it after.
• Does any purchase shorten the time to counterplay, rather than the time to content? Shortening time to content is a convenience sale. Shortening time to counterplay is a competitive sale.

Do this: Mark every purchasable item with one of the five categories above, then write the counterplay each access and power item unlocks. The items you cannot categorise cleanly are the ones to argue about.

Answering those questions well needs a clear read of who is actually playing and what they compare you against. That work belongs with player audience profiling and competitive analysis, not with the store spreadsheet alone.

Can a player see the real price before they pay?

Virtual currency is where competitive games lose price clarity. The item costs 850 coins, the packs sell in 500 and 1,200, and the player ends up holding a residue they can only spend by buying again. That pattern is now explicitly in scope for European consumer authorities.

In March 2025 the Consumer Protection Cooperation Network adopted Key Principles on in-game virtual currencies, prepared under the lead of the Netherlands Authority for Consumers and Markets and the Norwegian Consumer Authority. The European Commission’s statement on the principles describes them as covering clear and transparent pricing and pre-contractual information, avoiding practices that hide the costs of in-game content or oblige consumers to buy virtual currency, respecting the right of withdrawal, and respecting consumer vulnerabilities, in particular where children are concerned. The principles are the position of national authorities rather than new legislation, which makes them a reasonable design brief rather than a legal ceiling.

Practical checks that follow from that:

• Show the real money price next to the soft currency price at the point of purchase, not only in the top-up screen.
• Check pack sizes against your actual price points. If no combination of packs buys a single item cleanly, the residue is a design choice and it will be read as one.
• Make sure nothing in the flow forces a currency purchase where a direct purchase would do.
• Have an answer ready for withdrawal and refund requests that does not depend on a support agent’s discretion.

Do this: Price one real item end to end. Start with an empty wallet, buy the smallest pack combination that reaches it, and write down what is left over.

Do your random items meet platform disclosure rules?

If your game sells anything randomised, odds disclosure is a submission requirement on both major mobile stores, and the wording is specific.

Apple’s App Store Review Guidelines state under 3.1.1 that apps offering loot boxes or other mechanisms that provide randomised virtual items for purchase must disclose the odds of receiving each type of item to customers prior to purchase.

Google’s Play payments policy requires that apps and games offering mechanisms to receive randomised virtual items from a purchase, including loot boxes, clearly disclose the odds of receiving those items in advance of, and in close and timely proximity to, that purchase. The proximity wording is the part teams miss. Odds published in a patch note or a wiki do not sit in close proximity to the purchase.

Systems with pity timers, weighted duplicate protection or per-player adjustment need more than a static table. Google’s policy on chance-based reward programs asks for the odds where they are fixed, and the selection method where they are not, published in the official terms. If your drop system changes with player history, describe the mechanism.

Ratings bodies treat randomisation as a labelling matter as well. Since April 2020 the ESRB has assigned the In-Game Purchases (Includes Random Items) interactive element to any game with randomised paid elements, including loot boxes, gacha mechanics, card packs and prize wheels. Plan for the label rather than discovering it during certification.

Platform policies get revised. Check the current wording yourself before submission, and record the date you checked it in the build documentation.

Would your purchase flow survive a regulator reading it?

The clearest published example of a purchase flow being read this way is the United States Federal Trade Commission’s action against Epic Games. In March 2023 the FTC finalised an order requiring the company to pay 245 million dollars over what the Commission described as dark patterns that led players into unwanted purchases, including a button configuration the FTC called counterintuitive, inconsistent and confusing, and purchases by children without parental involvement. The order prohibits charging consumers through dark patterns or without affirmative consent, and bars the company from locking accounts of customers who dispute charges. A separate settlement covered a 275 million dollar penalty over children’s privacy.

That is one authority acting under United States law, so treat it as a design warning rather than a global rule. As a design warning it is a good one. It converts into checks any team can run in an afternoon:

• No purchase should be reachable by a single press of a button that also does something in gameplay.
• Confirmation should be affirmative and specific about what is being charged.
• The refund path should be findable by a player who is annoyed, not only by a player who is patient.
• Disputing a charge should never cost a player access to their account.
• If children can plausibly reach the store, the parental consent path has to work rather than exist.

In the United Kingdom, the principles for online and app-based games published as OFT1519 were adopted by the Competition and Markets Authority and are still published on gov.uk, with a note that the guidance predates the unfair commercial practices provisions of the Digital Markets, Competition and Consumers Act 2024, which came into force on 6 April 2025. Read the old principles for the reasoning and check current guidance for the rules.

Do this: Walk the full purchase and refund path on a controller and on a phone, as a player with no documentation open, and record every point where a charge could happen without a deliberate confirmation.

What the review measures after launch

A monetization review that ends at launch is half a review. The store is a system that interacts with matchmaking, progression and patch cadence, so it needs instrumentation that shows those interactions.

Useful signals for a competitive game:

• Share of active players who buy anything, tracked separately from average spend. Average spend hides a small paying group.
• Win rate by spend cohort at equal rank. This is the number that tells you whether you sold advantage.
• Non-paying player retention across store updates. A store patch that moves this is a balance patch.
• Refund and chargeback rate by item type. Randomised items and bundles usually behave differently.
• Support ticket categories tied to purchases, read as text rather than as a count.

We do not publish target numbers for these, because a benchmark taken from another game’s genre, region and price point tells you very little about yours. Set your own baseline in the first weeks and watch the direction. Choosing what to track, and what a healthy direction looks like for your game, is the job of game metrics design.

The checklist

Run this against a build, not against a document.

1. List every purchasable item and mark it cosmetic, convenience, progression, access or power.
2. For each access and power item, write the counterplay it unlocks or removes.
3. State the hours a non-paying player needs to reach the competitive ceiling.
4. Instrument win rate by spend cohort at equal rank.
5. Check that soft currency packs can buy real items without forced residue.
6. Show real money prices at the point of purchase.
7. Publish odds for every randomised item, next to the purchase, and describe the selection method where odds are not fixed.
8. Confirm the ratings label your randomised content will attract.
9. Walk the purchase flow on a controller and on a phone, looking for single-press charges.
10. Walk the refund path as an annoyed player with no documentation.
11. Test the parental consent path if minors can reach the store.
12. Record the date you last checked each platform policy, and put a review date in the release calendar.

Where this fits in production

Run the review before the content pipeline is committed, not after the first season is built. The findings usually change art scope, and art scope is the expensive part. On a prototype, the same questions belong inside prototype feasibility work, where a store idea can still be cut for the cost of a conversation.

If you want this run against your build rather than your design document, contact ProGameX with the build, the store list and the current player numbers you have.

FAQ

What is a monetization review for a competitive game?

It is a structured read of everything a game sells, checking what each purchase changes inside a match, whether players see the real price before paying, whether the store meets platform disclosure rules, and what you will measure after launch. It looks at the built store rather than the monetization plan.

Is selling character or hero access pay to win?

In a game built on counters, access sales behave like power sales. If a common composition has one clean answer and that answer sits behind a purchase, players meet the paywall as a lost match. Whether that is acceptable is a design decision, but it should be made deliberately rather than described as convenience.

Do I have to publish loot box odds?

On mobile, yes. Apple’s App Store Review Guidelines require disclosure of the odds of receiving each type of item before purchase, and Google Play requires the odds to be disclosed in advance of and in close proximity to the purchase. Where odds are not fixed, Google asks for the selection method in the official terms. Check the current wording before each submission.

When should a competitive game run this review?

Before the content pipeline is committed. Findings tend to change what art and systems work gets built, so running the review late converts a design conversation into a rebuild.

Sources checked on 1 September 2026

• Apple App Store Review Guidelines, section 3.1.1
• Google Play payments policy and Play policy on chance-based reward programs
• European Commission on the CPC Network Key Principles on in-game virtual currencies
• FTC order requiring Epic Games to pay 245 million dollars
• ESRB, In-Game Purchases (Includes Random Items)
• Online and app-based games: consumer law compliance principles (OFT1519, adopted by the CMA)

ProGameX is an independent gaming studio. This article is production guidance, not legal advice. Confirm platform policy and consumer law requirements for your own markets before you ship a store.

ProGameX note

A store is a systems change, not a revenue setting.

ProGameX can run this review against a build and return the findings as production notes.

Review a game store