∴ Use case · Pricing & packaging
Test the price, not just the pricing page.
Changing a pricing-page headline is not the same as changing what a customer pays. Trevo can test the server-side rules for trial length, tier limits, fees, and discounts, with every variant arriving as code your team reviews.
export function quoteOrder(order: Order) { const fee = BOOKING_FEE; // exp: waive the fee at four tickets const fee = variant === "waive-at-4" ? order.tickets >= 4 ? 0 : BOOKING_FEE : BOOKING_FEE; return subtotal + fee;
How do you A/B test pricing?
Real pricing tests change the rule that computes the price, not the page that displays it. With Trevo, a pricing experiment is a pull request against your server code: the trial length, the per-seat price, the fee threshold, or the discount rule changes behind a feature flag, assignment is consistent per visitor, and revenue per visitor is measured with always-valid sequential statistics. Because the change is code in your own repository, finance and engineering can review exactly what each variant charges before it runs, and the losing rule is removed by an automatic cleanup pull request.
How it works
From a pricing hypothesis to a decided rule change, with review at every gate.
Trevo reads where price is decided
The scan finds your pricing paths — plan definitions, quote functions, fee rules, discount thresholds — and cites them in its proposals.
The experiment is a server-side rule change
Approve a proposal and the PR changes the rule behind a flag: one variant charges the current way, the other the proposed way. No mocked UI, no display-only trickery.
Assignment is consistent, exposure is tracked
Each visitor sees one price consistently across sessions and surfaces. Exposure and conversion events are wired in the same PR.
Revenue decides, cleanup follows
Revenue per visitor with mSPRT always-valid stats. Merge the winning rule; the cleanup PR deletes the losing branch of the logic and the flag.
Packaging is testable, not just price points
The lever is rarely the number alone — it is what sits in each tier. Because Trevo edits code, it can move a feature across the paywall, change a limit, or gate a capability, and measure what that does to upgrades.
- ✓Tier limits and caps as experiments
- ✓Feature gating moves behind flags
- ✓Trial length and depth tested server-side
hypothesis the free tier gives away the habit-forming featurechange move exports behind Starter, raise free capsurface server-sidemetric upgrade_clicked → paid conversion
Safe enough for money paths
Pricing code is where teams are rightly conservative. Trevo cannot deploy anything: it writes to trevo/* branches only, your review approves every diff, and both variants are explicit in the code — auditable before a single visitor is bucketed.
- ✓Both prices visible in one reviewable diff
- ✓Your CI runs on every experiment PR
- ✓Automatic cleanup — no zombie discounts left in the code
control $175 booking fee, all party sizesvariant $0 fee at 4+ ticketsguard no change to refunds or taxesgate your approval + your CI
What this looks like in practice
Illustrative pricing proposals of the kind Trevo writes — yours are argued from your own pricing code.
Δ fees
Waive the fee at a threshold
Turn a flat fee into a threshold rule and tell the buyer what unlocks it — tested in the quote function itself.
measures → checkout_completed → revenue per order
Δ trials
Fourteen- vs twenty-one-day trial
Change the trial constant server-side and follow cohorts to paid conversion.
measures → trial_started → paid conversion
Δ plans
Annual toggle default
Default the billing toggle to annual with the discount stated, monthly one click away.
measures → plan_selected → annual mix
Frequently asked questions
Is A/B testing prices legal and fair?
Price testing is common and lawful in most jurisdictions when it is not based on protected characteristics; many teams also avoid testing on existing customers mid-subscription. Trevo gives you the controls that make a test defensible — consistent per-visitor assignment, explicit variant rules in reviewable code, and a full audit trail in git — but your counsel makes the policy call.
Can visitors see two different prices?
Assignment is consistent: a visitor keeps their variant across sessions and pages, so nobody sees the price flicker. The experiment runs server-side, which also means the competing price never ships to the client of the other arm.
What metric should a pricing test use?
Revenue per visitor is the usual primary metric, because conversion rate alone rewards the cheaper arm. Trevo wires the exposure and revenue events in the experiment PR and evaluates them with always-valid sequential statistics.
Can Trevo test the pricing page too?
Yes — page layout, plan ordering, and how the tiers are framed are ordinary frontend experiments. The point of this page is that Trevo does not stop there: the rules behind the page are testable in the same loop.
What if the losing price wins revenue but hurts activation?
Experiments track secondary metrics alongside the primary, so a revenue win that damages activation or retention is visible before you merge. The decision stays yours; Trevo supplies the evidence and the cleanup either way.
Keep reading: Onboarding & activation experiments · Trevo for growth teams · Trevo for startups · How the statistics work · Trevo vs Optimizely
Bring Trevo one real funnel problem.
Connect the repo and the first proposals arrive in under fifteen minutes, each one naming the exact files a full-stack experiment would change. Not ready? A free scan previews the ideas on your domain first.