Pricing Strategy and Business Model Questions

Direct answer

Treat each country as its own pricing problem with a shared method: set a local price in local currency from three inputs (willingness to pay, local competitor prices on a like-for-like basis, and cost and tax), then test within the country rather than copying a converted US price. Compare against local competitors after putting every price on the same basis: tax treatment, currency, billing unit, and included features. Test using randomised price points within each market where volume allows, and staggered launches with a comparison market where it does not.

Step 1: set the local price

1. Start from value, not exchange rate. Willingness to pay (WTP) varies with income and local alternatives. Purchasing-power parity (PPP) is a measure of how much a basket of goods costs locally relative to a reference country, so it indicates how heavy a given price feels to local buyers. Use it as a guide to the price level, not as a formula.
2. Estimate local demand sensitivity. Run a price-sensitivity survey or conjoint in each large market, and for smaller ones pool markets in a hierarchical model (a model that estimates each country's price elasticity while pulling thin-data countries toward the group average). Price elasticity is the percentage change in sales for a one percent price change.
3. Add cost and tax. Local payment fees, support cost and taxes change margin. Confirm whether the price shown is tax-inclusive (the tax is already inside the shelf price, common for consumers) or tax-exclusive (tax such as VAT, a sales tax collected at each stage of the supply chain, is added on the invoice, common in business-to-business) and what the tax authority requires on invoices.
4. Check the rules with legal and tax. Sales-tax or VAT registration thresholds, invoicing rules, currency and payment-method rules, and whether local law or app-store rules restrict charging different prices across borders (and what stops customers from buying in the cheaper market). I would not state any country-specific rule from memory in a design; I would get counsel's confirmation.
5. Pick local price points that look native (rounded, with a pricing page that reads in the local currency) and set a review trigger for currency moves, such as a monthly review of the exchange rate and a rule that a drift beyond a pre-agreed band reopens the price.

Step 2: compare against local competitors fairly

Put each competitor price through the same pipeline: remove tax, convert, normalise the unit, and adjust for features.

All rates and levels here are illustrative inputs. Our own list is $55 net of tax in each market (the same $55 is compared with each market's competitor in turn, so the comparison is repeated per market). We are 10% above the Market A competitor ($55 / $50 = 1.10) and 8.3% below the Market B competitor ($55 / $60 = 0.917). The last row shows the Market B competitor is expensive relative to local buying power, which suggests lower WTP there and room for a lower local price (to be tested, not assumed).

How to read the price-level row: a local price level is what a standard basket of goods and services costs in that market compared with a reference country (set to 1.00). A level of 0.95 means Market A's basket costs 95% of the reference basket and 0.45 means Market B's costs 45%, so a dollar buys far more locally in B. International statistics bodies publish these as price level indices (look up the current values for real markets; the figures here are illustrative). Dividing a USD price by the level restates it in reference-country purchasing power: $50 / 0.95 = $52.63 and $60 / 0.45 = $133.33, so the Market B competitor's $60 feels like $133 to a reference-country buyer, which is why it signals weaker local demand at that price. The tax step matters for the same reason: removing 20% tax takes the Market A shelf price from 4,800 AA to 4,000 AA, about 17% lower, and comparing 4,800 with Market B's 2,400 without that step would put the two prices on different bases.

Then adjust for features included (map their tiers to ours, and compare price per equivalent bundle, using conjoint WTP to value the differences), billing unit (per seat vs per usage), contract terms (annual vs monthly), and local competition (an international vendor and a local incumbent are not equally priced or equally trusted). Beware of comparing web list prices with what customers actually pay after local discounting.

Step 3: test locally

• Within a country: randomise visitors or new accounts to two or three price points and measure conversion, plan mix and 90-day retention. The unit is the account, and run long enough to see renewals.
• Where traffic is thin: stagger the launch across similar markets and compare with difference-in-differences (the change in the launched market minus the change in a comparable unlaunched market).
• Guardrails: watch refunds, chargebacks (card payments the customer disputes with their bank, which claws the money back), cross-border purchases and support cost per market.

Worked decision

Take Market B, where the competitor in the table charges $60 and our list is $55 net of tax, converting at 3% on the pricing page, and suppose we test $45. If the elasticity estimated from the test is -1.5, the drop from $55 to $45 is -18.2% in price (45 / 55 = 0.818), so the simple rule (percentage change in sales = elasticity x percentage change in price) predicts conversion up about 27%, from 3.0% to about 3.8%, while revenue per signup falls 18.2%. Revenue per visitor changes by 1.27 x 0.818 = 1.04, roughly +4%. That simple rule is accurate only for small moves; with a constant-elasticity curve the volume factor is (45 / 55)^-1.5 = 1.35 and the result is 1.35 x 0.818 = 1.11, about +11%. Either way the cut pays off only if the elasticity holds and cost to serve does not rise, so I would adopt it only if the lift survived through renewals.

Trade-offs and pitfalls

• Pure FX conversion makes prices swing with currency markets; pure PPP ignores that business buyers often benchmark to global prices.
• Large price gaps across borders invite arbitrage (buying through a cheaper country).
• Tax-inclusive vs exclusive confusion is the commonest comparison error.
• Small markets tempt you to skip testing; use pooled estimates and small staged tests instead.

Direct answer

Before shipping the 5% base-fare increase I would first simulate it with a simple demand model, then validate it with a geography-and-time experiment (a geo experiment gives different regions different prices; a switchback alternates one region between prices over time blocks) rather than a rider-level A/B test. The metrics to simulate fall in four groups: demand (requests, conversion, completed trips), revenue (GMV, which is gross merchandise value, the total fares paid; and net revenue after the platform's take rate, its percentage cut), supply participation (online hours, acceptance, earnings per hour) and satisfaction (ratings, repeat rate, complaints). The key unknown is price elasticity of demand: the percentage change in trips for a 1% change in price. It is negative: an elasticity of -1 means a 1% price rise loses about 1% of trips.

Step 1: simulate before testing

Use a constant-elasticity model: trips after = trips before x 1.05^e, where e is the elasticity (negative). Illustrative inputs: 100,000 trips per week, an average fare of $20, a 25% take rate (platform revenue is 25% of GMV), and fares rising 5% to $21.

Baseline GMV is 100,000 x $20 = $2.000M and platform revenue is $500k. Reading it: when demand is less elastic than -1 the increase raises GMV, at -1 it is neutral, and beyond -1 it loses money. Pull the plausible range of elasticity from past price changes, promotions and surge-price episodes, and carry the whole range through, since the answer is most sensitive to it.

The supply side changes the picture. Decide who receives the extra fare: if it goes to providers (drivers, hosts, sellers), take rate falls but supply hours and acceptance should rise, shortening waits and partly offsetting the demand loss. If the platform keeps it, take rate rises and supply gets no new reason to show up. Simulate both splits. At e = -0.8 (96,172 trips a week at $21; today providers receive $15 a trip and the platform $5), the table above splits the extra dollar in proportion (platform $5.25 a trip, $504.9k). At the extremes: if the platform keeps the extra dollar it earns $6 a trip, 96,172 x 6 = $577.0k a week (+15.4% against $500k, take rate 28.6%) with no new reason for supply to show up; if providers get it they earn $16 a trip (+6.7%) and the platform earns $5, 96,172 x 5 = $480.9k (-3.8%, take rate 23.8%), the price of attracting more provider hours and shorter waits, which the experiment must then measure. Also check what share of the all-in price the base fare is: if fees and taxes sit on top, a 5% base increase is a smaller percentage change to what the customer pays, so the elasticity must be applied to the all-in price.

Metrics tree

Step 2: validate with an experiment

Randomising individual customers is unsafe here because treated and untreated customers share the same pool of providers. A user-level test relies on SUTVA (stable unit treatment value assumption: one unit's outcome does not depend on which arm other units are in). It fails in marketplaces, which biases the result.

• Design: a switchback or geo experiment. Randomly assign comparable regions (or time windows within a region, such as alternating blocks) to the new fare or the current fare, stratified by region size and day of week (first group regions or time windows of similar size and day of week, then randomise within each group, so both arms are alike).
• Duration: long enough for providers to react (supply adapts over weeks, not hours) and to see repeat behaviour, with a washout between switchback blocks (a gap whose data is discarded) so effects do not carry over.
• Analysis: compare regions with cluster-robust standard errors (error bars that treat all rows from one region as one correlated unit, because trips in a region are not independent); check pre-period balance (that treated and control regions behaved alike in the weeks before the test); report revenue per provider hour and trips with intervals.
• Guardrails: an automatic stop if wait time, cancellations or provider hours cross a pre-set line.
• Worked example (illustrative): 40 regions in 20 matched pairs by size, one region of each pair randomly given +5%, a 4-week pre-period and a 6-week test. If region-level noise in the change in trips, after adjusting for the pre-period, has a standard deviation of 4%, then 20 regions per arm can detect a difference of (1.96 + 0.8416) x sqrt(2 x 0.04^2 / 20) = 3.5%. The simulated trip loss at e = -0.8 is 3.8%, so it is just detectable; the 1% GMV effect is not, since it would need 2 x 7.849 x 0.04^2 / 0.01^2 = about 251 regions per arm. So size the test on trips, and judge revenue through the estimated elasticity: the price rise is worth shipping if the estimated trip loss is smaller than the 4.8% at which GMV is neutral (e = -1, since 1.05^-1 = 0.952).
• Decision rule: ship if net revenue per provider hour improves and no guardrail breaks; if demand loss is bigger than the simulation predicted, update the elasticity and re-run.

Pitfalls: novelty effects (people react to anything new) and price-anchoring effects (people judge later prices against the first one they saw) fade, so read week 1 cautiously; fare changes interact with promotions running at the same time; and a 5% change is small, so the experiment needs enough regions to detect it.

Direct answer

Roll out in stages that grow only when the data from the previous stage could actually have shown a problem. First run the model in shadow (it computes prices that are never shown) across all customers, including a dry-run of invoices (generating invoices at the new prices without sending them), to catch rare mechanical errors. Then expose 0.1%, 1%, 5%, 25%, 50% and 100% of customers, assigning at customer level, keeping a small holdout on the old pricing, with automatic rollback on technical guardrails and human review on business guardrails.

Terms. Canary is a small first exposure used to catch failures cheaply. Guardrail is a metric with a pre-set limit that stops or reverses the rollout. Holdout is a group kept on the old behaviour for comparison. Billing cycle is the period between invoices. Kill switch is a flag that instantly restores the previous behaviour. Sticky hash is a fixed scramble of the account ID, so the same account always lands in the same group. Leakage is customers learning about the other group's price. Chargeback is a customer disputing a charge with their bank. Parity with the old model means the new model's prices agree with the old one's wherever nothing should have changed.

Ramp schedule (3,000,000 customers; minimum times illustrative)

Why those sizes (arithmetic you can redo)

To detect a relative drop in a 5% conversion rate with 95% confidence (a 5% chance of a false alarm; z-value 1.96) and 80% power (an 80% chance of catching a real drop of that size; z-value 0.8416), the customers needed per arm (an arm is one group: the exposed customers or the control customers still on the old price) are n = 2 x (1.96 + 0.8416)^2 x p x (1 - p) / d^2, where p is the average of the two rates and d the difference. The 7.849 below is (1.96 + 0.8416) squared, which is 2.8016 squared. For a 10% relative drop: rates 5.0% and 4.5%, d = 0.005, p = 0.0475. Then 2 x 7.849 = 15.70; 15.70 x 0.0475 x 0.9525 = 0.710; 0.710 / 0.000025 = 28,409 per arm. For a 5% relative drop it is 116,475 per arm; for 20%, 6,746. So at the 1% stage the 30,000 exposed customers, compared with the control customers who stay on old prices, exceed the 28,409 needed per arm for a 10% drop. The 3,000-customer canary cannot see even a 20% fall in conversion; it exists to catch mechanical errors. At 3,000 customers a bug affecting 0.5% of invoices is found with near certainty (1 - 0.995^3000), but one affecting 0.05% only with probability 0.777 (1 - 0.9995^3000), which is why the shadow stage must dry-run every invoice across all 3,000,000 customers.

Assignment

Randomise by customer, with a sticky hash of the account ID, never by request: a customer who sees two prices will complain and contaminate the metrics. Watch for leakage when customers or neighbouring accounts compare prices.

Guardrails and rollback

Rollback mechanics: store a price version on every quote and invoice, keep the old table live, honour the quoted price for customers already charged, and issue credits for any overcharge. Rollback criteria are written before launch; the kill switch needs no meeting.

Monitoring for unintended effects

Reconcile quote, order and invoice daily; track tickets tagged price, refund requests, chargebacks and social or review mentions; watch sales escalations and partner or reseller conflicts; check tax and currency calculations; and compare the holdout's churn at 30, 60 and 90 days, since effects on cancellations show up late.

What would change this plan

If prices are quoted per request (consumer checkout) rather than billed monthly, the billing-cycle wait shrinks and ramps can be faster. If regulators require pricing explanations, add a human-readable reason to every price.

Direct answer

Build a repeatable framework with five parts: segment, choose price points, randomise at a level customers cannot see across, measure short-term conversion and long-term retention together, and set grandfathering and rollback rules before the first test starts. Start with new visitors only, never existing subscribers, test three to four prices around the current one, and judge on revenue and retention over a long enough window, using early retention as a proxy only with a long-running holdout to confirm.

Terms

• Grandfathering: letting existing customers keep their current price after a change.
• LTV (lifetime value): the total gross profit expected from a customer over their life with the product.
• Churn: the share of customers who cancel in a period.
• Willingness to pay: the most a customer is willing to pay.
• Holdout: a group kept on the old price to measure what would have happened without the change.
• Arm: one variant in the test, here one price.
• Cohort: a group of customers who started in the same period, followed together.
• Retention curve: the share of a cohort still subscribed at day 30, day 90, day 180 and so on.
• Revenue per visitor: total revenue from an arm divided by everyone who saw its price, converters or not.
• Trial-to-paid: the share of people who start a free trial who become paying customers.
• Price-ending convention: the pattern prices follow, such as always ending in 9 ($19 or $19.99); mixing patterns across arms would test the pattern, not the price.
• Price anchoring: how a nearby reference price (a crossed-out higher price, or a pricier plan next to it) changes what a price feels like.
• Feature flag: a switch in the product that turns a behaviour on or off for chosen users without a new release.
• Kill criteria: stop conditions agreed before the test starts, so nobody argues about them mid-test.

Framework

Short-term versus long-term

Use revenue per visitor as the first readout to decide whether to drop clearly losing arms, and retention for the final choice. Estimate LTV from the early retention curve, but keep a small holdout cohort on each surviving price for six months to check the extrapolation. Do not declare a winner on conversion alone.

Worked example (illustrative numbers)

Setup: a $20 a month plan, 80% gross margin (so $16 of gross profit per customer per month), four arms of $18, $20, $22 and $25. Sample size per arm: to detect a drop in conversion from 4.0% to 3.6% (a 10% relative change) with 80% power at a 5% significance level, you need about 2 x (1.96 + 0.84)^2 x 0.038 x 0.962 / 0.004^2 = about 36,000 visitors per arm. Four arms need about 144,000 visitors; at 6,000 new visitors a day that is 24 days.

How retention becomes LTV. Take the $20 arm: retention fell from 85% at day 30 to 70% at day 90, two months, so monthly churn is 1 - sqrt(0.70 / 0.85) = 9.2%. Assuming that churn continues, the expected lifetime is 1 / 0.092 = 10.8 months, and LTV = $16 gross profit x 10.8 = $173 (equivalently 16 / 0.092). Multiply by conversion (4.0%) to get $6.92 per visitor. The same steps give the other rows.

Reading it. On first-month revenue per visitor the first three arms are within a cent of each other ($0.79 to $0.80), so conversion and early revenue cannot choose between them. Retention separates them: $22 loses about 14% of LTV per visitor against control, and $25 about 34%. $18 and $20 are a statistical tie, so $20 stays unless a holdout shows $18 retains better. This is the case for the long window: the first-month readout would have called $22 a tie. Power caveat: the 36,000 visitors per arm were sized for the conversion difference, not for retention. At that size the $20 arm has about 1,440 customers and the $22 arm about 1,296, so the 70% versus 67% day-90 retention gap has a z of about 1.7 (p about 0.09) and is not significant at the 5% level, while the $25 arm's 62% (z about 4.2) is. Confirming the $22 gap at 80% power would take roughly 94,000 to 104,000 visitors per arm. So the $22 LTV loss is a signal to confirm with the long holdout, not a settled result.

Kill criteria with thresholds (illustrative): stop an arm if its revenue per visitor is more than 5% below control at the planned sample size, if its refund rate is more than double the control's, or if complaints about price are more than double the control's. The extrapolation above assumes churn stays at its day 30 to 90 level; the holdout (a small cohort kept on each surviving price for six months) checks that. If actual six-month retention is well below the extrapolated value, the early churn was understating long-term loss.

Constraints

• Legal: advertised prices must be honoured, and rules on price display, differential pricing and consumer protection vary by jurisdiction, so check with legal before launch. Show the same price at every step of the checkout.
• Psychological: customers who find a lower price feel unfairly treated, which can harm trust. Price anchoring and rounding matter. Avoid showing different prices to the same person.
• Operational: billing and support must handle several live prices and refund requests.

Grandfathering and rollback

• Anyone who purchased at a test price keeps that price for a stated period, so no customer is charged more after the test than they agreed to.
• Existing subscribers are excluded from tests, and any later increase on them is a separate, announced change with a notice period.
• Pre-set kill criteria: for example, stop an arm if conversion falls by more than a stated margin against control, or if support complaints about price rise above a stated level. Control the arms with a feature flag so switching off takes minutes.
• Rollback means returning the page to the control price and honouring what test buyers already paid, with a credit if the test price was higher than the final price.

Pitfalls

Testing too short a window, peeking and stopping on a good day, ignoring currency or region differences, running several price tests at once on the same visitors, and rolling out the winner to existing customers without notice.

Direct answer

At a 10% price rise with an elasticity of about -3, the increase loses money. Price elasticity is the percentage change in buyers for a 1% change in price, so -3 means each 1% rise costs roughly 3% of volume. With the constant-elasticity form (the same percentage response to every percentage rise, rather than a straight-line 30% loss), 10% more price keeps 1.1 to the power of -3, or 0.751, of the volume (about 25% fewer buyers), so revenue lands at 1.1 x 0.751 = 0.826 of today's (-17.4% at steady state, meaning once all the price-driven losses have happened and the numbers stop changing). In the 12-month model below, with the loss arriving over three months, revenue is 15.6% lower and contribution (revenue minus the variable cost of serving each subscriber) is 13.7% lower. For a CFO who wants a defensible answer in ten minutes: do not ship -3 as a company-wide increase on this evidence. Either the -3 does not describe today's customers, or the increase is the wrong move, and a test on new customers settles which.

Assumptions (all illustrative, replace with your own data)

• Mid-tier plan priced at $50 per month, 10,000 paying subscribers, baseline monthly churn (share of subscribers who cancel each month) of 2%, 300 new subscribers per month, variable cost to serve of $10 per subscriber per month.
• The elasticity is applied as a constant-elasticity volume factor (the share of today's volume that remains: 1.0 means no change, 0.751 means 25% fewer). The linear shortcut (10% x 3 = 30% fewer buyers) overstates the loss at this size: it gives 1.1 x 0.70 = 0.77 against 0.826.
• The price-driven loss of existing subscribers arrives evenly over the first 3 months. New-subscriber volume drops by the same factor from month 1.
• Billing is monthly, so everyone pays the new price from month 1.

The 12-month model

price0, subs0 = 50.0, 10_000      # $/month list price, paying subscribers today
churn, adds, cost = 0.02, 300, 10.0   # baseline monthly churn, new subs/month, $ cost to serve per sub/month
ramp = 3                           # months over which the price-driven loss arrives

def twelve_months(elast, rise=0.10):
    vol = (1 + rise) ** elast      # constant-elasticity volume factor (1.0 = no change)
    price, subs, rev, contrib = price0 * (1 + rise), float(subs0), 0.0, 0.0
    for m in range(1, 13):
        if m <= ramp:
            subs -= subs0 * (1 - vol) / ramp        # price-driven extra losses, spread over the ramp
        rev += subs * price
        contrib += subs * (price - cost)
        subs = subs * (1 - churn) + adds * vol      # normal churn, new adds scaled by the same factor
    return rev, contrib

base_rev, base_con = twelve_months(0.0, rise=0.0)
print(f"baseline 12-month revenue ${base_rev/1e6:.2f}M, contribution ${base_con/1e6:.2f}M")
print("elasticity | volume factor | revenue vs base | contribution vs base")
for e in (-0.3, -1.0, -2.0, -3.0, -4.0, -5.0):
    r, c = twelve_months(e)
    print(f"{e:>10} | {1.1**e:>13.4f} | {100*(r/base_rev-1):>+14.1f}% | {100*(c/base_con-1):>+19.1f}%")

lo, hi = -6.0, 0.0                 # bisection: elasticity at which contribution is unchanged
for _ in range(60):
    mid = (lo + hi) / 2
    if twelve_months(mid)[1] > base_con: hi = mid
    else: lo = mid
print(f"contribution break-even elasticity: {lo:.2f}")
print(f"profit-maximising price if elasticity were truly -3 everywhere: ${cost*-3/(1-3):.2f}")

arpu, churn5, e = 30.0, 0.05, -0.3  # inelastic case
vol = 1.1 ** e
print(f"inelastic: volume factor {vol:.4f}, revenue factor {1.1*vol:.4f}")
print(f"lifetime revenue per customer ${arpu/churn5:.0f} -> ${arpu*1.1/churn5:.0f}")

Output:

baseline 12-month revenue $6.31M, contribution $5.05M
elasticity | volume factor | revenue vs base | contribution vs base
      -0.3 |        0.9718 |           +7.1% |                +9.5%
      -1.0 |        0.9091 |           +0.6% |                +2.9%
      -2.0 |        0.8264 |           -7.9% |                -5.8%
      -3.0 |        0.7513 |          -15.6% |               -13.7%
      -4.0 |        0.6830 |          -22.6% |               -20.9%
      -5.0 |        0.6209 |          -29.0% |               -27.4%
contribution break-even elasticity: -1.33
profit-maximising price if elasticity were truly -3 everywhere: $15.00
inelastic: volume factor 0.9718, revenue factor 1.0690
lifetime revenue per customer $600 -> $660

Reading the table

• Revenue breaks even at an elasticity of -1: the revenue-neutral volume factor is 1 / 1.1 = 0.909, and 1.1 to the power of -1 is exactly that. The +0.6% at -1 is timing only (losses are spread over three months while the higher price applies from month 1). In steady state it is zero.
• Contribution breaks even at about -1.33 in this model, because losing a subscriber also removes the $10 cost of serving them. The bisection loop in the code finds that number by searching for the elasticity at which 12-month contribution equals the baseline: it tries the midpoint of the range, checks whether contribution is above baseline (then the break-even lies at a more negative elasticity, so the upper end moves down to the midpoint) or below it (the lower end moves up), and halves the range 60 times. A hand check in steady state: contribution per subscriber is $50 - $10 = $40 today and $55 - $10 = $45 after the rise, so contribution is unchanged when the volume factor is 40 / 45 = 0.889, an elasticity of ln(0.889) / ln(1.1) = -1.24. The model's -1.33 is a little more negative because, during the three-month ramp inside a 12-month window, the lost subscribers are still partly paying the higher price.
• At -3 both measures are well below break-even. At -0.3 the increase is clearly worth it (+7.1% revenue, +9.5% contribution).
• Cross-check against a profit-maximising price. If demand really had a constant elasticity of -3 everywhere, a profit-maximising price is cost x e / (1 + e) = 10 x 3 / 2 = $15. Why that formula: a company picks the price that maximises (price - cost) x volume. With constant elasticity e, volume is proportional to price^e, and the maximum is where the markup over cost satisfies (p - c) / p = -1 / e. At e = -3 that is a 33% margin, so p = 10 / (1 - 1/3) = $15. A plan with an 80% gross margin ((50 - 10) / 50) is nowhere near that; an 80% margin would be the profit-maximising choice only if the elasticity were about -1.25 (-1 / e = 0.8). If customers truly had -3 at $50, the price would already be far too high and a cut would raise profit. So the -3 is probably measuring something other than the response of today's subscribers to a price rise: for example new-customer conversion, a different price range, or a period when something else changed. Saying this to the CFO is more defensible than quoting the output.

Which elasticities to estimate

Three different responses hide inside "elasticity", and they need different data:

1. New-customer conversion (visitor or trial to paid) at different list prices. Source: a randomised price test on new visitors.
2. Existing-customer retention when their price rises. Source: past price changes with a comparison group that was not raised, analysed with survival curves (the share of a cohort still subscribed by tenure) and a Cox model (a regression for time-to-cancel that compares cancellation rates between groups, with controls).
3. Mix shift: customers who move to a cheaper tier instead of leaving. This is revenue loss that churn metrics miss.

LTV and churn linkage

LTV (lifetime value) is, in its simple form, monthly ARPU (average revenue per user) x gross margin / monthly churn. Revenue per customer lifetime is proportional to ARPU / churn, so a 10% price rise keeps lifetime revenue per customer at least level only if churn rises by less than 10% in relative terms. Inelastic example: ARPU $30, churn 5%, elasticity -0.3. The volume factor is 0.9718 and the revenue factor 1.0690 (+6.9%). Lifetime revenue per customer is ARPU divided by monthly churn, because a customer stays 1 / 0.05 = 20 months on average: $30 / 0.05 = $600 today, and $33 / 0.05 = $660 after the rise if churn is unchanged, and the churn that would cancel the gain is 5% x 1.1 = 5.5%. So even in the "safe" case, 0.5 points of extra monthly churn erases the benefit.

Presenting a range, and test or roll out

Show three cases (for example -0.5, -1.5 and -3, because the response of existing subscribers may be milder than the -3 measured on a different population), not a point, and name the break-even elasticity (-1 for revenue, -1.33 here for contribution). Roll out without a test only when the whole plausible range sits on one side of break-even and the change is easy to reverse. Run a randomised test (on new customers, with existing customers grandfathered, meaning kept on their old price) when the range straddles break-even, a price cut later would damage trust, and the dollars at stake are large compared with the test's cost. Here the range straddles it (-0.5 is above the -1.33 contribution break-even, while -1.5 and -3 are below it), so test. Had every plausible case been -1.5 or more negative, the rule would say hold.

The ten-minute CFO version

Pull four things: the last two or three price changes with dates, monthly subscribers and churn by tenure for the mid-tier, new-to-paid conversion by price shown, and cost to serve. Then say: "At -3, a 10% rise cuts 12-month revenue by about $1.0M and contribution by about $0.7M on a $6.3M base. Break-even is -1.33. Our -3 looks like a new-buyer number, so the decision hinges on how existing subscribers respond. I recommend a test, sized in advance, on new visitors plus a renewal-only test on a small existing cohort before committing." Before seeing any numbers, agree the decision criteria with leadership: ship if contribution is positive across the whole plausible range, test if break-even falls inside the range, hold if it is negative across the range, and name the churn increase they would accept.

Pitfalls

• Applying an elasticity measured on new buyers to the installed base (the subscribers you already have), or one measured over small changes to a 10% jump.
• Reporting revenue only. Fewer customers can be profit-positive and revenue-negative, or the reverse.
• Ignoring the ramp: annual contracts hit churn at renewal, not in month 1.
• Forgetting competitor response and discounting by sales, which dilute the realised increase.