WooCommerce CRO Technique
How to write a WooCommerce A/B test hypothesis and prioritise tests with ICE
This technique turns test ideas into falsifiable WooCommerce experiments by forcing each idea to link a real problem, a specific change, a primary metric and a defined segment before build starts. It helps most when traffic, developer time or both are limited, because underpowered or loosely defined tests waste scarce experiment slots and make results easier to misread.
Summary
Bottom Line: For WooCommerce, write every test idea as because [evidence], we expect [change] to move [metric] for [segment], then rank it in a backlog with Impact, Confidence and Ease so the next test is chosen by evidence and practicality, not opinion.
- A stronger WooCommerce hypothesis starts with observed friction, not a design preference: use GA4 to find where users drop, then use replay, heatmaps and direct customer feedback to understand why.
- Confidence in ICE should reflect evidence quality, not stakeholder certainty. A hypothesis backed by funnel drop-off, replay pattern and voice-of-customer deserves a higher score than a copied “best practice” with no store-specific evidence.
- Define one primary metric and a small set of guardrails before launch. Changing the success metric after results arrive invites confirmation bias and weakens decision-making.
- On WooCommerce, record the exact surface each idea touches, especially whether cart and checkout use Blocks or classic shortcodes, because implementation options and extension compatibility can differ.
- ICE is a fast backlog method, not a scientific law. If your ideas span pages with very different traffic or commercial weight, sense-check with PIE because ICE does not explicitly include reach or page importance.
How To Implement
Make sure the evidence stack is live before you prioritise anything
In WooCommerce, go to WooCommerce → Settings → Advanced → Features and confirm Analytics is enabled. If you want last-touch context inside WooCommerce Analytics, enable Order Attribution there as well. If you use the official Google Analytics for WooCommerce plugin, verify tracking in Google Tag Assistant before you score backlog ideas; WooCommerce’s own documentation recommends simulating actions such as add to cart and checkout to confirm events are sent correctly. Measurement note: do this before backlog scoring, otherwise you risk assigning high confidence to bad instrumentation.
Create a simple backlog with fixed columns
A shared sheet is enough. Recommended columns are: idea ID, date added, WooCommerce surface, page/template, Blocks or classic, segment, evidence links, problem statement, hypothesis, primary metric, guardrails, ICE score, owner, status, test result, and what you learned. This mirrors the documented discipline experimentation teams use in test plans: hypothesis, targeting, primary metric, decision rules and risk should exist before launch, and a documented record is more useful than isolated studies.
Source ideas from quantified drop-off first
In GA4, use Explore → Funnel exploration to visualise where users complete or abandon a task. For storewide commerce journeys, Google’s purchase journey report uses
session_start,view_item,add_to_cart,begin_checkoutandpurchase. For checkout-only friction, the checkout journey relies onbegin_checkout,add_shipping_info,add_payment_infoandpurchase. Start by isolating the sharpest drop for an important cohort, not by brainstorming page tweaks.Add qualitative evidence so the backlog explains why
Replay and heatmaps show how users interact with the page, while surveys capture their feedback in the moment. Use Microsoft Clarity or a similar replay tool to inspect the failing step, and pair that with on-site feedback or exit surveys. NN/g’s guidance is the useful shorthand here: analytics tells you what users are doing, but user research is needed to understand why.
Write the hypothesis in one sentence and make it falsifiable
Use this exact structure: Because [evidence], we expect [change] to move [metric] for [segment]. For example: Because mobile users drop between add to cart and begin checkout, and recordings show repeated coupon-field interaction, we expect hiding the coupon field by default on the cart page to increase checkout completion for mobile cart visitors. The key is that the evidence names the problem, the change names the treatment, the metric names success, and the segment defines who should be affected. Strong hypotheses are rooted in observed behaviour and sentiment, not random UI tweaks.
Record the exact WooCommerce implementation surface
This is where WooCommerce specificity matters. For product-page ideas, record whether the change sits in the single-product template, gallery, price box, add-to-cart area or reviews area. For cart and checkout ideas, record whether the store uses Cart & Checkout Blocks or classic shortcodes. WooCommerce states that Cart and Checkout Blocks are the default on new installs from version 8.3, while classic pages still use
[woocommerce_cart]and[woocommerce_checkout]. If you need to revert a checkout or cart page to classic for compatibility, WooCommerce documents the path as Appearance → Editor → Pages → Cart or Checkout → Transform → Classic Shortcode on block themes, or Pages → All Pages on non-block themes. If you revert one of cart or checkout, revert both.Score with ICE, but define the rules first
Agree one scoring scale before the first session. A practical store rubric is: Impact = likely movement on the chosen metric if the hypothesis is right; Confidence = strength and triangulation of evidence; Ease = build and QA effort on this WooCommerce setup, including theme, Blocks/classic and extension constraints. ICE is intentionally lightweight and relative, so use it to order one backlog, not to create false precision. Also note that published explanations disagree on the exact formula: some use an average of the three scores, others multiply them. Consistency inside your backlog matters more than the arithmetic style. If traffic importance varies sharply across ideas, use PIE as a second pass because PIE explicitly asks about Potential, Importance and Ease.
Set the primary metric and guardrails before the test is built
Pick one primary metric that is as close to the treatment as possible. If you are changing a CTA, a near-page metric may be better than using revenue immediately; if the real trade-off is between conversion rate and basket size, RPV may be the better overall criterion because it combines conversion rate and AOV. Add a small number of guardrails that the change must not harm, such as checkout completion, AOV, conversion rate, refund rate, or Core Web Vitals if scripts or UI payload are changing. Avoid loading the test with too many metrics, because that slows analysis and increases confusion.
Add one WooCommerce caveat line for feasibility
For each item, include a short note such as: “Blocks checkout; no custom checkout field plugin in play” or “Classic shortcode checkout; payment gateway JS customised; HPOS compatibility to confirm.” Prioritisation itself is not blocked by HPOS, but WooCommerce documents that HPOS uses dedicated order tables and is enabled by default on new installations from 8.2 onward, so any experiment tool, plugin or custom code touching order storage or reporting should be checked before a test is promoted from idea to ready.
How To Measure
The main KPI for this technique is backlog quality, not an on-site conversion metric. In practice, that means the percentage of “ready” backlog items that include: a named evidence source, a one-sentence hypothesis, a defined segment, one primary metric and explicit guardrails. A useful supporting KPI is throughput: how many top-ranked, evidence-backed tests you actually launch in a quarter, and what share of launches came from the highest-priority part of the backlog rather than ad-hoc requests. This is a recommended operating metric set, grounded in the fact that experiments need a pre-agreed plan and pre-selected metrics to avoid bias.
Use GA4 Funnel exploration when the hypothesis is about store navigation or lower-funnel progression, and use Purchase journey or Checkout journey when the hypothesis is about ecommerce step completion. Read results in the exact segment named in the hypothesis: for example mobile users, paid social landers, returning customers, or a specific product category cohort. If the hypothesis concerns checkout, the most relevant GA4 events are begin_checkout, add_shipping_info, add_payment_info and purchase; if it concerns earlier product discovery, include view_item and add_to_cart as well.
Success looks like an ordered queue where the first tests to run are the ones with the clearest evidence trail and the clearest metric definition, not simply the loudest internal requests. For the experiments themselves, keep the business metric vocabulary consistent: use RPV, conversion rate, AOV or checkout completion as appropriate, then add guardrails that must not get worse. If the change adds scripts, widgets or visual instability risk, include LCP, INP and CLS as performance guardrails; Google’s current “good” thresholds are LCP within 2.5 seconds, INP at 200 ms or less, and CLS at 0.1 or less, measured at the 75th percentile.
Pitfalls
- Myth: ICE makes prioritisation objective. It does not. ICE is deliberately simple and still relies on human judgement; published guides note subjectivity, lack of an explicit reach factor, and the danger of chasing only easy wins.
- Mistake: scoring confidence from optimism instead of proof. Confidence should go up when evidence is triangulated across analytics, qualitative observation and customer feedback, not because the team likes the idea.
- Mistake: using GA4 alone to write “why” statements. GA4 is excellent at showing where the journey breaks, but not sufficient on its own to explain cause; pair it with recordings, heatmaps and direct feedback.
- Mistake: deciding the win metric after you see results. Primary and guardrail metrics should be selected before launch, otherwise you invite confirmation bias and inconsistent shipping decisions.
- Mistake: treating all WooCommerce checkout ideas as equally easy. A change on a Blocks checkout can differ materially from the same idea on a classic shortcode checkout, and extension or HPOS compatibility can change effort.
- False positive to watch: reading an open funnel as proof that the whole journey works. Google’s purchase and funnel reporting can be shown as open or closed funnels; if your ecommerce events are incomplete, the picture can look healthier or stranger than the real checkout path.
Examples
FAQs
No. A shared sheet is enough to start, because the value comes from evidence quality, scoring discipline and pre-defined metrics rather than from the backlog software itself. Experimentation platforms formalise those fields, but the planning discipline is the important part.
ICE is usually the simpler default for a small WooCommerce backlog, while PIE is useful when page importance and traffic differ sharply across ideas. ICE is quick and lightweight, but PIE makes traffic value part of the discussion more explicitly.
No. GA4 tells you where users drop, but you still need behavioural observation and direct customer feedback to understand the likely cause of that drop-off.
Confidence should mean the strength of the evidence behind the hypothesis, not how strongly someone argues for it. In practice, confidence should rise when multiple methods point to the same friction and fall when the idea rests on opinion or borrowed best practice.
Sources & Further Reading
- WooCommerce — Page Shortcodes – Date: publication date not clearly stated in page view; search snippet shows it was published about 2024. Confirms that Cart and Checkout Blocks are the default for new installations from WooCommerce 8.3, and that classic shortcode alternatives still exist.
- WooCommerce — Customizing the Cart and Checkout Pages – Date: publication date not clearly stated in page view; search snippet shows it was published about 2024. Documents the block-theme and non-block-theme paths for editing Cart/Checkout and converting Blocks back to classic shortcodes.
- WooCommerce — High-Performance Order Storage – Date: publication date not clearly stated in page view; search snippet shows it was published about 2022. Explains HPOS, its dedicated order tables, and that it is default for new installations from WooCommerce 8.2 onward.
- Google Analytics for Developers — Measure Ecommerce – Date: updated 4 May 2026. Primary reference for GA4 ecommerce events such as begin_checkout, add_shipping_info, add_payment_info and purchase.
- Google Analytics Help — Funnel Exploration – Date: date not stated in page view. Documents GA4 funnel exploration as the core way to visualise task completion and abandonment.
- Google Analytics Help — Checkout Journey Report – Date: date not stated in page view. Confirms the required GA4 events for the checkout journey and how abandonment is shown between steps.
- NN/g — Mixed-Methods Research: Combining Qualitative and Quantitative Data – Date: 25 Jul 2025. Strong independent source on why quantitative and qualitative methods should be combined rather than treated as substitutes.
- NN/g — Turning Analytics Findings into Usability Studies – Date: 16 Feb 2018. Still-useful principle piece: analytics tells you what users do, but not why they do it.
- Microsoft Clarity FAQ – Date: 12 May 2026. Official reference confirming Clarity’s session recordings and heatmaps as behaviour-analysis inputs.
- Hotjar Documentation — How to Create a Survey – Date: date not stated on page. Useful official source for on-site surveys as a voice-of-customer input.
- Optimizely — 127k Experiments Later, Here’s What We Learned – Date: date not clearly stated in page view. Vendor source, but useful for the practical point that every experiment needs a pre-agreed test plan covering hypothesis, targeting, primary metric and risks.
- Optimizely Support — Primary Metrics, Secondary Metrics, and Monitoring Goals – Date: 3 Feb 2025. Solid practical source on picking a primary metric, using guardrails, and why metric definition should happen before launch.
Want us to implement this for you?
We run measured CRO consultancy for WooCommerce. If you want help prioritising, testing & implementing these improvements, tell us about your store.
Book PilotAbout This Page
- Written By: Eliot Webb – Founder & WooCommerce CRO Consultant
- Last Reviewed: 22 Jun 2026
- Last Updated: