Experimentation
Testing comes after the basics are trustworthy. We use experiments when traffic, risk and measurement make a test more useful than simply fixing the obvious friction.
Read our five-star reviews on Trustpilot
A/B testing only works when a page has enough traffic to reach a decision in a sensible window, and most WooCommerce stores don't have that for every change. So we test where experimentation can genuinely settle uncertainty, fix what's clearly broken directly, and read every result in revenue per visitor rather than a button-click. The result is fewer wasted weeks, fewer false "wins", and decisions you can defend.
A controlled experiment is only trustworthy if exposure, conversion and revenue are measured correctly, so we validate the GA4 ecommerce model (view_item, add_to_cart, begin_checkout, purchase, with transaction_id, value, currency and a proper items array) and, for heavyweight clients, the BigQuery export, before any test ships.
We decide whether a change is a true uncertainty worth randomising or an obvious defect to fix. We don't spend weeks randomising a bug.
Built from GA4 pathing, device splits, search queries, support tickets and session replay, and scored with a simple framework such as ICE or PIE.
Simple designs preserve power; multivariate is reserved for genuinely high-traffic pages because it splits traffic across combinations.
Client-side for copy and layout, server-side or feature-flag patterns for payment, shipping, pricing or checkout logic, with no flicker and no brittle DOM dependencies on business-critical paths.
When classic A/B is too slow, testing higher-traffic pages or micro-conversions, bundling a coherent package of changes (and saying so), and leaning on usability testing, replay, surveys and established best practice.
(caching, CDN, deferred scripts, consent) to make sure assignment and tracking are sound before we read anything.
Decide in the platform, then confirm the result holds in revenue per visitor and the guardrails in the GA4 surface you actually trust.
We choose one primary metric that represents business value, revenue per visitor or revenue per session on the tested journey, plus guardrails like error and payment-failure rate, basket value and exposure health, so a win in one place can't quietly damage another. Before a test starts we fix five things in writing: the primary metric, the guardrails, the baseline conversion rate, the minimum detectable effect we'd actually act on, and the decision rule (typically 95% significance and 80% power). We respect the weekly business cycle, running for at least seven days and often two full weeks, because small effects are expensive to detect: as a rule of thumb, halving the effect you want to find roughly quadruples the sample needed, and detecting a 2% revenue change can require around 100,000 users per variant. A result is only a real win if the primary metric moved, revenue per visitor moved with it, the guardrails held, and it's still visible in the measurement surface you rely on.
Probably only if the page you want to test can hit its planned sample inside a sensible window, usually while covering at least one full weekly cycle. If it gets a few hundred sessions a week and very few purchases, testing small changes is usually too slow to be worth it, and we'll tell you so.
Long enough to meet the planned sample and at least one full business cycle, in practice a minimum of seven days, and often two full weeks for important tests. Ending after a few strong-looking days is how teams get fooled by noise.
If the issue is clearly broken, fix it. Testing is for uncertain trade-offs between credible alternatives, not for delaying obvious bug fixes, bad UX, broken measurement or checkout failures.
If you have the volume, use a revenue metric such as revenue per visitor, with order rate and basket value alongside it. If purchase volume is too low, a proxy like add-to-cart can be used temporarily, but only with strong guardrails, because a lift in add-to-cart that hurts checkout or basket value isn't a real win.
Start Here
Book the phase-one audit so we can review one revenue-critical WooCommerce journey first.