Test your pricing and pricing page

Kite separates a price problem from a presentation problem by looking at where buyers drop off and what they see when they do. It begins with a baseline: the share of pricing page visitors who take the next step over the last few full weeks. On a website Kite hosts, it reads that from its built-in analytics. On other websites, it uses your connected analytics account, such as Google Analytics or PostHog.

Then it reviews the live page. Kite checks whether a buyer can tell which plan is meant for them, whether each plan names the kind of customer it's built for, and whether the next step from each plan is obvious. It also looks at where your proof sits, since a testimonial or customer logo next to the button often does more than one buried further down the page. Kite also knows your competitors' pricing from its research on your market, so it can tell whether your prices are out of line with what buyers will compare them against.

Stripe adds the part analytics can't see. Kite reads your Stripe customers, subscriptions, and checkout sessions to find which plans new customers pick, how many trials turn into paid subscriptions, and where checkouts expire before payment.

Those readings often point clearly one way or the other. Suppose most of your new customers choose your cheapest plan, even though your middle plan is the one you built for them. That usually means the page isn't making the case for the middle plan, which is a presentation problem. Or suppose buyers click through to checkout on your annual plan but half of those checkouts expire unpaid. Then the price or the billing terms they meet at checkout may be the real obstacle.

Test the change with the strongest evidence behind it, and change one thing at a time. If you rewrite the headline, reorder the plans, and change the price all at once, a better result can't tell you which change earned it.

The most useful pricing page tests usually change how the page presents your plans, not the prices themselves:

• the plan descriptions, so each one names the buyer it's for
• which plan the page highlights as recommended
• whether the page opens on monthly or annual billing
• the wording on each plan's button
• a short comparison of the plans in place of a long feature grid
• answers to billing questions buyers ask, such as what happens when a trial ends
• customer proof placed beside the plans

Kite chooses among these using what it found in the diagnosis. Every test it proposes starts as one sentence that states the evidence, the change, the expected effect, the buyers it applies to, and how the result will be measured. For example: "Because most new customers choose the Starter plan even though they match the Team plan's buyer, rewriting the Team plan's description to name growing teams will increase Team plan signups from first-time visitors, measured by clicks on the Team plan's button."

When two ideas look equally promising, Kite starts with the one that's easier to build and measure. That way the testing gets started while the bigger changes are still being planned.

Kite writes the copy using what it knows about your products, customers, positioning, and brand voice. If the problem is how you describe your plans, it can also rewrite the plan descriptions for each type of buyer or rebuild the pricing page so the self-serve and talk-to-sales paths are clear.

Test a new price or plan structure with more care than a copy change, because it changes what customers pay. A copy test that loses costs you a few weeks of slightly lower clicks. A price test that loses can cost you revenue, and buyers who notice two different prices for the same plan may stop trusting either one.

Kite handles this in a few ways. It can test a price on something new, such as a new plan or a new annual option, so it doesn't change what your current customers pay. When the two versions of the page show different prices, Kite can create the new price and a payment link for it in your connected Stripe account. Each version's button then leads to its own checkout, so Kite can count completed payments for each price separately.

Some businesses don't get enough pricing page traffic to test prices against each other at all. In that case, Kite can design a short willingness-to-pay survey for your customers and prospects and use the answers to choose a price point. It can also make the change for everyone and compare the results with the period before. If the question is how you charge, such as per seat or per use, Kite can help you choose a pricing model before anything gets tested.

An A/B test shows your current pricing page to some visitors and the new version to others, then compares how many from each group take the next step. On a website Kite hosts, Kite sets up the whole test. It picks the conversion to measure from the events your site already records, such as clicks on a plan's button or completed signups. Then it builds the new version in its own draft and splits traffic between the two versions, half and half by default.

Kite shows you the test before it runs. You see the idea being tested, the conversion it measures, and how traffic will be split, and you can preview the new version. When you're ready, you start the test from your website's Experiments panel in Kite. The plan locks when the test starts, so the conversion being measured and the traffic split stay the same for the whole run, and the results always describe the test you approved.

Kite then watches the results. It tracks how many visitors saw each version, how many converted, each version's conversion rate, and the chance that each one is better. It won't recommend a winner until the test has run for at least a week, each version has been seen by at least 100 visitors, and the difference is statistically significant. If the difference is still too small to trust after three times that minimum run, Kite recommends ending the test as inconclusive and keeping your original page. That's a real answer too: it tells you that change wasn't what was holding buyers back.

If your website runs somewhere else, Kite can publish the change through a supported connection such as Webflow and measure it through your connected analytics, comparing equal periods before and after the change. If your website's code lives in GitHub, you can import the repository into Kite, which lets Kite run a true A/B test on it.

A pricing test isn't finished when one version gets more clicks. It's finished when you know whether that version brought in more revenue. A cheaper plan or a louder "Start free" button can easily win on clicks while bringing in customers who pay less or cancel sooner.

So Kite follows the result into Stripe. It checks which plans the customers who signed up during the test chose and what they pay. A month or two later, it checks again to see whether they're still subscribed. When each version of a price test has its own payment link, Kite compares completed payments for each one directly. Otherwise, it compares the plan mix and revenue from the test period with the period before.

Every test ends with a clear verdict: the new version won, it lost, or the result was inconclusive. Kite reports the baseline, the new result, how long the test ran, and anything that might have affected it, such as a launch or a campaign that changed who was visiting. If the new version won, Kite asks you to approve making it permanent, and then it merges the change. It records the test and its lesson in your team's knowledge base, so it doesn't run the same test twice and later work can build on what it learned. Then it proposes the next test.

To revisit your prices on a fixed rhythm rather than test by test, Kite can also review your pricing on a regular schedule and record the decision each time.