Google Play Subscription Price Changes in 2026: Cohorts, Opt-In and Opt-Out

Raising the price of a Google Play subscription is not a pricing decision that happens in your own backend. It is a sequence of platform events with fixed clocks, and the default behaviour surprises almost everyone the first time: your existing subscribers keep paying the old price and nothing changes for them until you explicitly end their legacy price cohort. This checklist is the order of operations, the caps, and the notice obligations that decide whether a price increase lands or quietly churns your base.

Everything below is grounded in Google's own documentation — Change subscription prices (Android Developers), Understanding subscriptions, and Create and manage subscriptions (Play Console Help), all checked on 2026-10-28.

Two objects carry a price: the base plan and an offer (a pricing phase). They do not behave the same way after a purchase.

• Changing the base plan price applies to new purchases immediately, and puts everyone still on the old price into a new legacy price cohort — a new cohort is created each time you change the price.
• Changing an offer's pricing phases cannot be applied to existing subscribers at all. Offers are an acquisition tool; they are not a way to re-price your installed base.

If the plan is "raise revenue from current subscribers", only the base plan path exists. Deciding this first avoids renegotiating the whole launch with your team a week later.

Cohorts, migration, notification clocks and opt-out eligibility are all evaluated per country/region. Two practical consequences:

• You can end a cohort in one region and leave it in place in another; a mixed decision is normal, not an error.
• Programmatic price updates must use the parent region code. Google's own example: purchase-status APIs may report PR for Puerto Rico, but a price update sent with PR fails with an error saying the region is not billable — you must send US. Child territories of a parent region behave this way for billing purposes.

Pull the list of regions where the base plan is actually selling before you compute anything. A price rise in a low-volume region can create a notification obligation out of proportion to the revenue it brings.

A decrease needs no consent. When the new price is lower, subscribers are notified by email and start paying the lower price at their next renewal. One timing detail is worth writing into your support macros: payment authorization can happen up to 48 hours before renewal, and up to 5 days for users in India or Brazil, so a user already authorized at the old price simply renews at the lower price the following cycle.

An increase is the opposite: by default it is an opt-in change, and opt-out is a privilege with conditions rather than a setting you flip. Treat decrease and increase as two separate projects with different owners and different notice templates.

For an opt-in increase, the documented mechanics are precise:

• Users are charged the higher price the next time they pay, following an advance notification period of 37 days.
• Starting 30 days before that charge, Play notifies existing subscribers by email and push notification.
• During the first seven days after you trigger the migration, Play sends nothing — that window is yours to communicate first.
• A subscriber who never accepts is automatically cancelled at the first renewal where the new price would apply.

So the real planning number is not "37 days" alone: it is seven days of your own notice, then thirty days of Google's, then a renewal that either converts or cancels. Budget the churn conversation for the week the Play emails go out, not the day you change the price.

An opt-out increase charges users without their action unless they cancel. Google restricts it on four axes, and the Console enforces them:

• Geography: only certain countries/regions are supported, and the minimum advance notice there is either 30 or 60 days depending on the country.
• Standing: only developers in good standing on Google Play.
• Frequency: one opt-out increase per subscription base plan, per country/region, in any 365 days.
• Amount: no more than the greater of 50% of the price the user currently pays, or 17 US cents per day, converted to local currency.

If a cohort fails any of these, the Console shows it as an opt-in increase. You can still proceed — but the plan just became "ask every subscriber", and the churn math changes with it.

Starting an opt-out increase requires a certification in Play Console, and both parts are load-bearing:

• Your terms of service must reserve your right to increase subscription prices with advance notice, and provide clear and valid reasons for such increases.
• At least 30 days before the increase takes effect, you must show each affected user a prominent in-app notice containing, at minimum: the subscription name, the current price, the new price, the date the new price applies, and how to cancel.

The notice must appear on every device type where the app is available — mobile, TV platforms, streaming devices. Watch devices are the single documented exception, where it is recommended rather than required. An in-app banner that only ships to phones is not compliant for a TV build of the same app.

Opt-in increases convert better when the user can accept inside the app, and Play provides that path through in-app messaging with the TRANSACTIONAL message category. Two implementation details decide whether it works:

• The opt-in prompt is shown from the first day the user can accept, at most once every 7 days. It is a nudge, not a countdown banner.
• When the user accepts, you receive SUBSCRIPTION_STATUS_UPDATED together with a purchase token; refresh the subscription state through the Google Play Developer API with that token instead of assuming success locally.

Call the check whenever the app opens. A price increase the app never surfaces is functionally identical to a silent cancellation at the renewal boundary.

Wrong price typed into the wrong region is a real incident class, and Google documents the escape routes:

• Opt-in: set the base plan back to the original price and initiate a price decrease from the legacy price points page. If you revert within seven days, existing subscribers are not notified about the accidental change at all.
• After seven days, the change is cancelled for any user who has not yet paid the new price, effective after the payment authorization window of up to five days — but some users will already have received the opt-in email, because renewals are individual.
• Opt-out: the same revert path applies, and the cancellation also waits on that up-to-five-day authorization window.

Write the region rollback steps down before the migration starts. During the incident nobody reads a 700-line help article accurately.

Two product types break the "the change is immediate" mental model:

• Installment subscriptions: a price change for a legacy cohort takes effect at the end of the active commitment period. You cannot change the price a user is mid-way through paying. If your cash-flow model assumes the increase lands next month, it may land several months later.
• Subscribe with Google: Google's own documentation warns that you should not change the price of a Subscribe with Google subscription. Treat those products as out of scope rather than as an edge case to test in production.

Ending a legacy price cohort is the step that actually moves your installed base, and it has three properties that deserve a second pair of eyes:

• It only moves users to the current base plan price. You cannot migrate a cohort to any arbitrary price; the price you want has to be the base plan price first.
• Ending one cohort ends the previous cohorts for the same base plan and countries. Cohorts created by older price changes are not preserved independently.
• It disappears from view once started. After a migration begins, that legacy price cohort no longer appears in Play Console even if the migration is not yet complete — so the Console audit trail must be captured beforehand. The Console change log records when prices were updated, who initiated the change, and which regions were touched.

The API equivalents, for teams managing a large catalogue: monetization.subscriptions.patch sets the new base plan price through RegionalBasePlanConfig, and monetization.subscriptions.basePlans.migratePrices ends the cohort with a list of RegionalPriceMigrationConfig objects — which is also what triggers the price change notifications to users on a historical price older than the timestamp you supply.

None of the above predicts conversion or churn: Google publishes the mechanics, not opt-in rates by price step or region, and any number quoted for those would be invented. What the documentation does fix is the sequence — legacy cohort created, notification window opened, acceptance or cancellation, migration completed — and every one of those steps has a date you can plan against.

Sources: Android Developers — Change subscription prices (developer.android.com/google/play/billing/price-changes): new purchases within hours, legacy price cohort default, 37-day advance notification period, 30-day Play notification, the first-seven-day developer window, price decreases and email notification, 48-hour and 5-day payment authorization, in-app messaging with TRANSACTIONAL and SUBSCRIPTION_STATUS_UPDATED, installment commitment periods, the Subscribe with Google warning, migratePrices behaviour, and parent-versus-child region codes. Play Console Help — Understanding subscriptions (support.google.com/googleplay/android-developer/answer/12154973): legacy cohort creation per price change, offers not re-priced for existing subscribers, opt-in versus opt-out definitions, opt-out criteria (supported countries, good standing, one per 365 days, greater of 50% or 17 US cents per day), the certification requirements and the all-device-type in-app notice. Play Console Help — Create and manage subscriptions (support.google.com/googleplay/android-developer/answer/140504): View legacy price points flow, cohort start-date selection, prior cohorts ending together, and the migration review step. All three checked on 2026-10-28.