Pricing Experiments: How to Find the Price That Maximizes Revenue
Introduction: The Highest-Leverage Variable You Are Probably Ignoring
Most growth teams have a backlog full of landing page tests, onboarding tweaks, and email subject line experiments. Pricing is rarely on that list. Teams treat price as a strategic decision made once per year in an offsite, not as an experimental variable to be continuously optimized. That is a mistake — and an expensive one.
Pricing is, by a significant margin, the highest-leverage growth variable available to most software businesses. A 1% improvement in conversion rate might lift revenue by 1%. A 1% improvement in retention does the same over the long run. But a 1% improvement in price — holding volume constant — drops directly to the bottom line. McKinsey research has consistently found that a 1% price improvement, on average, yields an 8–11% improvement in operating profit for the typical S&P 500 company.
Yet most SaaS teams have never run a single pricing experiment. They picked a number, maybe compared it to one or two competitors, and left it alone. Meanwhile, they are running their twelfth test on the color of a CTA button.
This guide covers how to run pricing experiments correctly: legally, ethically, without angering your existing customers, and with measurement frameworks sophisticated enough to capture actual revenue impact rather than surface-level conversion rates.
The Ethics and Legality of Pricing Experiments
The most common objection to pricing experiments is that they feel unfair. If two people visit your pricing page on the same day and see different prices, is that deceptive? The short answer is: it depends entirely on how you design the experiment.
Geographic Segmentation
The most legally unambiguous form of pricing experimentation is geographic segmentation. Different prices in different countries or regions are standard commercial practice. Airlines, software companies, and consumer goods manufacturers all do this. There is no deception involved because the user sees one price — the price for their region — and that price is accurate.
Geographic pricing experiments can reveal substantial willingness-to-pay differences. A $49/month price that converts poorly in price-sensitive markets may convert identically to $29/month in those markets while remaining at $49 in markets where it performs well, increasing blended revenue without any deception.
New-User-Only Testing
The cleaner ethical approach for same-market experiments is to test prices only on new visitors who have never seen your pricing page before. This avoids the scenario where a returning user sees a price that has changed since their last visit. Technically, this requires using your experiment platform to bucket users on first visit and persist that assignment.
New-user-only testing is the standard approach used by companies like Basecamp, Notion, and most mature SaaS businesses when they run price point experiments. It is commercially reasonable: you are not changing the price for existing customers, and you are not showing the same user different prices on different visits.
Disclosure and Fairness
The line into legally and ethically problematic territory is personalized pricing based on inferred ability to pay (for example, charging Mac users more than Windows users, as Amazon famously experimented with in the early 2000s), or showing different prices to the same user on different page loads without a clear rationale.
Stick to the safe pattern: segment by geography, new vs. returning, acquisition channel, or plan tier. Make the price shown accurate for that segment. Do not use personal characteristics unrelated to the product to set price. If you are running a test, the price shown to any given user is consistent across their session.
Price Point Experiments: Testing $29 vs $39 vs $49
The most fundamental pricing experiment is simple: show different price points to different visitor cohorts and measure which one maximizes revenue per visitor (not just conversion rate — more on that distinction shortly).
Understanding Price Elasticity
Price elasticity measures how sensitive demand is to price changes. Elastic demand means a small price increase causes a large drop in volume. Inelastic demand means volume holds relatively stable across a range of prices. Most software businesses are more inelastic than their teams assume, particularly when the product addresses a painful, high-stakes problem.
A product that converts at 4% at $29/month and 3.2% at $39/month is not “losing” customers by raising the price — it is generating 8% more revenue per visitor. The 0.8 percentage point drop in conversion rate is worth taking.
How to Structure a Price Point Test
A price point test typically requires three things:
- A clean variant assignment. Use your experiment platform to assign visitors to price variants at first visit. Store the assignment so the same visitor always sees the same price.
- Sufficient sample size. Price tests require more traffic than headline tests because the conversion event (purchase) is rarer. Use a power calculator: for a 4% baseline conversion rate, detecting a 20% relative lift with 80% power requires roughly 6,000 visitors per variant.
- Revenue per visitor as your primary metric. Not conversion rate. Revenue per visitor = conversion rate × average contract value. A variant that lowers conversion by 10% but raises price by 40% wins on the metric that matters.
What Price Points to Test
Test a range wide enough to reveal meaningful elasticity. If your current price is $29, test $29, $39, and $49 simultaneously. Avoid testing more than three or four variants at once — each additional variant increases the traffic required to reach significance. If you find the curve is flat up to $49, run a second experiment with $49, $59, and $69.
Pricing Page Layout Experiments
The way a price is presented often matters as much as the price itself. Pricing page layout is one of the highest-ROI experiment categories in SaaS because it does not require any change to the actual price charged.
Feature Comparison Tables
A feature comparison table (starter / pro / enterprise columns with checkmarks) is the dominant pricing page format for a reason: it communicates relative value quickly. But the exact features shown, the labels used, and which plan is highlighted as the recommended choice all have measurable impact on which plan visitors select.
Experiments to run:
- Which plan is highlighted as “Most Popular” or “Recommended.” Moving the highlight from the middle tier to the higher tier can shift plan mix significantly without reducing overall conversion.
- Feature row ordering. Features valued most by buyers should be near the top. Testing reordering reveals which benefits actually drive plan selection.
- Table vs. card layout. Some audiences respond better to side-by-side comparison; others prefer a card-per-plan format with less visual complexity.
Annual vs. Monthly Toggle Placement
Most SaaS pricing pages offer both monthly and annual billing. The default state of the toggle — which option is selected when the page loads — has an outsized effect on plan mix. Defaulting to annual display typically increases the share of annual subscriptions without meaningfully reducing conversion, because annual plans represent better LTV and lower churn.
Test variants: default monthly, default annual, no toggle (annual only), and toggle with a prominent “Save 20%” badge on the annual option.
Anchoring and Decoy Pricing Experiments
Behavioral economics offers a set of well-validated pricing structures that exploit cognitive anchoring — the tendency of humans to evaluate options relative to the first number they see, not in absolute terms.
Three-Tier Pricing and the Compromise Effect
When presented with three options, the majority of buyers select the middle option regardless of absolute price. This is the compromise effect: the middle choice feels safe because it avoids both the risk of the cheapest option (is it good enough?) and the expense of the most expensive. Knowing this, you can design your tier structure so the middle option is the one you most want customers to buy.
Experiments worth running:
- Price gap between middle and top tier. A large gap (e.g., $49 vs. $199) makes the middle tier look like extreme value. A smaller gap (e.g., $49 vs. $79) encourages upgrades to the top tier. Test both.
- Which features are in each tier. Moving one high-demand feature from the top tier to the middle tier can dramatically shift volume to the middle plan.
Phantom Tiers and Decoy Plans
A phantom tier (sometimes called a decoy) is a pricing option designed not to be purchased but to make another option look more attractive by comparison. A classic pattern: add an expensive “Enterprise” tier with a price that is dramatically higher than your target plan. The target plan now looks like a bargain.
Dan Ariely’s research on The Economist subscriptions found that adding a print-only option (priced identically to the print+digital bundle) increased print+digital subscription rates from 32% to 84%. The decoy made the bundle look like an obvious choice.
Test whether adding a visible enterprise-tier price on your pricing page (even without a buy button, just a “Contact us” link) shifts plan distribution toward your higher self-serve tier.
Free Trial Length Experiments
Trial length is one of the most consequential and most under-tested variables in SaaS go-to-market. The intuition — that a longer trial means higher conversion because users have more time to experience value — is often wrong.
Why Shorter Trials Sometimes Convert Better
Urgency drives action. A 7-day trial creates a clear deadline that motivates users to engage immediately. A 30-day trial often results in users deferring engagement until “later in the trial,” then churning without ever experiencing the product’s core value. If your product’s time-to-value is less than a week (and it should be — if it is not, that is a product problem to fix first), a shorter trial can increase conversion by concentrating urgency.
What to Measure in a Trial Length Experiment
Do not measure trial-to-paid conversion rate in isolation. A 14-day trial will, by definition, convert to paid sooner than a 30-day trial in calendar time — but if the 30-day variant ultimately produces the same number of paying customers (just later), the apparent short-term advantage of the 14-day trial is an artifact of measurement timing, not a real signal.
Measure:
- Activation rate during trial — did users complete the key actions that predict retention?
- Conversion to paid at 90 days post-signup — allowing enough time for the longer trial variants to fully play out.
- 12-month retention of converted customers — do customers acquired through shorter trials churn faster?
The winning trial length maximizes the product of conversion rate and long-term retention, not just the near-term conversion number.
Freemium Limit Experiments
For products with a freemium tier, the position of usage limits is a continuous optimization problem. Set limits too low and users hit the wall before experiencing enough value to want to pay. Set limits too high and users never feel enough friction to upgrade.
What Features to Gate
The most effective gates are on features that users have already used and found valuable — not on features they have not yet discovered. Gating a feature before users understand its value teaches users to work around the limitation rather than upgrading past it.
The upgrade-inducing pattern: let users fully experience a feature, then limit it after they are reliant on it. A user who has used collaboration features with their team for two weeks will upgrade to unlock unlimited collaborators. A user who has never invited a teammate will not.
Limit Experiments to Run
- Project or workspace count — 3 vs. 5 vs. unlimited free projects
- Seat count — 1 free user vs. 3 free users vs. unlimited free with usage cap
- Feature depth — basic vs. advanced reporting, data export on/off, integrations on/off
- History or data retention — 30 days vs. 90 days of data on free tier
For each variant, measure upgrade rate, time-to-upgrade, and post-upgrade retention. The goal is to find limits that create natural, non-frustrating upgrade moments: the user wants to do more, hits a clear limit, and upgrading feels like the obvious next step.
Annual vs. Monthly Discount Experiments
Offering an annual plan at a discount improves cash flow (12 months upfront), reduces payment failure churn, and typically reduces voluntary churn because the annual commitment changes the user’s psychological relationship with the product. But the discount percentage that maximizes LTV is not obvious.
The Discount Tradeoff
A deeper discount increases the share of customers who choose annual billing, but at the cost of lower revenue per annual customer. A 40% annual discount might convert 60% of customers to annual plans; a 20% discount might only convert 30%. The question is which scenario generates more total 12-month revenue from the cohort.
The optimal annual discount is not the highest conversion rate — it is the discount percentage that maximizes revenue per acquired customer over a 12-month horizon, accounting for the churn reduction benefit of annual plans.
How to Run the Experiment
Test annual discount variants on your pricing page (e.g., “Save 17%” vs. “Save 25%” vs. “Save 33%”). Track plan mix (monthly vs. annual selection), overall conversion to paid, and 3-month and 6-month retention for each cohort. Because annual plan revenue is received upfront, the revenue-per-visitor signal is visible within weeks. Retention differences take longer to accumulate but matter significantly for LTV calculations.
Packaging Experiments: Feature Bundling and Add-Ons
Price point and trial length experiments assume a fixed product definition and vary only the price or terms. Packaging experiments vary what is included, which can have equal or greater revenue impact.
Feature Bundling vs. Unbundling
The dominant SaaS pattern is to bundle features into tiers (Starter / Pro / Enterprise). But for products with a diverse user base whose needs vary significantly, unbundling — letting users build their own plan from a menu of add-ons — can increase average revenue per user by letting power users pay for exactly what they value without subsidizing features they do not use.
The tradeoff: bundled plans are simpler to explain and often convert better for less sophisticated buyers. Unbundled add-on pricing captures more value from sophisticated buyers who know exactly what they need. Test both models if your user base is heterogeneous enough to warrant it.
Seats vs. Usage Pricing
Per-seat pricing is simple, predictable, and easy for buyers to understand. Usage-based pricing (per API call, per event, per GB) aligns price with value delivered but introduces uncertainty that some buyers dislike. Hybrid models — a flat platform fee plus usage for high-volume features — often capture the benefits of both.
If you currently use per-seat pricing, experiment with a usage-based tier for your highest-volume customers. Measure whether this unlocks deals that were previously blocked by seat-based pricing and whether usage-based customers show higher or lower churn than seat-based customers at comparable revenue levels.
Add-On Pricing Experiments
Packaging certain features as paid add-ons (rather than including them in a tier) is a high-impact experiment for products with features that have strong but segment-specific value. Examples: advanced analytics as a $15/month add-on, SSO as an enterprise add-on, priority support as an add-on to all tiers.
Test whether making a feature an explicit add-on — with clear pricing and a dedicated upgrade moment — generates more revenue than burying it in a higher tier that not all users need.
Measuring Pricing Experiments Correctly
The single most common mistake in pricing experiments is using conversion rate as the primary success metric. Conversion rate measures the percentage of visitors who start paying, but it says nothing about how much they pay or how long they stay. A pricing variant that reduces conversion by 15% but increases average contract value by 30% is a clear win by any measure that matters — but it looks like a loss if you are only watching conversion rate.
The Right Metrics for Pricing Experiments
- Revenue per visitor — the product of conversion rate and average contract value. This is your primary short-term signal. It captures both dimensions of the tradeoff.
- Revenue per acquired customer at 12 months (LTV proxy) — accounts for churn differences between price variants. A lower-priced plan that retains better may outperform a higher-priced plan with higher churn over a 12-month horizon.
- Payback period — how many months of revenue are required to recover customer acquisition cost. Higher prices shorten payback period, which affects how aggressively you can invest in growth.
- Plan mix — for multi-tier tests, which plan each variant cohort selects. This reveals whether pricing changes are shifting buyers toward higher or lower plans, not just changing overall conversion.
Watch for Segment-Level Effects
Aggregate metrics can hide important segment-level differences. A price increase might lift revenue per visitor for small-team buyers while significantly reducing conversion among enterprise buyers (who have procurement processes sensitive to price thresholds). Slice your experiment results by company size, acquisition channel, and job function before declaring a winner.
How Long to Run Pricing Experiments
Price experiments need longer run times than most A/B tests. Three reasons:
- Purchase conversion rates are lower than click or engagement rates, requiring more time to accumulate statistical power.
- Seasonality affects purchasing behavior. A test run only on Mondays and Tuesdays may not generalize.
- LTV differences between variants are not visible for weeks or months after acquisition.
Run price point tests for a minimum of two full business weeks before reading results, and ideally four weeks. Do not stop tests early because one variant is “winning” on a small sample — this is the most common source of false positives in pricing experiments.
How to Run Pricing Experiments Without Angering Existing Customers
The fastest way to create customer backlash is to show existing customers that they paid more (or less) than a neighbor. This section covers the practices that prevent that outcome.
Grandfathering and Price Lock Commitments
Before running any price point experiment that might result in a price increase, decide your grandfathering policy: will existing customers stay at their current price if you raise prices for new customers? Communicating this commitment proactively — “your price is locked as long as you remain a customer” — prevents backlash and can actually increase retention by creating a tangible benefit to staying.
Limit Visible Variants to New Visitors
Configure your experiment to activate only for first-time visitors or users who have not yet entered a trial or paid state. This ensures no existing customer ever sees a pricing page with a different price than they paid. It also keeps your experiment population homogeneous — prospects, not existing customers with established price expectations.
Avoid Visible Price Inconsistency
If your pricing page is publicly visible and indexed by Google, two visitors on the same day can compare notes. This is manageable for geographic segmentation (different prices are expected) but riskier for same-market price point tests. Practical mitigations:
- Do not show the test price in the page title or meta description that search engines index.
- Use JavaScript to render the price after page load (so crawlers see a neutral state).
- Run same-market price tests for a limited window (four to six weeks) rather than indefinitely.
Communicate Changes Transparently
When you implement a permanent price change after a successful experiment, announce it to your user base with appropriate lead time. Give existing free users or trialists a window to convert at the current price. This converts the price change from a potential complaint into a marketing opportunity: urgency drives conversions, and users who feel they received fair warning are far less likely to be publicly critical.
Running Pricing Experiments With ExperimentFlow
ExperimentFlow handles multi-variant pricing experiments with the same infrastructure you use for any other experiment — no separate tool required. The key is to assign visitors to a pricing variant at first visit, persist the assignment, and render the correct price based on the variant returned by the API.
Setting Up a Price Point Experiment
Create a three-variant experiment in ExperimentFlow with variants for each price point you want to test. Name them clearly so your results are easy to interpret:
// Create the experiment (one time, via dashboard or API)
// Variants: "control" ($29), "mid" ($39), "high" ($49)
// On your pricing page, call /api/decide at first load:
const response = await fetch("https://experimentflow.com/api/decide", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer YOUR_API_KEY"
},
body: JSON.stringify({
experiment_id: "pricing-price-point-test",
visitor_id: getOrCreateVisitorId() // stable per-device ID
})
});
const { variant } = await response.json();
const prices = {
control: { monthly: 29, annual: 23 },
mid: { monthly: 39, annual: 31 },
high: { monthly: 49, annual: 39 }
};
renderPricingPage(prices[variant] || prices.control);
Tracking Conversions to Revenue
When a visitor upgrades, pass the variant and the revenue value to ExperimentFlow’s conversion tracking. This lets you compare revenue per visitor across variants directly in the dashboard:
// On successful checkout completion:
await fetch("https://experimentflow.com/api/convert", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer YOUR_API_KEY"
},
body: JSON.stringify({
experiment_id: "pricing-price-point-test",
visitor_id: getOrCreateVisitorId(),
value: planPrice // the actual monthly price the customer paid
})
});
With revenue values attached to conversions, ExperimentFlow calculates revenue per visitor for each variant automatically. You can see at a glance not just which variant converted more users, but which variant generated more dollars per visitor — the number that actually determines whether the experiment was a success.
Running Multiple Pricing Experiments Concurrently
Use ExperimentFlow’s batch decide API to handle multiple concurrent pricing experiments without multiple round trips. For example, if you are simultaneously testing price point, annual discount percentage, and CTA copy on your pricing page:
const response = await fetch("https://experimentflow.com/api/decide/batch", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer YOUR_API_KEY"
},
body: JSON.stringify({
visitor_id: getOrCreateVisitorId(),
experiments: [
"pricing-price-point-test",
"pricing-annual-discount-test",
"pricing-cta-copy-test"
]
})
});
const variants = await response.json();
// { "pricing-price-point-test": "high", "pricing-annual-discount-test": "25pct", ... }
renderPricingPage({
price: priceForVariant(variants["pricing-price-point-test"]),
annualDiscount: discountForVariant(variants["pricing-annual-discount-test"]),
ctaText: ctaForVariant(variants["pricing-cta-copy-test"])
});
This keeps all experiments isolated from one another in analysis while delivering a consistent, coherent pricing page to each visitor in a single request. Learn more about running multi-armed bandits vs A/B tests if you want ExperimentFlow to automatically shift traffic toward the best-performing pricing variant as data accumulates.
Conclusion: Make Pricing a Continuous Optimization
Pricing is not a one-time decision. It is a continuous experiment. The market changes, your product evolves, your customer mix shifts, and the price that was optimal at your last offsite may no longer be optimal today. Teams that treat pricing as an experimental variable — systematically testing price points, packaging, trial structure, and page layout — compound their revenue advantage over time in a way that no CTA color test ever will.
The practical starting point is simple: pick your most important pricing variable (usually the price point itself), set up a clean three-variant experiment, run it for four weeks, and measure revenue per visitor. The result will almost certainly surprise you — either because your price is lower than it needs to be, or because you find a configuration of packaging and trial structure that converts better than your current setup at the same price.
Either outcome is a win. The only losing move is not to test at all.
Ready to start your first pricing experiment? Get started free with ExperimentFlow and have your first experiment running in minutes.
Ready to optimize your site?
Start running experiments in minutes with Experiment Flow. Plans from $29/month.
Get Started