WooCommerce 10.6 shipped March 10, 2026 with Cart and Checkout Block enhancements that accelerated migration off the legacy [woocommerce_checkout] shortcode. Pixel plugins still listening on the old jQuery hooks — added_to_cart, woocommerce_checkout_init — stopped firing AddToCart and InitiateCheckout the moment the migration completed.

The Purchase event keeps firing because the woocommerce_thankyou PHP hook still works. Revenue still tracks. But the funnel above it went silent — and Smart Bidding is now optimising against an audience that, as far as the pixel knows, never added anything to a cart.

What WooCommerce 10.6 Actually Changed

WooCommerce 10.6 (WooCommerce Developer Blog, March 10 2026) shipped a wave of UX polish on the Cart and Checkout Blocks: a trash icon for line removal, a price savings badge, cleaner spacing. None of that breaks tracking by itself. The breakage is older than the polish — it’s the architectural shift the Blocks introduced when they replaced the shortcode in the first place. The 10.6 release just made the Blocks nice enough that the holdouts finally migrated.

The legacy checkout used [woocommerce_checkout] as a PHP shortcode. It rendered server-side templates and fired client-side events through jQuery — added_to_cart when you clicked add-to-cart, updated_cart_totals on every cart change, woocommerce_checkout_init when the form mounted. Pixel plugins built for this era — older PixelYourSite versions, custom theme injection, half the GTM data-layer tutorials still indexed on Google — listened on those exact events.

The Cart and Checkout Blocks (woocommerce/cart and woocommerce/checkout) don’t fire any of them.

The Blocks are React components that read state from the @wordpress/data store and mutate the cart through the WooCommerce Store API at /wp-json/wc/store/v1. No jQuery. No legacy events. The user adds something to the cart, the Store API endpoint returns the new state, the React tree re-renders. Your pixel plugin’s jQuery(document.body).on('added_to_cart') listener never sees it.

Why GA4 Won’t Tell You

This is the part that turns a tracking gap into a strategic problem. Your GA4 dashboard still looks fine. Sessions count. Page views fire on every product and cart page. Revenue still attributes correctly because the Purchase event runs on the order-received page from the woocommerce_thankyou PHP hook — which fires regardless of whether the customer checked out through the shortcode, the Block, or by submitting a form to /wp-json/wc/store/v1/checkout directly.

What goes silent is the middle. AddToCart. InitiateCheckout. ViewContent on cart pages. The events that feed Smart Bidding’s audience signals.

The WordPress.org Facebook for WooCommerce support thread from the official plugin team makes the dependency explicit: the checkout page must contain either the [woocommerce_checkout] shortcode or the WooCommerce Checkout Block — those elements are necessary for the Purchase event to be registered. Read it again. The official guidance distinguishes shortcode from Block as two different code paths the plugin has to handle separately. If your pixel plugin only handles one, you’ve already lost half the funnel.

The 5-Minute Diagnostic

You don’t need to read code. You need a private window and consent denied. Here’s the walk:

1. Open a private/incognito window with no extensions and no logged-in session.
2. Click reject on your consent banner so it doesn’t gate the events.
3. Open DevTools → Network and filter by fbevents (Meta), collect (GA4), or googleadservices (Google Ads).
4. Walk the funnel manually: view a product page → click add-to-cart → view the cart → start checkout → place a test order.
5. Count the events at each step. If you see PageView on every page but no AddToCart when you click the button, no InitiateCheckout when you start checkout, and only Purchase at the end — your pixel is missing the Block events.

This is the diagnostic the 15-minute WooCommerce pixel audit hinges on. It works because the pixel either fires or it doesn’t, and the network tab is the only place that won’t lie to you.

Why Patching Plugins Is Not the Answer

The first reflex is to update PixelYourSite, switch the detection method, or wire your GTM data layer to the Store API responses. That works until the next WooCommerce update. Roughly 70% of WooCommerce stores already have broken tracking on a regular cadence, and theme-template-based pixel injection has been the breakage point since GTM launched in 2012 (WooCommerce Tracking Breaks on Updates: The Fix).

Even PixelYourSite’s own documentation hints at the pattern. The general settings page tells merchants to switch the method used to detect adds — using WooCommerce hooks as the fallback — whenever themes or plugins replace default add-to-cart behaviour. That’s documentation-speak for: every theme and every checkout migration breaks the detection layer, and we keep adding fallback hooks.

The pattern repeats. Theme updates. WooCommerce Block updates. jQuery deprecation. Payment-method plugins replacing the Add-to-Cart button with their own component. Each one breaks a different listener. Meta’s Conversions API can recover 20-30% more conversion data than pixel-only — but only if the events fire in the first place. The Block migration breaks the upstream signal before CAPI ever gets a chance to catch it.

Translation: you’re not fixing tracking. You’re maintaining tracking. Every release, forever.

The Hook That Still Fires

There is one hook that didn’t change. woocommerce_thankyou is a PHP action that fires on the order-received page after payment is processed — regardless of whether checkout ran through the shortcode, the Block, the Store API directly, the Stripe Agentic Commerce Suite, or a future WordPress 7.0 ability invocation. The order goes through the same WooCommerce order pipeline, and the same hook fires at the same point.

Bind your tracking to that hook — on the server, in PHP, before the browser is involved — and the Block migration becomes irrelevant. So does the next checkout architecture. So does the one after that.

The question isn’t which pixel plugin you should buy. The question is whether you should be buying pixel plugins at all.

How Seresa Captures Block Funnels

Transmute Engine™ is a first-party Node.js server that runs on your subdomain (for example, data.yourstore.com). The inPIPE WordPress plugin hooks into the WooCommerce action layer — woocommerce_add_to_cart, woocommerce_checkout_order_processed, woocommerce_thankyou — captures the event in PHP, batches it, and sends it via API to the Transmute Engine server, which routes simultaneously to GA4, Meta CAPI, Google Ads Enhanced Conversions, and BigQuery. Whether your store ran the shortcode yesterday, the Block today, or the next checkout architecture tomorrow, the same PHP hooks fire and the same events reach your platforms.

Key Takeaways

• WooCommerce 10.6 (March 10, 2026) accelerated migration to Cart and Checkout Blocks. The Blocks use the @wordpress/data store and Store API — not the legacy jQuery events pixel plugins were built for.
• The Purchase event still fires from woocommerce_thankyou in PHP. AddToCart and InitiateCheckout often don’t. Revenue keeps tracking; the funnel above it goes silent.
• Smart Bidding optimises against the broken signal. An audience the pixel never sees adding to cart is, to Google’s algorithm, an audience that doesn’t add to cart. Bid pacing reflects that.
• The diagnostic is consent-denied + DevTools network tab. Walk the funnel and count fbevents, collect, and googleadservices calls at each step. Missing AddToCart with present Purchase is the signature.
• Server-side capture at the WooCommerce hook layer is the only fix that survives the next checkout architecture. The PHP hooks fire regardless of which checkout UI rendered them.

FAQ

Pixel plugins maintain. Server-side hooks fire. See how Transmute Engine binds to WooCommerce hooks once and tracks every checkout architecture from now on.