Subscription Price Increases and Cohort ROAS: Reading Before-and-After Results

When you raise a subscription price for new users only, existing subscribers keep renewing at the old price. Revenue by calendar day then mixes two price levels in one line, so a price change can look better or worse than it is. Splitting install cohorts before and after the change lets you read its effect on ROAS without older renewals hiding it.

Store Rules for Legacy Subscribers

How you execute a price increase in the app stores determines whether your existing subscriber base experiences a sudden churn event or continues renewing quietly in the background. Even a simple notification gives passive subscribers a prompt to reconsider their subscription and cancel.

If your goal is to test how new paid users respond to a higher price without disturbing your recurring revenue base, you have two structural options in your store configuration. You can either grandfather existing subscribers into their original price tier when updating the product, or you can create a brand-new subscription product ID for the higher price and display only that new product on your current paywall. Either way, the billing mechanics are isolated: users who subscribed before the change keep paying the old rate on every renewal cycle, and only users seeing the updated paywall enter the higher-priced funnel.

Why Keep Existing Users on Old Prices

Leaving current subscribers on their legacy rate is not just about avoiding store notification prompts; it also protects the baseline of your paid acquisition experiments. When you raise prices across the board, two variables shift simultaneously: the conversion rate of newly acquired installs and the retention rate of your older cohorts. If your monthly revenue dips or spikes the following week, you have to untangle how much of that movement came from existing users reacting to a billing change versus how much came from new users reacting to the paywall.

By holding legacy subscribers at their original price, you turn your existing user base into a stable control group. Their renewal behavior continues along its established curve. Meanwhile, every dollar of new ad spend on channels like Meta, Google, Apple Ads, or TikTok is directed entirely at the new pricing tier. The only challenge left is making sure those steady legacy renewals do not leak into the metrics you use to judge your new ad campaigns.

Splitting Pre- and Post-Change Cohorts

A standard calendar-view revenue chart cannot separate those two groups because a renewal from a user who installed three weeks ago at the old price lands on the exact same calendar day as an initial subscription from a user who installed today at the new price. To isolate the price test, you need to evaluate performance using cohort ROAS, which tracks revenue by the number of days since install and counts revenue only from users who installed during that specific cohort window.

In the Revenue Report, you can define cohort conditions using the specific events users generated, the types of those events, and how frequently they generated them. When you set the Start Event to Install, the cohort restricts its scope to users who installed within your selected date range and displays the revenue data generated by that exact group.

The report's date range represents the time span covered by the report and follows your app's time zone. You can then pull one date range for the days leading up to the price change and a separate date range starting the day after the rollout. The transition day itself will contain a mix of both prices, so excluding that single day from your before-and-after comparison keeps both cohorts clean.

Reading ROAS Across Cohorts

Once your before and after cohorts are separated by install date, you can compare how fast each group pays back its acquisition cost. ROAS (%) measures the revenue generated from revenue events by those start-event users as a ratio of your ad spend. In the Airbridge Revenue Report, setting the Start Event to Install and selecting ROAS with Cumulative aggregation lets you read Day 1, Day 7, and Day 30 performance on the exact same row.

Reading those milestones side by side across your old-price and new-price cohorts shows how the price hike shifts your payback curve:

• If a higher price lowers trial-to-paid conversion, your Day 1 or Day 7 cumulative figure might start slightly slower, or it might jump immediately if the higher ticket size outweighs the drop in conversion volume.
• As the cohort matures toward Day 30 and beyond, renewal events need to stay attached to the original install cohort rather than floating into the current week's numbers. When subscription events are sent through the RevenueCat, Adapty, or Superwall integration, both Subscribe and renewal revenue are placed inside the same cohort.
• If you want to check how specific creative angles or targeting groups are handling the new price point, the Actuals report groups your installs, trial starts, First Subscribe (App) events, and subscription revenue across campaign, ad group, and ad creative levels.
• Waiting a full month to see if a price increase improves long-term return can feel slow when you are paying for ads daily. You can use Predictive LTV when your report's date range starts at least 3 days before today (with 13 or more days recommended for accuracy), the granularity is set to Daily, the Start Event is Install (App), and the cohort contains at least 30 users.

Pitfalls That Skew Price Comparisons

Even with clean install cohorts, three tracking traps can distort your before-and-after ROAS comparison when you raise prices.

First, relying on a day-one ad-platform dashboard number will almost always misrepresent the test. That number is typically calendar-window revenue, meaning it mixes in renewals from older cohorts alongside bookings that are later cancelled or refunded; measuring cohort ROAS by day since install removes the renewals from older cohorts.

Second, refunds can arrive after a trial converts. If you only look at gross bookings, the new price tier can look more profitable on Day 7 than it ends up. If you need refunds netted out, confirm which billing events your integration sends before treating Day-N revenue as net.

Third, mismatched user identifiers between your attribution SDK and your subscription billing tool can corrupt your user counts right in the middle of an experiment. For example, when integrating with a tool like RevenueCat, the User IDs logged in the Airbridge SDK and in RevenueCat must be identical for subscription data to connect properly. If a matching User ID cannot be found in RevenueCat, a random User ID is generated instead, which can inflate the number of users displayed for subscription-related events above the actual figure. Before you compare conversion rates or per-user value across price tiers, verify that both systems pass the exact same identifier upon app launch and login.