Pricing Experiments Catalog: 12 Rapid A/B Tests to Validate Billing Units in 30 Days
Written by AppWispr editorial
Return to blogPRICING EXPERIMENTS CATALOG: 12 RAPID A/B TESTS TO VALIDATE BILLING UNITS IN 30 DAYS
If you’re building a product-led SaaS or an app with paid microfeatures, pricing unit decisions (per-user, per-seat, credits, per-output) change ARPU and UX in ways you can’t predict. This catalog gives 12 experiment templates you can implement in 30 days: each includes a concise hypothesis, traffic & sample-size guidance, primary metric(s), implementation notes, rollback rules, and a one-line ARPU mapping so you can turn results into revenue projections.
Section 1
How to read this catalog and convert results into ARPU lift
Before running tests, define baseline ARPU and the cohort you’ll measure (new signups, trialers who reach paywall, or existing customers). Use revenue-per-user over a fixed window (first 30 days or first billing cycle) as your primary conversion-to-ARPU mapping — it’s direct and easy to compute. Measure both conversion rate and revenue-per-converted-user so you can calculate ARPU change = conversion_rate * avg_revenue_per_payer.
Pick conservative minimum detectable effects (e.g., 5–10% relative lift in conversion or ARPU) and use a sample-size calculator (your A/B tool or common calculators) to avoid underpowered tests. If traffic is limited, run sequential pilots on segmented cohorts rather than full randomized A/B tests to reduce risk and time to learning. Keep tests isolated to new customers or a clearly segmented subset to avoid cross-cohort billing confusion.
- Primary ARPU formula: ARPU = (converters / cohort) * average revenue per payer.
- Run tests on new-user paywall or clearly scoped segments (avoid global existing-customer price shocks).
- Require traffic or sample-size calculation: low traffic -> pilot segmented tests rather than full randomized A/B.
Sources used in this section
Section 2
Catalog: 12 rapid experiments (structure: hypothesis, sample, metric, implementation, rollback, ARPU mapping)
The next 12 templates are grouped into three families: Billing unit swaps (per-seat, per-user, per-output, per-project), Add-on & microfeature tests (one-time, token packs, feature unlocks), and Packaging & framing (annual prepay, contrast pricing, free-trial duration). Each template is compact so you can ship in a sprint with conservative guardrails.
For every template: run duration 14–30 days, primary cohort = new paying-eligible signups (or trial converters), and capture: conversions to paid, revenue per payer, churn in first 30 days (if measurable). Use feature flags or your experimentation system tied to billing (RevenueCat/Lago/your billing provider) to keep revenue telemetry accurate and reversible.
- Duration: 14–30 days depending on conversion cadence.
- Primary telemetry: conversion rate, revenue/payer, 30-day retention, support volume.
- Implementation must route charges through the billing system to measure true ARPU — not just front-end clicks.
Section 3
Billing-unit swap experiments (4 templates)
1) Per-seat vs per-active-user. Hypothesis: switching to per-active-user reduces sticker shock and increases conversion among small teams. Sample: randomize new signups into two variants, each with n determined from expected baseline conversion and 7–10% MDE. Metric: conversion rate and revenue/payer over 30 days. Implementation: show variant pricing on paywall and route billing to same plan ID logic but compute invoices based on reported active users. Rollback: restore control and refund any misbilled invoices within 48 hours.
2) Per-output (credits) vs flat plan. Hypothesis: charging per-output (credits) aligns payment to value and increases conversion for low-frequency users while increasing ARPU for heavy users. Implementation needs ledger-backed credit balances and per-charge events; run on new users only. ARPU mapping: compute ARPU change by modeling average credits consumed per cohort times credit price.
- Key guardrail: keep tests limited to new users to avoid retroactive billing problems.
- Billing changes must be reversible and tested on staging with synthetic invoices first.
- Sample-size calculators are required when splitting near checkout.
Section 4
Add-on & microfeature experiments (4 templates)
3) Microcheckout (one‑click microfeature). Hypothesis: offering a one-time microfeature purchase at the first high-value moment yields measurable paid adoption and predictable ARPU lift. Sample: show the microcheckout to 50% of qualifying users who reach the key moment. Metric: microfeature conversion rate, revenue per microfeature purchaser, and downstream retention. Implementation: simple 1-click checkout integrated with billing; if using token packs, deliver tokens to user ledger.
4) Token packs and bundles. Hypothesis: selling token packs (3/10/30) with a rollover increases ARPU and average spend-per-buyer. Implementation: offer token pack variants and measure purchases and average tokens consumed. Rollback: pause new purchases and honor already delivered tokens or refund unused portion per your policy.
- Expected decision rule: ship if first-month ARPU from buyers covers incremental build cost within 6–12 months (use your unit economics).
- Use a refundable small-dollar pilot if legal or tax complexity is uncertain.
- Track support volume: sudden spikes indicate UX or expectation mismatch.
Section 5
Packaging & framing experiments (4 templates)
5) Annual prepay framing (compare monthly vs annual anchor). Hypothesis: adding an explicit annual savings anchor increases ARR per signup even if conversion rate shifts slightly. Sample: new signups on paywall, variants with and without annual price framed as X/month billed annually. Metric: percent choosing annual, ARPU (first 12 months projected), cash flow uplift. Implementation: show different price cards; ensure order creation uses the correct billing cadence.
6) Feature gating vs feature trial. Hypothesis: gating a key microfeature behind a paywall but offering a short time-limited trial will increase paid conversion and ARPU among engaged users. Implementation: grant a 3–7 day trial on paywall to the test cohort only and measure conversion-to-paid post-trial.
- Always compute projected 12-month ARPU for annual tests to compare short-term conversion vs long-term revenue.
- Frame savings with absolute numbers (you save $X/year) rather than percentages to reduce cognitive friction.
- Monitor cancellation requests and billing disputes closely in the first 7 days after rollout.
Sources used in this section
FAQ
Common follow-up questions
How large a sample do I need for pricing A/B tests?
Sample size depends on baseline conversion, desired minimum detectable effect (MDE), and acceptable statistical power. Use an A/B sample-size calculator (or your experimentation platform) and aim for at least 80% power and a conservative MDE (5–10% relative lift). If traffic is low, run segmented pilots on targeted cohorts rather than full randomized experiments.
Can I test pricing on existing customers?
Avoid broad pricing tests on existing customers to prevent churn and billing confusion. Prefer targeted pilots (opt-in, feature experiments, or staged rollouts) with clear consent and a rollback policy. For high-touch customers, coordinate with sales and customer success rather than using blunt A/B splits.
How do I map experiment results to projected ARPU lift?
Compute ARPU change as: delta_ARPU = (conversion_rate_variant - conversion_rate_control) * avg_revenue_per_payer_variant + conversion_rate_control * (avg_revenue_per_payer_variant - avg_revenue_per_payer_control). For annual offers, project first-year revenue to compare tradeoffs between immediate cash and long-term retention.
What tooling do I need to run these tests without breaking billing?
Use feature flags and an experimentation platform that can integrate with your billing system (RevenueCat, Lago, or your own ledger). Ensure the experiment routes true invoice events through billing so revenue signals are accurate, and perform all billing logic tests in staging first.
Sources
Research used in this article
Each generated article keeps its own linked source list so the underlying reporting is visible and easy to verify.
Stripe
Pricing experiments: A guide for businesses
https://stripe.com/resources/more/pricing-experiments
Lago
How to Run Pricing Experiments Without Breaking Your Billing System
https://getlago.com/blog/pricing-experiments
RevenueCat
Getting Started with Experiments
https://www.revenuecat.com/docs/tools/experiments-v1/experiments-overview-v1
AppWispr
Feature Unbundling Playbook — 5 Experiments to Monetize Microfeatures
https://www.appwispr.com/blog/the-feature-unbundling-playbook-5-experiments-to-split-a-product-into-monetizable-microfeatures
AppWispr
Pricing Page Experiments for Apps: A 6‑Week Test Plan
https://www.appwispr.com/blog/pricing-page-experiments-for-apps-a-6-week-test-plan-that-beats-guesswork
Referenced source
Price Experimentation and Interference (arXiv)
https://arxiv.org/abs/2310.17165
Next step
Turn the idea into a build-ready plan.
AppWispr takes the research and packages it into a product brief, mockups, screenshots, and launch copy you can use right away.