Google Play has separated billing fees from store service fees, which used to arrive as a single deduction. It has also introduced a reduced rate of 15 percent for developers who join the Apps Experience Program or the updated Games programme by meeting defined quality benchmarks.
If you sell anything through an app, the number you have been assuming is probably wrong in one direction or the other. It is worth twenty minutes to establish what you actually pay, because on any meaningful revenue the difference between rates is a salary.
Why splitting the fee matters
Previously a percentage came off and that was that. Now the deduction has two components with different logic: a service fee for distribution, discovery, review and the platform itself, and a billing fee for processing the payment.
The practical significance is that the components can move independently, and in some configurations you can influence one of them. A single blended percentage is something you accept. Two itemised fees are something you can examine, and at least one is affected by how payment is handled.
It also makes comparison possible for the first time. When the deduction was one number, comparing a store against an alternative channel meant comparing unlike things. Separated, you can see what you are paying for distribution and what you are paying for payment processing, and the second one has a market rate you already know from the web.
What the reduced rate requires
The 15 percent tier is tied to quality benchmarks rather than to revenue, which is a meaningful change from the earlier revenue threshold approach.
That means it is achievable by improving the app rather than by staying small. Technical quality, crash rates, ANR rates, adherence to current requirements, and user experience standards all feed in. Many developers already meet most of it and have simply never enrolled, because there was nothing prompting them to look.
Work out what your revenue difference would be at 15 rather than 30 percent, then decide how much engineering effort that justifies. For an app turning over a modest amount monthly, halving the fee typically pays for the quality work several times over within a year, which makes it one of the better returns available on engineering time.
The benchmarks also overlap heavily with things worth doing anyway. Crash rate and ANR rate are what make people uninstall, so the work has a second return that does not appear on the fee line. We covered that side in why nobody opens your app after day one.
Check what you are actually being charged
Most teams cannot state their current effective rate without looking it up, and the assumed figure is frequently out of date.
Open the financial reports in Play Console and calculate it yourself: total deductions divided by gross revenue over a recent quarter. That gives you the effective rate including everything, rather than the headline number.
Compare that against what you assumed. If they differ, find out why before doing anything else, because the explanation is usually a category or a programme you did not know applied to you.
Then check whether your pricing was set with the old figure in mind. Many apps priced their subscription by working backwards from a 30 percent deduction. If you now pay 15, you have either more margin than you planned or room to reduce price, and that is a decision worth making deliberately rather than leaving as an accident.
We have found clients on the higher rate purely because nobody revisited the console after a programme changed. The money is recoverable going forward and not backwards, which makes this worth checking this week rather than next quarter.
Read More - AI Sends a Fraction of the Traffic and Several Times the Customers
The alternative store question
Google is also introducing a Registered App Stores programme, allowing stores meeting security and quality standards to register with a simplified installation flow.
For most businesses this is not an opportunity to act on. Distribution outside the main stores means solving discovery, updates and trust yourself, and those are the things the fee pays for. The developers for whom it makes sense are typically those with an existing audience they can direct, and even then it is a project rather than a switch.
What it does provide is context for the fee conversation. The store fee exists partly because there was no realistic alternative. As alternatives become slightly more realistic, the pressure on that fee changes, which is a reasonable part of why the structure is being adjusted at all.
What to do this month
Calculate your actual effective rate from the last quarter's reports rather than from memory.
Check whether you qualify for the reduced tier, and if not, what specifically is missing. The requirements are published and mostly measurable, so this is a checklist rather than an investigation.
Then model your revenue at both rates, and treat the difference as the budget available for the quality work. That framing usually makes the decision straightforward, because the work is typically smaller than the annual difference.
Apple is restructuring on the same timeline, replacing a per install fee with a commission from 1 October, which we went through in Apple's Core Technology Commission.
If your app has drifted on the technical quality metrics, our mobile app development team treats crash rate and ANR work as a defined piece rather than an open ended engagement, which makes it easy to weigh against the fee saving.
The arithmetic takes an hour and we rarely see it done. Teams estimate the difference from memory, and the estimate is usually wrong in whichever direction suits what was already decided.
Frequently Asked Questions
How do I find my actual fee rate?
Divide total deductions by gross revenue in the Play Console financial reports over a full quarter. That gives the effective rate including every component, which is usually more informative than any single published figure and frequently differs from what the team assumes.
Is the reduced rate based on revenue or on quality?
Quality benchmarks under the current programme, which is a change from earlier revenue based thresholds. That means it is reachable by improving the app rather than only by remaining below a revenue level, and many established apps qualify already without having enrolled.
What counts as a quality benchmark?
Technical performance measures such as crash rate and ANR rate, adherence to current platform requirements, and user experience standards. They are published and measurable, and most of them are things worth fixing regardless of the fee, because they are also what drives uninstalls.
Does this apply to iOS as well?
Apple runs its own programmes with different criteria, including a reduced rate for smaller developers. The structures are not equivalent, so if you ship on both you need to work out each separately rather than assuming one figure covers your business.
Should we consider alternative app stores?
For most businesses, no. You would take on discovery, update delivery and trust, which is most of what the fee buys. It is worth understanding as context for the fee rather than as a plan, unless you already have an audience you can direct without the store's help.
We priced our subscription assuming 30 percent. What now?
Decide deliberately what to do with the difference rather than letting it sit. More margin is a legitimate choice. So is reducing the price to compete. What you want to avoid is a price set by an assumption that stopped being true and nobody revisiting it.
How often do these terms change?
Often enough that an annual review is sensible, and both stores announce changes on their developer sites with lead time. The failure mode is not the change itself, it is finding out about it a year later from an invoice.
Talk to our team if you are not certain what rate your app pays or what would be needed to reduce it.