DEV Community: Hamdi Bk

WooCommerce Checkout Not Working? 9 Checks to Find the Cause

Hamdi Bk — Sun, 01 Nov 2026 00:38:57 +0000

A broken WooCommerce checkout rarely shows an error to the store owner: orders just stop. This is the checklist we published on optiuser.com, in the order we run it. Disclosure: we build Opti-Behavior, the plugin mentioned in some sections.

If your WooCommerce checkout is not working, the cause is almost always one of five things: a JavaScript error on the checkout page, a plugin or theme conflict, a cached checkout page, a payment gateway problem, or a broken HTTPS or session setup. This guide shows the signs, then 9 checks to run in order, most of them without any extra plugin, and how to confirm the fix on your live store.

Signs your WooCommerce checkout is not working

A broken checkout rarely shows a clear error. Look for these signs:

The Place order button does nothing. The shopper clicks, nothing moves, no message appears.
The spinner never stops. The checkout form greys out after the click and stays that way.
An error appears after the click, often a vague one such as “There was an error processing your order” or a session expired message.
Orders pile up in Pending payment or Failed in WooCommerce > Orders, while paid orders drop.
The cart empties after a product is added, or the checkout page shows “Your cart is currently empty”.
The checkout page is blank or shows only part of the form.

Note when it started: after a plugin, theme or WooCommerce update, after a new cache or CDN rule, or after a change of payment gateway. That date narrows the search more than anything else.

Why the WooCommerce checkout page is not working: 9 checks in order

Run these checks in this order. The first ones take two minutes and catch most cases.

1. Place an order yourself, on desktop and on a phone

Use a private browser window, add a product, and go to the end of the checkout with each payment method you offer. Then do it again on a phone. A failure that only happens on mobile, or only with one payment method, already tells you where to look.

2. Place order button not working? Open the browser console

On the checkout page, open the developer tools (F12, or right-click > Inspect), then the Console tab, and click Place order. A red error that mentions a plugin or theme file is the most common reason the button does nothing: one broken script can stop the checkout script that sends the order.

Then open the Network tab and click again. With the classic checkout, look for the request that contains wc-ajax=checkout; with the Checkout block, look for the request to /wp-json/wc/store/. A 500 status points to a PHP error on the server, a 403 often to a security plugin or firewall rule.

3. Exclude cart, checkout and my-account from the cache

A cached checkout page can serve an expired security token or someone else’s empty cart, and the order then fails or the cart looks empty. Most cache plugins exclude these pages by default; check again if you added a CDN, a server cache or custom rules. If you also use a JavaScript optimisation feature (combine, defer or delay JavaScript), exclude the checkout scripts from it or turn it off for the checkout page, then test again. We wrote more about cache side effects in our guide to cache plugins and tracking.

4. Checkout page not working after an update: test for a conflict

Install the free Health Check & Troubleshooting plugin and turn on its troubleshooting mode: it disables plugins and switches the theme for your own session only, so shoppers are not affected. Keep only WooCommerce and your payment gateway, switch to the Storefront theme, and place a test order. If it works, turn the other plugins back on one by one until the checkout breaks again. Checkout field editors, cache and optimisation plugins, security plugins and custom theme templates are the usual suspects. If you prefer, do the same test on a staging copy of the site.

5. Read the WooCommerce logs

Go to WooCommerce > Status > Logs. Open the log of your payment gateway and the fatal-errors log for the day of the problem. A PHP fatal error during checkout, a declined API call or an invalid API key shows up here even when the shopper only sees a spinner. For more detail, turn on WP_DEBUG_LOG on a staging site and repeat the order.

6. Check the payment gateway settings

Many “checkout not working” cases are a gateway still in test or sandbox mode, live keys pasted in the test fields, an expired API key, or a webhook that no longer reaches your site. Open the gateway settings, check which mode is active, and use the gateway’s own dashboard to see whether the payment attempts reached it at all.

7. Read your Pending payment and Failed orders

In WooCommerce > Orders, filter on Pending payment and on Failed. Pending payment means the order was created but the payment was never confirmed; Failed means the payment was refused or returned an error. A sudden rise after an update points to a technical problem, not to shoppers changing their mind. Open a few of these orders and read the order notes: the gateway often writes the reason there.

8. Check HTTPS, the site address and sessions

In Settings > General, the WordPress Address and Site Address must both use https and the same domain (with or without www). A mix of http and https, or of two domains, can lose the WooCommerce session between the cart and the checkout, which empties the cart. A browser warning about mixed content on the checkout page is a sign of the same problem.

9. Check the checkout page itself

Go to WooCommerce > Settings > Advanced and check that the Checkout page setting points to the right page. Open that page in the editor: it must contain the Checkout block or the `` shortcode, and only one of them. A page builder template that replaced the checkout content is a frequent cause of a blank or partial checkout.

How to see where the checkout breaks on your live store

Here is what this looks like on real data. On our WooCommerce test store, the suggested Purchase Funnel recorded, from 28 August to 25 September 2026, 126 visitors entering at the shop, 75 reaching the cart, 69 reaching the checkout and 27 reaching Order received. The biggest loss is the last step: 42 of the 69 visitors who reached the checkout never saw the confirmation page. That Checkout to Order received step is the one to read first. On a store where the checkout works, a gap there means shoppers stopping at the form; if it suddenly widens after an update, test the checkout before anything else.

The checks above find the cause when you can reproduce the problem. The hard cases are the ones you cannot reproduce: the checkout fails only for some shoppers, on some devices, some days. For those, you need numbers from real visits.

The simplest measure works in any analytics tool: over the same days, compare visits to the checkout page with visits to the order-received page. If checkout visits stay normal and confirmations fall close to zero, the checkout is broken, not your shoppers. Our guide to WooCommerce conversion tracking shows how to measure every step from product page to paid order.

Opti-Behavior is our WordPress plugin, so we are not neutral here. This is how we use it for this problem:

Suggested WooCommerce funnels (Free). On the Funnels page, Opti-Behavior detects WooCommerce and suggests a Purchase Funnel (Shop, Product page, Cart, Checkout, Order received) and a Cart Recovery Funnel (Cart, Checkout, Order received), filled with your real shop addresses. Confirm one, wait a few days of visits, and read the Checkout to Order received step: a step that falls after an update is your broken checkout. Split it by device to see if only phones are hit.
Error tracking (Pro). Opti-Behavior Pro logs JavaScript errors and failed network requests on your pages, with the page where they happened. Look at the errors seen on your checkout page around the date the funnel dropped: that is often the script that stops the Place order button. See WordPress error tracking.
Checkout form analytics and session recordings (Pro). When the checkout works but shoppers still stop, see the field where they quit, and watch a few replays of visits that left at the checkout. Our guide to WooCommerce checkout abandonment explains that side.

Free: Smart Insights turns a funnel into a card that names the step where visitors leave, ranked by priority (demo data).

The reports are stored in your own WordPress database. See what is in each version on the pricing page, or install the free plugin from WordPress.org.

Find the step where your orders stop

Install the free plugin, open Funnels, confirm the suggested WooCommerce funnel and read the Checkout to Order received step after a few days of visits.

What to check after the fix

Place a test order again on desktop and on a phone, with every payment method, and refund it.
Check that the order arrives as Processing (or Completed for virtual products), not Pending payment.
Check that the customer and admin e-mails for the order were sent.
Clear every cache layer (plugin, server, CDN) and test once more from a private window.
For the next 7 days, compare checkout visits with order-received visits, or read the Checkout to Order received step of your funnel, against the 7 days before the problem.
Write down which plugin or setting caused it, so you test that one first after the next update.

If the checkout works but shoppers still leave, the problem is no longer technical: read why WooCommerce shoppers abandon their cart and how to find the step where they leave.

WooCommerce checkout not working: FAQ

Why does my Place order button not work?

Most often a JavaScript error on the checkout page stops the script that sends the order. Open the browser console, click Place order and read the red errors; then test for a plugin or theme conflict with troubleshooting mode.

Why is my WooCommerce checkout spinning forever?

The order request was sent but the answer never came back correctly: a PHP error on the server, a security rule that blocks the request, or a payment gateway that does not respond. Check the Network tab for the status of the checkout request, then the WooCommerce logs.

Why are my WooCommerce orders stuck in Pending payment?

The order was created but the payment was never confirmed. Either the shopper left the payment page, or the gateway could not tell your site that the payment succeeded, often because of a webhook problem. Read the order notes and the gateway dashboard.

Can a cache plugin break the WooCommerce checkout?

Yes. A cached cart or checkout page, or a JavaScript optimisation applied to the checkout, can break orders. Exclude cart, checkout and my-account from every cache layer.

Why does my WooCommerce cart empty itself?

The WooCommerce session is lost between pages: a cached cart page, a mix of http and https or of www and non-www addresses, or a plugin that blocks the session cookie. Fix the site address and the cache exclusions first.

Find where your checkout breaks

Install the free plugin, then confirm the suggested Purchase Funnel and read the Checkout to Order received step.

The Opti-Behavior Team

Full checklist: https://optiuser.com/go/devto-checkout-not-working

Drafted with AI assistance, reviewed by the Opti-Behavior Team.

What Is a Good Conversion Rate? (And Why the Average Can Fool You)

Hamdi Bk — Sat, 31 Oct 2026 09:42:49 +0000

"Is 2 % good?" is the question every site owner asks once. This is the guide we published on optiuser.com: why the average can fool you, how to find a good rate for your own site, and how to raise it. Disclosure: we build Opti-Behavior, the plugin mentioned in some sections.

Imagine Nadia. She sells online yoga classes. Last month, 3,000 people visited her sales page and 45 bought a class. She typed "what is a good conversion rate" into Google and found an article that said "the average is 2.35%". Hers was 1.5%. She felt terrible.

Nadia is an example: her site and figures are made up to show the method step by step.

Then she found another article that said "a good conversion rate is 10%". Now she felt even worse.

Here is the truth: both articles were talking about other people’s websites. A good conversion rate depends on what you sell, who visits, and what you count as a conversion. In this guide we will work out a good rate for Nadia’s site, step by step, and then find ways to raise it.

Short answer: A good conversion rate is one that is better than your own rate last month, measured the same way. Industry averages are rough hints, not goals. Measure one clear action, per visitor, for each type of page, and improve the weakest step first.

What is a conversion, exactly?

A conversion is when a visitor does the thing you want. It can be big or small:

Type	Examples
Big (macro) conversion	A purchase, a paid sign-up, a booked call, a quote request
Small (micro) conversion	Adding to cart, starting a form, signing up to a newsletter, watching a demo

Small conversions matter because they lead to big ones. If nobody adds to cart, nobody buys.

How to calculate your conversion rate

The formula is simple:

Conversion rate = conversions ÷ visitors × 100

Nadia: 45 purchases ÷ 3,000 visitors × 100 = 1.5%.

But watch out. Tools do not all divide by the same thing:

Per visitor: 45 buyers out of 3,000 people. This is the honest one for sales.
Per session: 45 buyers out of 4,200 visits. The rate looks lower, because many people visit twice before buying.
Per page: conversions on one page divided by that page’s visitors. Best for comparing pages.

When you compare numbers, always use the same method. Many "benchmark" articles do not say which one they used.

So what is a good conversion rate?

Here are ranges you often see quoted in marketing reports. They come from different studies and change every year, so treat them as rough hints:

Type of page or site	Often quoted range
Online shop (all visitors)	1% to 3%
Shop, visitors who add to cart	30% to 60% reach checkout
Lead form on a service site	2% to 5%
Dedicated landing page from an ad	5% to 15%
Newsletter sign-up box on a blog	1% to 3%
Free trial sign-up (software)	3% to 10%

Why are the ranges so wide? Because a "good" rate depends on:

Price. A $5 ebook converts more than a $900 course.
Traffic source. Visitors from your newsletter already trust you. Visitors from a cold ad do not.
Device. Mobile visitors often browse and buy later on a computer.
Intent. Someone searching "buy yoga class online" is ready. Someone searching "is yoga good for back pain" is learning.

So Nadia’s 1.5% was not bad for a paid course with mostly cold traffic. The real question was: which part of her journey was weak?

Split the rate into steps

One big conversion rate hides where the problem is. Split the path into steps. This is called a funnel.

Nadia’s path was: Sales page, Pricing, Checkout, Thank-you page. In Opti-Behavior, you can create this funnel in a minute: go to Opti-Behavior > Funnels, click Build New Funnel, and add each step with a URL rule, like "URL Contains /pricing/". Opti-Behavior also suggests funnels built from the pages of your site.

Each step shows how many visitors continue and how many leave.

Here is what Nadia’s funnel showed:

Step	Visitors	Continue to next step
Sales page	3,000	28%
Pricing	840	22%
Checkout	185	24%
Thank-you	45

The big leak was at checkout: 185 people started to pay, only 45 finished. That is 76% lost at the very last step. Her sales page was fine. Her checkout was not.

With Pro, each funnel step links to the recordings of the people who left right there. Nadia watched eight of them. On phones, her checkout asked people to create an account with a password before paying. Most gave up at the password field.

In Pro, each step links to the recordings of the visitors who dropped there.

Measure what counts as a win

When you change something, you want to know if it worked. That is what A/B tests are for: half your visitors see the old version, half see the new one, at the same time.

In Opti-Behavior, a test has goals. The first goal is the one that picks the winner.

Goal	Counts a conversion when	Plan
Page visit	The visitor reaches a page, like a thank-you page	Free
Click	The visitor clicks an element you pick on the page	Free
Form submit	A form on the page is sent	Free
Scroll depth	The visitor scrolls to a depth you set	Pro
Time on page	The visit lasts longer than a threshold	Pro
Revenue	WooCommerce orders from the test	Pro

Pick the action that counts as a conversion. The first goal decides the winner.

The free version runs up to 3 tests at the same time, with up to 3 versions each.

Careful: a higher conversion rate is not always better

This surprises a lot of people. Look at this real-style example from our A/B testing docs:

Version	Visitors	Orders	Conversion rate	Average order	Revenue per visitor
A (current)	1,000	30	3.0%	60 €	1.80 €
B (free shipping over 50 €)	1,000	27	2.7%	78 €	2.11 €

Version B has a lower conversion rate, but people spend more, so it earns 17% more per visitor. If you only looked at the conversion rate, you would pick the wrong version. For shops, watch revenue per visitor too. Pro can measure it with a Revenue goal.

Know what one conversion is worth

Once you know the value of one conversion, every leak has a price. In Smart Insights settings, you can type the value of one conversion (Free and Pro). Smart Insights then estimates what a problem costs you. With Pro, WooCommerce orders set that value for you.

Type the value of one conversion, or, with Pro, let WooCommerce orders price the losses.

For Nadia, one class was worth 60 €. Losing 140 people at checkout every month was not "a bad conversion rate". It was up to 8,400 € a month walking away. That made the fix very easy to prioritize.

8 ways to raise your conversion rate

Fix the weakest step first. A 10% gain on your worst step beats a 10% gain on your best one.
Remove forced account creation. Let people buy as guests. Offer an account after payment.
Show the price and what is included early. Surprises at checkout kill sales.
Make the main button obvious. One clear action per page, visible without scrolling on mobile.
Answer doubts next to the button. Refunds, delivery time, support. One line each.
Speed up mobile. A slow checkout on a phone loses people fast.
Check for broken things. Rage clicks and JavaScript errors on a checkout page are pure lost money. Read our guide on rage clicks.
Test, do not guess. Run an A/B test on one change at a time. Our WordPress A/B testing guide shows how.

Nadia’s new conversion rate

Nadia allowed guest checkout and moved the account creation to the thank-you page. Six weeks later, 44% of people who reached checkout finished paying, instead of 24%. Her overall conversion rate went from 1.5% to 2.7%, with the same traffic.

She still does not know if 2.7% is "good" for the whole yoga industry. She does not care anymore. It is better than last month, and she knows exactly which step to work on next.

Find your weakest conversion step

Opti-Behavior is free: funnels, click heatmaps and A/B tests on WordPress. Pro adds drop-off recordings and revenue goals, with a 6-month free trial.

Good conversion rate FAQ

What is a good conversion rate?

It depends on your site, price and traffic. Rough ranges often quoted are 1% to 3% for online shops, 2% to 5% for lead forms and 5% to 15% for focused landing pages. The best benchmark is your own rate last month, measured the same way.

How do I calculate my conversion rate?

Divide the number of conversions by the number of visitors and multiply by 100. For example, 45 sales from 3,000 visitors is a 1.5% conversion rate.

Is a 2% conversion rate good?

For an online shop with mixed traffic, 2% is often considered solid. For a landing page that only receives ad visitors, it may be low.

Why is my conversion rate low?

Usually one step loses most people: an unclear offer, a hidden button, a surprise cost, a long form or a broken checkout. A funnel shows which step, and recordings show why.

Should I trust average conversion rate benchmarks?

Only as a rough hint. Studies measure different sites in different ways. Track your own rate per page and per step, and try to beat it.

The Opti-Behavior Team

Full guide: https://optiuser.com/go/devto-conversion-rate

Drafted with AI assistance, reviewed by the Opti-Behavior Team.

Add to Cart Rate: How to Find the WooCommerce Products That Lose Buyers

Hamdi Bk — Mon, 26 Oct 2026 04:38:23 +0000

Add to cart rate is the first number to read when a WooCommerce product gets visits but few sales. This is the guide we published on optiuser.com: how to measure it per product, how to find the pages that lose buyers, and how to fix them. Disclosure: we build Opti-Behavior, the plugin mentioned in some sections.

Your add to cart rate is the share of product page views that end with a click on Add to cart. On a WooCommerce store, it is the first number to check when you have visitors but few orders: if shoppers never put a product in the cart, no checkout fix will help. This guide shows how to calculate it, how to find the products that lose the most buyers, and what to change on those product pages.

Short answer: add to cart rate = adds to cart ÷ product page views × 100. Measure it per product, not only for the whole store. Sort your products by visits lost (viewed, not added to cart), then work on the product page at the top of the list: price and delivery cost visible, clear photos, simple variation choice, and a button that is easy to reach on a phone.

What is the add to cart rate, and how do you calculate it?

There are two common ways to count it. Both are useful, for different questions.

Per product: adds to cart of one product ÷ views of that product’s page × 100. Example: a product page viewed 400 times with 24 adds to cart has an add to cart rate of 6%. This tells you which page to fix.
Per session: sessions with at least one add to cart ÷ all sessions × 100. Many analytics tools report this one. It tells you whether the store as a whole is getting better or worse.

The two numbers are not comparable with each other, and two tools rarely count the same way. Pick one method, write it down, and compare the store with itself over time.

What is a good add to cart rate?

There is no single good number. Published benchmarks vary with the industry, the price of the products, the device and the way each vendor counts. A €15 accessory and a €900 sofa will never have the same rate.

Three comparisons are more useful than any benchmark:

Each product against your store average. A product far below the others, with similar traffic, has a page problem.
Phones against desktop. A rate that collapses only on phones usually points to layout, photos or the button, not to the price.
This month against last month. A sudden drop after a theme, plugin or price change is a strong clue.

How to measure your add to cart rate in WooCommerce

In WooCommerce itself

The WooCommerce Analytics reports show orders, items sold and net sales per product. They do not show product page views or adds to cart, so you cannot calculate the rate there. You need an analytics tool that records both.

With Google Analytics 4

If your store sends the ecommerce events view_item and add_to_cart (for example with Google’s WooCommerce integration), the Ecommerce purchases report lists items viewed and items added to cart for each product. Divide the second by the first. It works once the event setup is in place.

With Opti-Behavior (free plugin)

Opti-Behavior adds a Shop screen to WordPress on WooCommerce sites (Opti-Behavior > Shop). It counts product views, adds to cart, checkouts and paid orders, and lists the visits each product loses (viewed, not added to cart), worst product first. No event setup is needed.

Why shoppers view a product but do not add it to cart

Before changing anything, check the product at the top of your list against these common causes:

The full cost is unclear. Price visible, but shipping cost and delivery time only appear at checkout.
The photos do not answer the question. No close-up, no scale, no photo of the product in use.
The variation choice blocks the button. On a variable product, the button stays inactive until size and colour are chosen, and shoppers do not see why.
Stock is unclear. “Out of stock” or “available on backorder” with no date.
The button is hard to reach on a phone. Below a long description, under a sticky banner or a cookie notice.
Nothing reassures. No reviews, no returns policy, no way to ask a question.
Something is broken. A JavaScript error or a failed request stops the button from working for some browsers. Repeated clicks on the button are a typical sign: see rage and dead clicks.
The wrong visitors arrive. A campaign or a search result sends people who were looking for something else.

Product page optimization: 7 changes worth testing

Work on one product page at a time, the one that loses the most visits. To see the other steps where your store loses buyers, from cart to paid order, read our guide to WooCommerce conversion tracking. Change one thing, then compare the same number of days before and after.

Show the delivery cost and delivery time next to the price. If you offer free shipping above an amount, say it here.
Put the Add to cart button where a phone user sees it without scrolling past the whole description.
Make variation choices obvious: swatches or clear labels, and a short message when a choice is missing.
Add the photos shoppers ask for: close-up, scale, in use. Check what they click on the page first.
Answer the top three questions in the first lines of the description (size, material, compatibility, what is in the box).
Bring reassurance near the button: returns policy, delivery promise, a contact link, reviews if you have them.
Test the page yourself on a phone with each variation, after every theme or plugin update.

When shoppers do add to cart but still do not buy, the problem has moved to the next step: see our guides to the WooCommerce abandoned cart and to WooCommerce checkout abandonment.

How Opti-Behavior finds the product that loses buyers, and what to fix

Opti-Behavior is our WordPress plugin, so we are not neutral here. The data stays in your WordPress site, and the work follows three steps: the modules collect, Smart Insights ranks the problems, and a report tells you what to fix.

1. The modules collect the signals

Shop for WooCommerce (Free): views, adds to cart, checkouts and paid orders, and the visits lost per product, worst product first.
Funnels (Free): on a WooCommerce site, Opti-Behavior suggests ready-made funnels built from your own addresses, such as Product page → Cart → Checkout → Order received.
Click heatmaps (Free): see what shoppers click on the product page instead of Add to cart: photos, tabs, the size guide, a link away.

2. Smart Insights ranks what costs the most

Smart Insights turns the data into one card per problem, ranked by visitors lost, with a confidence level based on the visits measured. In Pro, a WooCommerce card flags a product page whose visitors rarely reach the cart, and funnel cards name the step where visitors leave.

3. The report says what to fix, in order

Page X-Ray (Pro) opens one product page: a health score, what the page is for and how often visitors reach its main button, a page audit (buttons, trust, content) and an action plan. The free plugin shows a preview of your three most visited pages, each with its health score and first problem. More on what Page X-Ray checks.
Site report and scheduled e-mail (Free): the three most costly issues of the period and, on WooCommerce sites, the product that loses the most visits.
Shop in Pro: an estimated range of lost sales per product, from your conversion rate and average order, and shop events (add to cart, checkout, payment failure) inside session recordings, recorded only in Full Tracking mode after the visitor’s consent.

4. Check that the fix worked

When your change is live, mark the Smart Insights card as resolved. Opti-Behavior measures the period after your change and shows the result, so you know whether the product page really improved.

Find the product that loses your buyers

Install the free plugin, open Opti-Behavior > Shop after a few days of visits, and start with the first product of the list. See what is in each version on the pricing page.

Add to cart rate FAQ

How do I calculate the add to cart rate?

Divide the number of adds to cart by the number of product page views, then multiply by 100. Per product, this shows which page to fix. Per session (sessions with an add to cart ÷ all sessions), it shows the trend of the whole store.

Does WooCommerce show the add to cart rate?

Not in its built-in Analytics reports, which show orders and items sold but not product views or adds to cart. Use an analytics tool that records both, such as GA4 with ecommerce events or the Shop screen of Opti-Behavior.

What is the difference between add to cart rate and conversion rate?

The add to cart rate measures the first step: product page to cart. The conversion rate measures the whole journey to a paid order. A store can have a good add to cart rate and a poor conversion rate when the problem is in the cart or the checkout.

Why is my add to cart rate low only on mobile?

Usually because of the page, not the product: the button sits far below the photos and description, a banner covers it, or the variation choice is hard to use on a small screen. Test the page on a real phone.

Is the Shop screen free in Opti-Behavior?

Yes. Product views, adds to cart, checkouts, paid orders and visits lost per product are in the free plugin. The estimated lost sales per product, Page X-Ray reports and session recordings are in Pro.

The Opti-Behavior Team

Full guide: https://optiuser.com/go/devto-add-to-cart

Drafted with AI assistance, reviewed by the Opti-Behavior Team.

WooCommerce Conversion Tracking: Find the Step That Loses Sales

Hamdi Bk — Sat, 24 Oct 2026 15:11:30 +0000

Most WooCommerce stores know what sold. Few know where the buyers who did not buy stopped. Below is the guide we published on optiuser.com: the five steps to track, how to set them up with GA4 or inside WordPress, and the four leaks they usually reveal. Disclosure: we build Opti-Behavior, the plugin mentioned in some sections.

WooCommerce conversion tracking means counting how many visitors reach each step of a purchase, from the product page to the paid order, so you can see where sales are lost. WooCommerce reports tell you what sold. They do not tell you who almost bought. This guide shows how to set up WooCommerce conversion tracking with the tools you already have, then the four problems it usually reveals and how to fix each one.

Short answer: track five steps (product page, add to cart, cart, checkout, order received), compare each step with the one before, and work on the biggest drop first. Google Analytics 4 can do it once your store sends ecommerce events; a WordPress funnel can do it from page visits. Then check the four usual leaks: products viewed but not added, checkouts started but not paid, payments that fail, and the product pages that lose the most sales.

What WooCommerce reports show, and what they miss

The WooCommerce Analytics menu lists revenue, orders, products, categories, coupons and stock. It answers “what did we sell?”. It does not count the visits that did not become an order, so it cannot give you a conversion rate per step.

A store owner usually feels the problem as “traffic is fine, orders are not”. Conversion tracking turns that feeling into four precise questions:

Which product pages are seen but rarely added to cart?
At which step between cart and order do buyers leave?
Do payments fail, with which payment method and which error?
Which of these problems costs the most?

How to set up WooCommerce conversion tracking

1. Write down the steps

Use the same five steps whatever the tool: product page, add to cart, cart page, checkout page, order received page. For the last step, use a rule like “URL contains order-received”, because the real confirmation address contains the order number.

2. With Google Analytics 4

GA4 needs the ecommerce events view_item, add_to_cart, begin_checkout and purchase. Google’s official WooCommerce integration sends them. Then build a Funnel exploration in the Explore section with those events as steps. If you also run ads, Google Ads and Meta each need their own purchase conversion, usually sent by their official WooCommerce extensions. Check how each one fits your consent setup before you turn it on.

3. Inside WordPress, from page visits

A funnel built from page visits needs no event setup: it counts the visitors who reach each page in order. In our guide to WordPress conversion funnels we show how it works. Opti-Behavior, our plugin, detects WooCommerce and suggests a Purchase Funnel (Shop, Product page, Cart, Checkout, Order received) with your real cart and checkout addresses filled in. This is in the free plugin.

4. Test the tracking

Place a test order on a phone and on a computer, and check that each step counts it once.
Exclude your own visits and your team’s, or they will hide the real drop.
Compare the order count of the tracking with WooCommerce > Orders for the same days. A large gap means a step is not measured.

Problem 1: products viewed but not added to cart

The sign: a product gets visits from search or ads, but sells little.

Check by hand: for each product, divide adds to cart by product page views over the same period, then sort from the lowest. Open the worst pages on a phone: the price, the delivery cost, the stock and the add to cart button should be visible without scrolling.

What Opti-Behavior shows (Free): the Shop screen of our WooCommerce analytics lists, for each product, product views, adds to cart, paid orders and lost visits (product page views that did not lead to an add to cart), worst product first. A product with adds to cart but no measured product view shows “Not measured” instead of 0. The click heatmap of the product page, also free, shows whether visitors click the gallery, the tabs or the button.

Problem 2: checkouts started but not paid

The sign: carts are filled, the checkout page gets visits, few orders arrive.

Check by hand: over the same days, compare visits to the checkout page with visits to the order received page. Then filter WooCommerce > Orders on Pending payment and Failed. A sudden drop after a plugin or theme update points to a broken checkout, not to buyers changing their mind. Our WooCommerce abandoned cart guide lists the settings to check first.

What Opti-Behavior shows: the funnel shows where visitors drop off between steps, with a device filter (Free). Smart Insights turns that funnel into a card that names the step where visitors leave, ranked by visitors lost (Free). Opti-Behavior Pro adds dedicated WooCommerce cards (product page to cart, cart to checkout, checkout to purchase), and session recordings show the shop events (add to cart, checkout, paid order, payment failure) in the list and the player, with a “Shop action” filter. Session-linked shop events are recorded only in Full tracking mode, after the visitor’s consent.

Smart Insights (Free) flags the funnel step where visitors drop off and says what to open next.

Problem 3: payments that fail

The sign: orders in Failed status, buyers who write “your payment does not work”, a payment method that suddenly sells nothing.

Check by hand: open WooCommerce > Status > Logs and read the log of each payment gateway for the days of the problem. Place a test order with each payment method, on a phone too.

What Opti-Behavior shows (Pro): on the Shop screen, payment errors grouped by error type and payment method, with the failed attempts, the orders concerned and their estimated cost (orders not paid later). In Full tracking mode, a recording of a failed payment can be watched.

Problem 4: which product loses the most sales

A product with many lost visits is not always the most costly one: a cheap product with high traffic can cost less than an expensive one with fewer visits. Rank by money, not by visits.

Check by hand: lost visits × your conversion rate × your average order value. Example with round numbers: 400 lost visits × 2 % × 50 = about 400 in sales at stake for the period. It is an estimate, not a promise: use it to choose what to fix first.

What Opti-Behavior shows (Pro): the Shop screen gives the estimated lost sales, as an indicative range, per product and for the period, from the lost visits, your conversion rate and your average order. The Shop screen shows lost sales as a range, or "Not enough data" when there are too few orders.

WooCommerce reports by e-mail

Conversion tracking only helps if someone reads it. Instead of opening the admin every day, get the figures sent to you. In Opti-Behavior, the scheduled e-mail report (daily, weekly or monthly) is free and includes a Shop block with the store’s figures. In Pro, the same block adds “Money at stake”, the estimated lost sales of the period, marked as an estimate.

Free or Pro: summary

Problem	What you get	Version
Products viewed but not added	Shop screen: views, adds to cart, paid orders, lost visits per product	Free
Where buyers leave	Suggested purchase funnel, drop-off per step, click heatmaps	Free
A purchase step with a large drop	Smart Insights card naming the step (Free); dedicated WooCommerce cards per purchase step (Pro)	Free / Pro
Why buyers leave	Recordings with shop events (Full mode, after consent) and the “Shop action” filter	Pro
Payments that fail	Payment errors by type and payment method, with estimated cost	Pro
What each product costs	Estimated lost sales per product (indicative range)	Pro
Reports by e-mail	Shop block with figures / “Money at stake”	Free / Pro

The full list of each version is on the pricing page.

What to check after a fix

Change one thing at a time: the product page, the cart, the checkout or a payment method.
Compare the same number of days before and after, on the same step of the funnel.
Split by device: a fix on desktop can leave the problem on phones.
Check WooCommerce > Orders too: more checkouts without more paid orders means the leak moved to the payment step.

FAQ

Does WooCommerce track conversions on its own?

It records orders, revenue and products sold. It does not count the visitors who saw a product or started a checkout without buying, so it cannot show a conversion rate per step without another tool.

Do I need Google Analytics for WooCommerce conversion tracking?

No. GA4 works once your store sends ecommerce events. A funnel built from page visits inside WordPress gives the step-by-step drop without that setup.

What is the difference between conversion tracking and WooCommerce reports?

WooCommerce reports count what was sold. Conversion tracking counts what happened before: visits, adds to cart, checkouts and payments, step by step.

Which WooCommerce analytics are free in Opti-Behavior?

The Shop screen, the purchase funnel, click heatmaps, the Smart Insights card that names the funnel step where visitors leave, and the Shop block of the e-mail report. Dedicated WooCommerce Smart Insights cards, estimated lost sales, payment errors and recordings with shop events are in Pro.

Find the step where your store loses sales

Install the free plugin, open Shop to see the products viewed but not added, then confirm the suggested purchase funnel.

Try it on your store: https://optiuser.com/blog/woocommerce-conversion-tracking/?utm_source=devto&utm_medium=referral&utm_campaign=oct26-problem-keyword&utm_content=woocommerce-conversion-tracking

Drafted with AI assistance, reviewed by the Opti-Behavior Team.

Heatmap Not Working After Installing a Cache Plugin? Here's Exactly What Breaks It

Hamdi Bk — Tue, 13 Oct 2026 10:52:28 +0000

Last verified: August 2026. Filter names and behaviours below were checked against each optimizer’s own documentation or source. Re-check before relying on them — optimizers change these between releases.

Heatmap not working after installing a cache plugin? Your heatmap page is empty. The session counter says zero. There is nothing in the browser console, no failed request in the Network tab, no warning in your dashboard. As far as every screen you can look at is concerned, nothing is wrong.

It isn’t your analytics tool. It’s your optimizer.

Cache and performance plugins rewrite, merge, defer and delay JavaScript. Tracking scripts are JavaScript. When an optimizer decides your tracker is just another file to bundle, the tracker stops executing — and because nothing errors, nothing tells you. You keep browsing your own site, the pages load faster than ever, and you lose weeks of behavioural data before you happen to open the heatmap and find it blank.

This applies to every tool in the category. Hotjar, Microsoft Clarity, Matomo, Opti-Behavior, your own custom beacon — same mechanism, same silence.

Click around a real dashboard before you install anything

A live WordPress site with real traffic, real heatmaps and real recordings. No signup, no credit card, no email.

Open the live demo →

Heatmap Not Working? The 60-Second Diagnostic

A heatmap not working right after a cache plugin install is almost always a script problem, so start here. Open your site in a private window, as a logged-out visitor, and run these three checks in order. Each one narrows the failure to a different cause.

1. Is the script in the HTML at all?

View source (Ctrl+U — not the DevTools Elements tab, which shows the DOM after JavaScript has run). Search for your tracker’s filename.

Not there → the script was never enqueued. This is not an optimizer problem. Check that the plugin is active, that you aren’t excluded from tracking as a logged-in admin, and that consent (if required) has been granted.
There, but the src points at something like /wp-content/cache/min/1/xxxx.js → your tracker was merged into a combined bundle. Go to the Minify/Combine section below.
There, but the type attribute is not text/javascript — you see type="rocketlazyloadscript", type="lazyload", data-src instead of src, or similar → the script is being delayed. Go to the Delay section.
There, with defer or async added → go to the Defer section.

2. Does the request actually leave the browser?

DevTools → Network → filter by XHR/Fetch, then click around and scroll for ten seconds. You are looking for the POST that ships events back to your site (admin-ajax.php, a REST route, or your vendor’s endpoint).

No request at all → the tracker never initialised. Confirmed script-level problem, continue below.
Request fires but returns 4xx → different problem: expired nonce or blocked REST route, usually caused by a page cache serving stale HTML rather than a JS optimizer. See “The page-cache trap”.
Request fires and returns 200 → your tracking works. Your problem is elsewhere: filtering, bot exclusion, or admin-user exclusion.

3. Is the config object defined?

In the console, type the name of the global config variable your tracker uses. Most tools localize their settings into a global (window.hj, window.clarity, window.optiBehaviorHeatmapConfig, etc.).

undefined while the script file itself is present → this is the failure almost everyone misses. The external .js file was correctly excluded from optimization, but the small inline <script> block containing its settings was not. The tracker loads, finds no configuration, and exits silently.

That third case is worth stating plainly, because it wastes more hours than the other two combined: excluding your tracker’s file is only half the job. The inline config block has to be excluded too, and it is matched by a different rule.

The four ways an optimizer kills a tracker

Delay JavaScript until user interaction

The most destructive one, and the most popular — it’s the single biggest PageSpeed win an optimizer can sell you. All non-essential JS is held back until the visitor moves the mouse, scrolls, or touches the screen.

For a tracker, that is fatal by design: everything that happens before the first interaction is exactly what you were trying to measure. Landing, above-the-fold reading time, immediate bounces, and any click that lands before the delay releases — all lost. A visitor who arrives and leaves in four seconds without touching anything is invisible.

Defer

defer moves execution to after HTML parsing. Less brutal than delay, but it inverts load order. If your tracker depends on another script (an ID broker, a consent layer, a queue stub) and only one of the two is deferred, the dependent one runs first and finds nothing.

The characteristic symptom is not empty data — it’s wrong data. A tracker whose session-ID source isn’t ready when it runs will usually fall back to minting a fresh random ID. You get one brand-new “session” per page view: inflated visitor counts, average session duration collapsing toward zero, funnels that never link two steps together. Everything looks alive, and everything is wrong.

Empty heatmaps get noticed. This doesn’t. Check for it specifically.

Minify and combine

Several JS files are concatenated into one bundle and rewritten. Trackers break here for two reasons: the rewrite can mangle the code, and the file the browser now loads has a different URL — so any exclusion rule you wrote based on the original filename no longer matches anything.

Concatenate / lazy-load / render-blocking removal

Feature names differ, mechanism is the same as the two above. Jetpack Boost concatenates. Cloudflare Rocket Loader defers everything through its own scheduler. NitroPack does the work on an external service, so no local rule can reach it.

The page-cache trap (bonus, and it’s a real one)

Full-page caches — WP Super Cache, Cache Enabler, and the page-cache half of WP Rocket or LiteSpeed — don’t touch your JavaScript at all. They cause a different failure: stale HTML with an expired security nonce.

Your tracker’s POST includes a nonce that WordPress generated when the page was rendered. If that page has been sitting in the cache for two days, the nonce is dead and the server rejects every event with a 403. Same silence, completely different cause. If diagnostic step 2 showed a 4xx, this is your problem — not JS optimization.

The same trap ruins A/B tests. A page cached while showing variant B gets served to every subsequent visitor, including the ones assigned variant A. Your test results become noise. The fix is a cache-vary cookie (below), not an exclusion rule.

Fixes, plugin by plugin

Add these to your child theme’s functions.php or a small mu-plugin. Replace your-tracker.js and yourTrackerConfig with your actual filename and inline config variable name.

If you’d rather not write code: every one of these plugins exposes the same lists in its settings UI (usually under File Optimization → Excluded files or similar). The code path is more reliable because a plugin update or a settings reset can’t quietly wipe it.

WP Rocket

// Minify/Combine JS and Defer JS — regex fragments matched against the URL.
add_filter( 'rocket_exclude_js', 'my_tracker_excludes' );
add_filter( 'rocket_exclude_defer_js', 'my_tracker_excludes' );
function my_tracker_excludes( $excluded ) {
    $excluded[] = '(.*)your-tracker\.js';
    return $excluded;
}

// Delay JavaScript execution — plain strings, matched against BOTH
// external script URLs and inline script content.
add_filter( 'rocket_delay_js_exclusions', function ( $excluded ) {
    $excluded[] = 'your-tracker.js';
    $excluded[] = 'yourTrackerConfig';  // the inline config block
    return $excluded;
} );

// Inline config blocks, for Defer and Combine separately.
add_filter( 'rocket_defer_inline_exclusions', function ( $e ) {
    $e[] = 'yourTrackerConfig';
    return $e;
} );
add_filter( 'rocket_excluded_inline_js_content', function ( $e ) {
    $e[] = 'yourTrackerConfig';
    return $e;
} );

The trap that costs people weeks: rocket_exclude_js and rocket_exclude_defer_js entries are not self-delimited regex patterns. WP Rocket joins your entries with | and wraps the whole set in its own #(...)# delimiters before matching. Write /my-tracker\.js/ with slashes, as you would for preg_match(), and those slashes become literal characters the URL must contain. A real enqueued URL ends in .js?ver=1.2.3, never in a literal /, so the pattern silently matches nothing — and you will swear you excluded the file, because you did.

Emit bare fragments. No delimiters.

LiteSpeed Cache

add_filter( 'litespeed_optimize_js_excludes', function ( $e ) {
    $e[] = 'your-tracker.js';
    return $e;
} );

// Defer exclusion — matched against inline content too, so feed both.
add_filter( 'litespeed_optm_js_defer_exc', function ( $e ) {
    $e[] = 'your-tracker.js';
    $e[] = 'yourTrackerConfig';
    return $e;
} );

SiteGround Optimizer

add_filter( 'sgo_javascript_combine_exclude', 'my_tracker_handles' );
add_filter( 'sgo_js_minify_exclude',          'my_tracker_handles' );
add_filter( 'sgo_js_async_exclude',           'my_tracker_handles' );
function my_tracker_handles( $exclude_list ) {
    $exclude_list[] = 'your-tracker-handle';  // enqueue HANDLE, not filename
    return $exclude_list;
}

add_filter( 'sgo_javascript_combine_excluded_inline_content', function ( $e ) {
    $e[] = 'yourTrackerConfig';
    return $e;
} );

The trap: all three SG Optimizer filters compare against the wp_enqueue_script handle, not the filename. Their own documentation shows $exclude_list[] = 'script-handle'. Pass your-tracker.js and the filter runs, returns cleanly, and excludes precisely nothing. This one is invisible in testing because the code looks correct.

If you don’t know your handle: search the plugin’s source for wp_enqueue_script( — it’s the first argument.

Autoptimize

add_filter( 'autoptimize_filter_js_exclude', function ( $exclude ) {
    return $exclude . ', your-tracker.js';
} );

Note the format: a comma-separated string, not an array. Returning an array here breaks the filter.

Perfmatters

foreach ( array( 'delay', 'defer', 'minify' ) as $stage ) {
    add_filter( "perfmatters_{$stage}_js_exclusions", function ( $e ) {
        $e[] = 'your-tracker.js';
        return $e;
    } );
}

WP-Optimize

add_filter( 'wp-optimize-minify-default-exclusions', function ( $e ) {
    $e[] = 'your-tracker.js';
    return $e;
} );

The trap: matched case-insensitively as a substring against the full script URL. Enqueue handles never appear in a URL, so passing a handle here silently does nothing. The mirror image of the SiteGround mistake — which is exactly why people who fix one site break the next.

W3 Total Cache

add_filter( 'w3tc_minify_js_do_tag_minification', function ( $do, $tag = '', $file = '' ) {
    if ( false !== strpos( $tag . ' ' . $file, 'your-tracker.js' ) ) {
        return false;
    }
    return $do;
}, 10, 3 );

Breeze

add_filter( 'breeze_js_dontmove', function ( $e ) {
    $e[] = 'your-tracker.js';
    return $e;
} );

Jetpack Boost

add_filter( 'js_do_concat', function ( $do_concat, $handle = '' ) {
    return ( 'your-tracker-handle' === $handle ) ? false : $do_concat;
}, 10, 2 );

Concatenation is filterable. Render-blocking/defer is not — Boost’s only documented exclusion mechanism there is the data-jetpack-boost="ignore" tag attribute. See below.

NitroPack, WP Fastest Cache, FlyingPress, Hummingbird, Swift Performance

No reliable PHP exclusion filter is publicly documented for these. NitroPack in particular optimizes on its own external service, so no local hook can intercept it. Use the settings UI, and rely on tag attributes.

The universal fallback: tag attributes

When no filter exists, mark the script tag itself. Six attributes cover most of the ecosystem:

add_filter( 'script_loader_tag', function ( $tag, $handle ) {
    if ( 'your-tracker-handle' !== $handle ) {
        return $tag;
    }
    return str_replace(
        '<script ',
        '<script nowprocket data-cfasync="false" data-noptimize="1" '
        . 'data-no-optimize="1" data-no-defer="1" data-jetpack-boost="ignore" ',
        $tag
    );
}, 10, 2 );

nowprocket — WP Rocket
data-cfasync="false" — Cloudflare Rocket Loader
data-noptimize="1" — Autoptimize, Breeze (no hyphen)
data-no-optimize="1" — LiteSpeed and others (with hyphen — yes, you need both)
data-no-defer="1" — generic
data-jetpack-boost="ignore" — Jetpack Boost

Important limitation: attributes only protect optimizations that inspect the rendered tag. Optimizations that match against the URL — WP Rocket’s minify and defer among them — never see these attributes. Attributes are a safety net, not a substitute for the filters above.

Fixing the page-cache trap

// WP Rocket: vary the page cache by a cookie your tracker sets.
add_filter( 'rocket_cache_dynamic_cookies', function ( $cookies ) {
    $cookies[] = 'my_ab_variant';
    return $cookies;
} );

// LiteSpeed equivalent.
add_filter( 'litespeed_vary_cookies', function ( $cookies ) {
    $cookies[] = 'my_ab_variant';
    return $cookies;
} );

For expired nonces on long-cached pages, the durable fix belongs in your tracker: retry once on a 403 after re-reading a fresh nonce. If you’re using a hosted tool, you can only shorten the cache lifetime.

Verify the fix properly

Before you trust any fix for a heatmap not working, verify it properly. Applying an exclusion and seeing data appear proves nothing on its own — you may simply have generated traffic while logged in, or the page you tested may not have been cached yet. Do this instead:

Purge every cache. Plugin cache, host cache (SiteGround, Kinsta, WP Engine all have their own), and Cloudflare if it’s in front.
Reload as a logged-out visitor in a private window.
View source and confirm three things: your tracker’s src points at the original file, not a /cache/min/ bundle; the type is text/javascript; the inline config block is present and unmangled.
In the console, check the config global is defined. Not undefined.
In the Network tab, confirm the event POST fires and returns 200.
Then check the dashboard — with the same date filter as your test, and with any “exclude admins” setting in mind.
Re-test on the pages that matter, not just the homepage. Checkout, product, and landing pages often have different scripts and different cache rules.
Re-test after your next optimizer update. Exclusion lists get reset by major version upgrades more often than you’d expect.

Choosing a tool? See our WordPress heatmap plugin comparison of 8 options.

You should never have had to read this

A heatmap not working for weeks with no warning is the real failure here. Every step above is diagnosis you performed because your tool stayed quiet. That’s the real defect. Not the optimizer — optimizers are doing exactly what you installed them to do. The defect is that a tracking tool can lose 100% of its data for six weeks and report nothing but an empty chart.

There’s no technical reason for that silence. The tool knows the site had traffic. It knows which of its modules are enabled. If traffic is arriving and a module’s event table stays at zero, it has everything it needs to raise its hand.

That’s the check we built into Opti-Behavior in 1.7.1. Every six hours it compares “the site received page views in the last 24 hours” against “this module recorded at least one event”, per module. If traffic is flowing and events aren’t, it shows an admin notice, names which modules went dark, and identifies the active cache or optimization plugin most likely responsible — from a list of nineteen. Sites with no traffic never alert, so a quiet site can’t trigger a false alarm. It reads nothing but COUNT(*) aggregates, adds no frontend code, and runs at most once every six hours.

Click around a real dashboard before you install anything

A live WordPress site with real traffic, real heatmaps and real recordings. No signup, no credit card, no email.

Open the live demo →

Alongside it, the exclusion rules on this page ship pre-registered for all the optimizers listed above — including the handle-versus-filename distinction that makes the SiteGround and WP-Optimize filters no-ops when you get them backwards. We had both of those backwards ourselves until July 2026. That’s how we know how invisible it is.

Opti-Behavior is a self-hosted WordPress plugin: heatmaps, funnels, session recordings, A/B testing and form analytics, with the data staying in your own database. See the plugin on WordPress.org →

Whatever you use, apply the exclusions, and then go check the last thirty days of data you assumed was being collected. Using Opti-Behavior? Run First 10 minutes: verify tracking is working, then see Cache plugin compatibility for what is handled automatically.

This article was drafted with the help of AI tools and reviewed by The Opti-Behavior Team.

Cookieless Analytics for WordPress: How Session-Based Tracking Works, and How to Prove a Plugin Sets Zero Cookie

Hamdi Bk — Sat, 05 Sep 2026 10:38:02 +0000

Every WordPress analytics plugin says "GDPR compliant" on its page. Most of them still leave a cookie. Some leave nothing in the cookie jar and hide a note in localStorage instead. A few build a fingerprint of your device.

This post explains the one design that really needs no consent banner, and shows you how to test any plugin yourself in one minute.

The cookie is the problem, not the counting

Europe's privacy rule (ePrivacy, Art. 5(3)) is simple: if you write or read something on the visitor's device, you must ask first. Counting pageviews is not the problem. Leaving a note in the browser is.

Three ways to leave a note:

a cookie (document.cookie)
other browser storage: localStorage, sessionStorage, IndexedDB
a fingerprint: nothing is written, but the script reads your screen size, fonts and browser details and mixes them into a secret ID. Privacy authorities treat this as worse than a cookie, because you can't see it or delete it.

A plugin that does none of the three can count visitors without a banner. France's privacy authority (CNIL) already allows this kind of audience measurement without consent, under conditions.

How session-based tracking works

The idea: the visitor's ID lives only in the page's memory, while the tab is open. It is never saved anywhere.

// Simplified. Runs once per page load.
const sessionId = crypto.randomUUID();     // exists only in this variable

function track(event, data = {}) {
  navigator.sendBeacon('/wp-json/analytics/v1/event', JSON.stringify({
    sid: sessionId,
    event,
    url: location.pathname,
    ref: document.referrer,
    ...data,
  }));
}

track('pageview');
addEventListener('click', e => track('click', { x: e.pageX, y: e.pageY }));

Close the tab, the ID disappears. There is nothing left to ask permission for.

On the server, WordPress writes the data into its own database. Before saving, it cuts the visitor's internet address (IP) short, so nobody can be identified:

// Simplified. IPv4: zero the last number. IPv6: keep the first 48 bits.
function ob_anonymize_ip( string $ip ): string {
    if ( filter_var( $ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4 ) ) {
        return preg_replace( '/\.\d+$/', '.0', $ip );
    }
    $bin = inet_pton( $ip );
    return inet_ntop( substr( $bin, 0, 6 ) . str_repeat( "\0", 10 ) );
}

You still know which country the visitor is from. You can't find the person.

What you lose: the plugin can't be sure that today's visitor is the same person as yesterday. It makes a good guess. For traffic, funnels and heatmaps, that's enough. For following one person over months, it isn't, and you shouldn't do that without asking anyway.

What you gain: the 35–45% of European visitors who click "Reject" are now counted. And they're not just anyone: Firefox and Brave users, people with ad blockers, developers. If your visitors are technical, cookie-based analytics is measuring the wrong crowd.

Test any plugin in 60 seconds

Open your site in a private window, press F12, and paste this in the console:

// Run before and after the analytics script loads
console.table({
  cookies: document.cookie.split(';').filter(Boolean),
  localStorage: Object.keys(localStorage),
  sessionStorage: Object.keys(sessionStorage),
});
indexedDB.databases().then(dbs => console.log('IndexedDB:', dbs.map(d => d.name)));

Then open the Network tab and look at what the plugin's script sends out. If you see scrambled navigator or canvas data leaving, that's a fingerprint.

Try it on Google Analytics, Hotjar or Clarity: you'll see _ga, _hjSession*, _clck. Try it on a real cookieless plugin: every list is empty.

Where I land

I built Opti-Behavior) on exactly this model: ID in memory only, no localStorage, no fingerprint, IP cut short before saving, everything stored in your WordPress database with no outside server, a ~15 KB script that never slows the page, robot filtering. Heatmaps and funnels are free. Session recordings (replaying one visitor) are Pro and run on a separate track, because replaying a person does need a "yes", cookies or not.

Full write-up, including what the CNIL says and why fingerprinting is a trap: How to Track WordPress Visitors Without Cookies (GDPR Compliant).

Run the 60-second test on your current setup and post what comes back. I'm collecting examples of "cookieless" plugins that aren't.

Your A/B test has three goals and they disagree. Now what?

Hamdi Bk — Sat, 01 Aug 2026 18:37:51 +0000

Every A/B testing tutorial ends the same way: run the test, wait for significance, ship the winner.

Then you run a real test and variant B converts 12% better on newsletter signups, brings in 4% less revenue per visitor, and bounce is flat. Nothing is significant except the signups. Ship it?

I spent an embarrassing amount of time on this question while building an A/B engine, and most of what I read online didn't help, because most of it assumes one metric. This post is what I ended up with. It's not novel — the statistics are decades old — but I couldn't find it written down in one place with working code, so here it is.

Why the p-value doesn't answer the question you're asking

Two problems, and the second one is the bad one.

Multiple comparisons. Three metrics at α = 0.05 means roughly a 14% chance of at least one false positive if nothing is actually different. Bonferroni fixes this, but now you need α = 0.017 per metric and your test needs to run three times as long. On a site doing 300 conversions a month that's not a fix, it's a refusal.

The p-value is answering a different question. It tells you the probability of your data assuming no difference exists. What you actually want to know is: if I ship B, how much do I expect to lose if I'm wrong? Those are not the same question and no amount of Bonferroni turns one into the other.

There's also the peeking problem — everyone checks the dashboard daily and stops when it goes green, which quietly inflates the false positive rate well past whatever α you wrote down. I'll come back to that, because Bayesian methods do not magically solve it, whatever you may have read.

Posterior first, decision second

For a conversion rate, the Beta-Binomial conjugate pair gives you the posterior in one line. With a uniform prior, after c conversions out of n visitors:

p | data ~ Beta(1 + c, 1 + n - c)

That's it. No closed-form comparison between two Betas that's worth implementing, so sample.

PHP has no Beta sampler in core, and no Gamma sampler either, so you build one. Marsaglia–Tsang, which needs a normal sampler underneath:

function normal_sample(): float {
    // Box–Muller
    $u1 = max(mt_rand() / mt_getrandmax(), 1e-12);
    $u2 = mt_rand() / mt_getrandmax();
    return sqrt(-2.0 * log($u1)) * cos(2.0 * M_PI * $u2);
}

function gamma_sample(float $shape): float {
    if ($shape < 1.0) {
        $u = max(mt_rand() / mt_getrandmax(), 1e-12);
        return gamma_sample($shape + 1.0) * pow($u, 1.0 / $shape);
    }
    $d = $shape - 1.0 / 3.0;
    $c = 1.0 / sqrt(9.0 * $d);

    while (true) {
        do {
            $x = normal_sample();
            $v = 1.0 + $c * $x;
        } while ($v <= 0.0);

        $v = $v * $v * $v;
        $u = max(mt_rand() / mt_getrandmax(), 1e-12);

        if ($u < 1.0 - 0.0331 * $x * $x * $x * $x) {
            return $d * $v;
        }
        if (log($u) < 0.5 * $x * $x + $d * (1.0 - $v + log($v))) {
            return $d * $v;
        }
    }
}

function beta_sample(float $a, float $b): float {
    $x = gamma_sample($a);
    $y = gamma_sample($b);
    return $x / ($x + $y);
}

Now the single-metric comparison:

$draws = 20000;
$wins = 0;
$loss_if_ship_b = 0.0;

for ($i = 0; $i < $draws; $i++) {
    $pA = beta_sample(1 + $cA, 1 + $nA - $cA);
    $pB = beta_sample(1 + $cB, 1 + $nB - $cB);

    if ($pB > $pA) {
        $wins++;
    }
    $loss_if_ship_b += max($pA - $pB, 0.0);
}

$prob_b_better  = $wins / $draws;
$expected_loss  = $loss_if_ship_b / $draws;

Two numbers instead of one. $prob_b_better is the intuitive one everybody quotes. $expected_loss is the one that should drive the decision: it's the average amount of conversion rate you give up, across the whole posterior, in the worlds where B is actually worse. If that number is 0.0004 and you genuinely don't care about four hundredths of a percentage point, ship B and stop thinking about it, even at 88% probability.

Pick that threshold before the test. Write it in the test config. It's the smallest effect you'd bother shipping for, and it forces a conversation about what the test is actually for.

Revenue per visitor is not a Beta

This is where I initially got it wrong. I treated revenue per visitor as a conversion-like quantity and got posteriors that were far too confident.

Revenue per visitor is zero-inflated (most visitors buy nothing) and heavy-tailed (one enterprise order distorts everything). A Beta is wrong, a Normal is wrong, a log-normal is closer but still assumes away the zeros.

I use a bootstrap instead. Resample the observed per-visitor revenue values with replacement, $draws times, take the mean of each resample. That's your posterior-ish distribution, and it inherits whatever ugly shape your real data has without you having to name it:

function bootstrap_means(array $values, int $draws): array {
    $n = count($values);
    $out = [];
    for ($d = 0; $d < $draws; $d++) {
        $sum = 0.0;
        for ($i = 0; $i < $n; $i++) {
            $sum += $values[mt_rand(0, $n - 1)];
        }
        $out[] = $sum / $n;
    }
    return $out;
}

It's O(draws × n) and it will hurt on large samples. Precompute a cumulative array and sample indices in blocks, or bootstrap on a fixed random subsample of 5,000 visitors per arm — the extra Monte Carlo noise is small compared to the sampling noise you're already living with.

Combining metrics without lying to yourself

Now the actual question. Three metrics, three posteriors, one decision.

The standard answer is an OEC — Overall Evaluation Criterion, from Kohavi's work at Microsoft. One weighted composite, agreed in advance, that the test is scored against. The two things people get wrong:

1. Weight relative uplift, not raw values. A conversion rate lives in [0,1], revenue per visitor might be €3.40, bounce rate is a percentage. Summing those with weights is meaningless. Convert each to relative uplift first, so everything is dimensionless.

2. Compute the composite inside the loop. This one matters and it's easy to miss. If you compute P(conv_B > conv_A), P(rev_B > rev_A) separately and then combine the summary numbers, you've thrown away the correlation between metrics. The draws are paired: draw i represents one coherent hypothetical world. Score the composite in that world, then aggregate.

$draws  = 20000;
$w      = ['conv' => 0.5, 'rev' => 0.4, 'bounce' => 0.1]; // must sum to 1
$rev_A  = bootstrap_means($revenue_A, $draws);
$rev_B  = bootstrap_means($revenue_B, $draws);

$oec_positive = 0;
$oec_loss     = 0.0;

for ($i = 0; $i < $draws; $i++) {
    $pA = beta_sample(1 + $cA, 1 + $nA - $cA);
    $pB = beta_sample(1 + $cB, 1 + $nB - $cB);
    $bA = beta_sample(1 + $bounceA, 1 + $nA - $bounceA);
    $bB = beta_sample(1 + $bounceB, 1 + $nB - $bounceB);

    $u_conv   =  ($pB - $pA) / $pA;
    $u_rev    =  ($rev_B[$i] - $rev_A[$i]) / $rev_A[$i];
    $u_bounce = -(($bB - $bA) / $bA);   // lower bounce is better, so flip

    $oec = $w['conv'] * $u_conv
         + $w['rev']  * $u_rev
         + $w['bounce'] * $u_bounce;

    if ($oec > 0) {
        $oec_positive++;
    }
    $oec_loss += max(-$oec, 0.0);
}

$prob_b_better  = $oec_positive / $draws;
$expected_loss  = $oec_loss / $draws;  // in relative-uplift units

Ship B when $expected_loss is below your threshold of caring. Not when $prob_b_better crosses 95%.

Fix the weights before you look at any data. Otherwise you will — I promise you will — nudge them until your preferred variant wins. If you can't decide the weights before the test, you don't have a hypothesis, you have a hope.

Guardrails are not goals

Some metrics don't belong in the composite at all. Page load time, JS error rate, checkout failures — these are guardrails, and no amount of signup uplift should be allowed to buy a regression in them.

They get a veto, not a weight:

if ($p95_load_B > $p95_load_A * 1.10) {
    return Decision::BLOCKED;   // no composite, no discussion
}

Mixing a guardrail into the OEC is how you ship a variant that converts 8% better and breaks checkout for Safari.

The peeking problem is still there

You will read that Bayesian methods let you monitor continuously without penalty. That's half true and the half that's false will burn you.

Expected loss is a decision-theoretic quantity, so stopping when it falls under your threshold isn't the same statistical sin as stopping when a p-value dips below 0.05. But with tiny samples the posterior is wide and jumpy, and "expected loss happens to be low right now" is a thing that occurs by chance early in a test.

The pragmatic fix I settled on: a hard minimum before any decision is offered at all. Both arms need a floor of visitors and a floor of conversions — conversions are what actually carry the information, and 50,000 visitors with 11 conversions tells you almost nothing. Below the floor the UI shows the posterior and refuses to say anything else.

Not elegant. Works.

Performance, since this runs on shared hosting

20,000 draws × 4 Beta samples × 2 arms is a lot of mt_rand() calls in PHP, and it is nowhere near free on a €4/month host.

What made it survivable:

Run it on a scheduled job, not on dashboard load. Cache the decision payload.
Aggregate counts ($nA, $cA, …) in a summary table updated incrementally. Never scan the raw events table to compute a posterior.
Drop to 10,000 draws. The Monte Carlo error on $prob_b_better at 10k draws is about ±0.5 percentage points, which is invisible next to the uncertainty in your data.
Bail out early when the result isn't close. If the two 99% intervals don't overlap, you don't need the simulation.

On my setup, the full three-metric run at 20k draws takes [X] ms for [N] visitors per arm, down from [Y] ms before the summary table. Replace these with your real numbers or delete the paragraph — made-up benchmarks are worse than no benchmarks.

What I'd tell past me

The statistics were the easy part. The hard part was accepting that "which variant won?" is a badly formed question, and that the honest output of an A/B test is a distribution plus a decision rule you committed to in advance — not a green checkmark.

The engine got simpler once I stopped trying to produce certainty and started producing an expected cost of being wrong.

I'm the author of Opti-Behavior, a self-hosted analytics plugin, and the decision engine described here is what's running inside its A/B testing module — so take my enthusiasm for this approach with the appropriate grain of salt. The maths is standard and framework-agnostic; port it wherever you like. Happy to argue about the weighting scheme in the comments, it's the part I'm least sure about.