A store running WooCommerce with a bank transfer or cash-on-delivery gateway enabled sends every customer who places that kind of order straight to the order-received page, the moment the order is created. No payment has been captured yet. WooCommerce's own woocommerce_thankyou hook fires on that page load regardless, and most analytics integrations listen for exactly that hook to send GA4 and Meta their purchase event. A GitHub issue filed against WooCommerce's own official Google Analytics integration plugin documents the resulting failure mode directly: the purchase event fired for orders that later ended up failed or cancelled, because the integration was reading a page load, not a payment confirmation.
That is the gap a standard WooCommerce audit checklist cannot catch, because it was never built to look there. Search "woocommerce audit checklist" and the results cluster around the same playbook every time: page speed, PHP version, SSL, plugin bloat, mobile tap targets, Yoast or Rank Math SEO settings. Useful work, worth doing. None of it touches whether the revenue number a dashboard reports is actually real.
Why the standard checklist never gets there
Public WooCommerce audit checklists are written by and for a different audience: performance consultants and WordPress agencies optimizing Core Web Vitals, plugin conflicts, and page experience. That's a legitimate, separate discipline, and it's why checklist after checklist repeats the same speed and SEO items instead of asking whether the order count GA4 reports for last month matches what WooCommerce's own order export says shipped.
WooCommerce reports 7 million-plus active installations on its WordPress.org plugin page, and the ecosystem built around that install base runs almost entirely on third-party plugins for analytics, currency, and consent, each one a separate place a conversion event can be read, duplicated, or dropped. A speed-and-SEO checklist has no reason to open that question. A measurement-first audit has no other job.
The checklist a measurement-first WooCommerce audit actually runs
1. Check what event the tracking plugin actually listens for
Find out whether your GA4 or Meta integration fires on page load (woocommerce_thankyou) or on a confirmed order status change. Newer releases of GTM4WP, one of the most widely used GTM integrations for WooCommerce, added a setting that lets you choose which order statuses trigger the purchase event, typically Processing, On Hold, and Completed by default, with Pending no longer tracked automatically. If your plugin predates that option or has it misconfigured, you are very likely sending purchase events for orders that never got paid.
2. Reconcile WooCommerce's order export against what GA4, Meta, and Google Ads reported
Pull a fixed date range from WooCommerce's own order export and compare total revenue against what GA4, Meta, and Google Ads each reported as purchase revenue for the identical window. Any platform more than a few percent off needs an explanation, not a shrug. This single check, the same reconciliation discipline behind a GA4 and Shopify revenue mismatch audit, is the step every free checker skips because it requires pulling real order data, not just confirming a tag fired.
3. Confirm your tracking plugin actually reads HPOS, not just declares it
WooCommerce has run High-Performance Order Storage as the default for new stores since version 8.2, storing orders in dedicated tables instead of wp_posts. A plugin can declare HPOS compatibility in its own header while still calling legacy functions like get_post_meta() under the hood. That combination doesn't throw an error. It quietly returns empty or zero-value order data, so GA4 and Meta keep receiving purchase events with the wrong value, or none at all, with nothing in the WooCommerce admin flagging it.
4. Audit what currency and payment gateway plugins send versus what the customer paid
If the store runs a multi-currency plugin or offers region-specific gateways, confirm the value and currency parameters a tag sends match what the customer was actually charged, not the store's base currency. A mismatch here inflates or deflates every reported revenue number by the conversion spread, invisibly, the same blind spot the GTM container audit catches when a variable is reading a stale or wrong data layer value.
5. Verify the checkout block migration didn't silently break an older tag
Stores that migrated from the classic shortcode checkout to WooCommerce's block-based cart and checkout changed the DOM and event structure those pages render. A tracking plugin or custom script that depended on a specific element selector or a page-level script tag on the old checkout can look installed and fire nothing on the new one. Confirm begin_checkout, add_payment_info, and purchase events still populate correctly after any checkout block update, the same question a GA4 datalayer audit asks of any ecommerce event layer after a front-end change.
6. Check what the consent plugin is actually blocking
A consent management plugin, whether that's Complianz, CookieYes, or another, sits in front of every tag on this list. If it's scoped incorrectly, it can block analytics and ad tags for visitors it shouldn't, or let them fire for visitors who never consented, and neither failure shows up as an error in the WordPress admin. Test the plugin's accept and reject paths from more than one region before trusting it, the same verification a Google Consent Mode v2 rollout requires on any platform.
7. Confirm key events are labeled correctly, not just present
A tracking plugin dashboard showing "Purchase: Active" tells you an event exists, not that it's mapped correctly. Open GA4's DebugView or a tag inspector and confirm the purchase event actually carries the order ID, value, and currency fields your reporting depends on, rather than firing with a generic or hardcoded value left over from a plugin's default configuration.
8. Re-check after any plugin, theme, or WooCommerce core update
WooCommerce ships frequent core releases, and tracking, currency, and consent plugins update on their own schedules, often independently of each other. A tracking audit done in January on a store that updated four tracking-adjacent plugins since is auditing a different setup than the one actually running today. Re-run the reconciliation in step 2 after any update that touches checkout, payments, or a plugin with tracking permissions, not on a fixed annual calendar.
One number to check before you trust any WooCommerce dashboard
Pull WooCommerce's order export for the last 30 days and compare total revenue against what GA4 reports as purchase revenue for the same window. That single percentage gap tells you more about whether your numbers can be trusted than any speed score or plugin count ever will. A small, explainable gap, from timezone differences or a known excluded order status, is normal. A gap you can't explain, or one that's grown since the last time you checked, is the signal to stop guessing.
If that gap shows up and nobody on the team can say with confidence which plugin owns the purchase event, a fixed-scope WooCommerce tracking audit reconciles every tag source against the order data directly, starting at $500 and delivered in one to two days, with the fee credited toward implementation if you move forward within 60 days. For a broader look across tracking, CRO, paid media, and reporting together, the full ecommerce audit service scopes all four in one fixed-price engagement on the same terms.
