Most stores test everything except the one number that matters most. Button colors, hero images, headlines — all worth testing — but a 5% improvement from a price change usually goes straight to profit, because you didn't spend a cent more to earn it. So why does almost nobody test prices?
Because until recently, the tools couldn't do it properly. Here's what makes price testing different, and how to run one on WooCommerce the right way.
Why your A/B testing tool can't test prices
Classic A/B testing tools work client-side: a JavaScript snippet rewrites the page in the visitor's browser. That's fine for a headline. For a price it's a disaster waiting to happen:
- JavaScript can change the displayed price, but the store still charges the original one. A shopper who sees €39 and is charged €49 at checkout is a lost customer and possibly a legal problem.
- The price appears in a dozen places — product page, listing grids, cart, mini-cart, checkout, emails. A client-side rewrite always misses some of them.
- Price flicker (the original flashing before the swap) destroys trust exactly where trust matters most.
The only correct way is server-side: the store itself decides the visitor's price before the page renders, using the platform's own pricing system, so every surface — including the charge — agrees.
How server-side price testing works
A proper price test on WooCommerce looks like this:
- Sticky assignment. Each visitor gets a random first-party id and is deterministically assigned to a price variant (say €49 control vs €44 challenger). They keep that price on every visit — a shopper must never bounce between prices.
- Real price application. The plugin applies the assigned price through WooCommerce's own pricing filters (
woocommerce_product_get_priceand friends), so product page, cart and checkout are always consistent, and the order charges exactly what was shown. - Server-side attribution. When the order completes, it's reported against the visitor's assigned variant with the order value — no reliance on client-side scripts that ad blockers eat.
- Revenue per visitor decides. A lower price almost always converts better. The question is whether it converts better enough to overcome the smaller margin. That's why price tests must be judged on revenue per visitor, not conversion rate.
The caching trap (read this before you start)
Full-page caching is the #1 way price tests silently break. If Varnish, a WordPress cache plugin, or your CDN caches product-page HTML, one visitor's price gets served to everyone. Before starting a price test, exclude product, cart and checkout pages from full-page caching. A good plugin marks personalised pages as non-cacheable, but a hard cache in front of PHP can override that.
Running your first price test
- Pick one product with steady traffic and sales — your best seller is ideal, a long-tail product will take months to reach significance.
- Test a meaningful gap. €49 vs €47 will take forever to resolve. Try ±10–15%: €49 vs €44, or €49 vs €54. Testing a higher price is often the profitable surprise.
- Run it for at least a full week (ideally two business cycles), and don't stop the moment a winner appears — early leads are usually noise.
- Watch revenue per visitor, and treat conversion rate as a diagnostic, not the goal.
Is this even allowed?
Testing prices across anonymous visitors is a standard, widely used practice — airlines, hotels and the biggest e-commerce players do it constantly. What you should avoid is targeting prices at identified individuals or protected groups. We cover the details in Is price testing legal?
Do it in one afternoon
ProveLift ships this whole pipeline as a product: install the WooCommerce plugin, pick a product, enter your challenger prices, press start. Assignment, consistent pricing, order attribution and the revenue-per-visitor statistics are handled for you — plugins for PrestaShop and Magento included. Start free and find out what your price should have been all along.