You have a pricing page, a few thousand visitors a month at best, and someone on the team wants to "test the price." Before you change a single number, open a sample-size calculator and type in your current visitor-to-trial rate. That five-minute check tells you whether a pricing A/B test is possible at all, and it decides almost everything else in this post.
If the answer is yes, the rest is about choosing what to measure, how long to wait, and which tool to run it in.
What Does a SaaS Pricing Page A/B Test Actually Measure?
A pricing page A/B test should measure revenue per visitor over a full billing cycle, because a variant that lifts signups can still lose money if it attracts customers who pay less or leave sooner.
Consider a hypothetical team whose new variant raises trial signups but fills the funnel with smaller accounts. On the signup dashboard it looks like a win. In the revenue data one billing cycle later it may be a loss. That scenario is an illustration, not a result I measured, but it shows why signup rate is only the first link in a chain: signup, trial start, paid conversion, retained revenue. Stop the measurement at the first link and you are optimizing a proxy.
In practice, pick one primary metric (revenue per visitor or paid conversions per visitor) and two guardrails, such as refund rate and first-cycle churn. Then keep observing the cohort for one full billing cycle after the test window closes. For monthly billing that means about 30 extra days before you call the result. The B2B SaaS glossary entry explains why longer sales cycles stretch this further.
Which variables are worth testing?
Structural changes are worth the traffic; cosmetic ones rarely are. The table lists the usual candidates, what to measure for each, and the trap that comes with it. These are hypotheses to test. I'm not quoting lift percentages because I could not find a primary source that supports a universal figure for any of them.
| Variable | What you change | Primary metric | Trap |
|---|---|---|---|
| Tier count | Two plans versus three | Revenue per visitor | A third plan that nobody buys still changes what people pick |
| Billing default | Annual or monthly shown first | Annual plan take rate, then first-cycle churn | Annual buyers may differ from monthly buyers, so compare cohorts |
| Anchor position | Highest-priced plan leftmost or rightmost | Average revenue per account | A narrow price spread gives the anchor little to work with |
| Feature gate visibility | How quickly a visitor finds the cheapest plan with their feature | Trial-to-paid rate by plan | Long comparison tables hide the answer below the fold |
| Social proof placement | Logos and quotes above or below the tier cards | Trial start rate | Only test proof you can back with real customers |
The reasoning behind each is plain. A third tier gives visitors a reference point, which is the decoy effect from behavioral pricing research. An annual default shows the lower per-month number first. A leftmost premium plan sets what "normal" costs before anyone reads the cheaper ones. A comparison table that answers "which plan has my feature?" in a few seconds removes a reason to leave. Proof above the cards frames the question as "which plan?" instead of "should I sign up?". All five are mechanisms I'd test, not mechanisms I'd promise.
How Long Should a Pricing Page A/B Test Run?
Run it until you reach the sample size you calculated before launch, and then through one billing cycle of follow-up, because stopping the first time the dashboard shows significance inflates false positives.
The size of the inflation is larger than most people expect. In Evan Miller's 2010 analysis of repeated significance testing, checking for significance after every observation pushes the real false positive rate to 26.1% instead of the 5% you think you are running. His advice is to decide the sample size in advance and wait until the experiment is over.
Sample size is the constraint that bites. Evan Miller's sample size calculator shows a worked example: detecting a move from a 10.2% to a 13.2% conversion rate takes 2,545 visitors per variation. Apply that arithmetic to a page with 1,000 visitors a month and two variants: you need about 5,090 visitors, which is roughly five months of traffic for a three-point lift. A smaller expected lift needs far more. That is my calculation from his example, not a benchmark, so run your own numbers.
Returning visitors add a second problem. A pricing page is often opened several times before someone buys, and Spotify's 2023 write-up on the peeking problem with longitudinal data describes how sequential tests that treat each user's measurement as final can inflate false positives when a unit is measured repeatedly. This suggests that a short window is risky for pricing pages specifically, though the article does not study pricing pages.
Here is a procedure that holds up at small scale:
- Write the hypothesis, the primary metric and two guardrails before any traffic is split.
- Calculate the sample size per variant from your real baseline rate and the smallest lift worth shipping.
- Create one feature flag, for example `pricing_annual_first`, and assign visitors randomly at page load.
- Change one thing at a time. Two concurrent pricing experiments on the same page make causation invisible.
- Do not read the result until the planned sample size is reached.
- Keep watching revenue and churn for one billing cycle, then decide.
How do you read the result once the sample is in?
Compute revenue per visitor for each variant as paid conversions multiplied by average first-cycle revenue, divided by visitors. Then check that neither guardrail moved the wrong way. If the variant wins on revenue per visitor but first-cycle churn or refunds rose, you have found a trade-off rather than a winner, and the decision belongs to you, not to the p-value. Segment by plan and by traffic source before you ship, because one large channel can hide a loss in another. Write down the result and the decision either way. A record of tests that found nothing saves the next person from repeating them.
PostHog or GrowthBook for Pricing Experiments?
PostHog fits small teams that want flags and experiments in the product analytics tool they may already use; GrowthBook fits teams that want sequential testing and variance reduction and will pay per seat for it.
| PostHog | GrowthBook | |
|---|---|---|
| Free allowance | 1M feature flag requests a month; experiments are billed with flags | Starter plan at $0, up to 3 users |
| Paid entry | Usage-based after the free allowance | Pro at $40 per seat per month, up to 30 users |
| Sequential testing | Not covered by the pages I checked | Pro and Enterprise plans, using Asymptotic Confidence Sequences |
| Statistics | Bayesian or frequentist | Sequential, CUPED on Pro and up |
One detail on GrowthBook is easy to misread. Its docs describe 5,000 as the default value of a tuning parameter for sequential tests and advise setting it to the sample size you expect when you are most likely to decide. It is not a minimum traffic requirement, so don't use it as one. Prices and plan limits change, so check both pricing pages (last checked on 2026-09-30) before you commit.
For a bootstrapped team with no data scientist, start with whichever tool your events already flow into. The habits in the procedure above matter more than the tool.
What If You Don't Have the Traffic?
If you can't reach the sample size in a few months, skip the A/B test and learn from conversations, exit surveys and direct comparison of cohorts, because a test that never finishes only produces noise.
Two projects from my case studies sit at different points on this. According to its case study, BookBed has Stripe in live mode with a trial lifecycle and a single price of €9 per month for up to twenty units, but paid traffic isn't switched on yet. There is nothing to split-test, and the useful question is why a person would pay. The Callidus case study lists a £15 per month Starter plan, a £50 per month Aesthetics plan, a £25 per month seat add-on and a 14-day free trial. The case study reports 14 onboarded tenants across active, trialing and suspended states. A base that size is too small for a statistically meaningful pricing test, which is my inference and not a finding from the case study.
Qualitative work has a procedure too. I'd talk to five to ten people who reached the pricing page and did not start a trial, ask what they expected to pay and what they compared you with, and write down the answers in their own words. Add a one-question exit survey on the page, such as "What stopped you from choosing a plan today?", and tally the answers weekly. A pattern that repeats across conversations gives you a hypothesis worth a future test. A single vivid comment does not.
When volume does arrive, test the billing default first. It is quick to build, easy to reverse, and the cohort comparison is straightforward. The app cost estimator helps you work out the price floor you need to sustain the product, and the SaaS MVP stack guide covers what sits beneath each tier. For the activation side of the funnel, see the post on product analytics and activation metrics, and for trial design see free trial versus freemium billing.
What is the smallest lift you would act on, and how many visitors does your pricing page get in a month? Put both numbers into the calculator today, and the answer will tell you whether your next pricing move is an experiment or a conversation.