WooCommerce conversion tracking: why it breaks and how to test it
In short
Missing WooCommerce purchase events can come from blocked scripts, payment redirects, checkout incompatibility, duplicate events or consent settings. Compare order records with received events before comparing attributed conversions. Server-side capture reduces dependence on the browser, but still needs correct hooks, consent handling, deduplication and delivery checks.
Why WooCommerce underreports conversions
Check these common failure points. They concern different parts of the system, so moving one request to the server will not resolve all of them.
- The pixel is blocked. Content blockers and tracking protection in Safari and
Firefox stop the request before it leaves. The order completes; the event never does.
- The thank-you page is skipped. Payment gateways that redirect back
asynchronously, or customers who close the tab once the bank confirms, never load the page the conversion script lives on. The order is in your database regardless.
- A plugin broke the event. WooCommerce checkout is a plugin surface. Anything
touching the order flow can suppress the script or change the DOM it reads from, and nothing warns you.
- The Block checkout is not the classic checkout. Trackers written against
woocommerce_checkout_create_order fire on the classic flow and silently do not fire on the Block one, which is now the default on new installs.
- Consent settings limit collection. Check which categories were granted and how each tag responds. A correctly blocked advertising event is not a tracking defect.
Test the implementation before choosing a fix. Browser restrictions, checkout hooks and consent rules need separate checks.
How to tell which one is hitting you
Use a staging checkout or test transactions in the existing checkout. Do not switch the live store between checkout types just to compare counts.
- Define the order set. Choose a completed observation window, time zone, payment and refund treatment. Processing and completed statuses are useful filters, but custom gateways and refunds still need reconciliation.
- Inspect received purchase events. Check browser and server events, order identifiers, event identifiers, timestamps and deduplication. Events Manager receipt is different from ad attribution.
- Compare attributed purchases separately. Match reporting dates, attribution windows and conversion definitions before interpreting the gap.
| Observation | What to investigate |
|---|---|
| Fewer received events than eligible orders | Consent exclusions, blockers, checkout hooks, delivery errors or late events |
| More received events than eligible orders | Duplicate firing, refreshes, retry handling or mismatched event definitions |
| Received events reconcile, attributed purchases differ | Attribution settings, reporting dates, modelled results and channel overlap |
These are diagnostic leads, not unique diagnoses. Reproduce the path with a test order and follow its identifier from the store to each destination. WooCommerce documents which classic checkout hooks do not work with Blocks.
What moving capture to the server actually fixes
In the local plugin source reviewed on 24 September 2026, landing-touchpoint capture runs on template_redirect at priority 5. This is a visit-capture hook, not a payment confirmation. The loyalz_tp cookie holds at most 20 touchpoints with a 90-day retention limit. It is HttpOnly and SameSite=Lax; the Secure flag depends on HTTPS. This source review does not verify every deployed store's configuration.
What gets recorded per touchpoint: the ad id, the five utm parameters, and the four click identifiers gclid, fbclid, ttclid and msclkid, plus referrer, landing URL and an ISO-8601 UTC timestamp.
A visit carrying none of those is not discarded. derive_channel() classifies it from the referrer into direct, organic or referral, so those channels appear in the path instead of being invisible — and returns null for same-host referrers, so internal navigation does not spawn a touchpoint on every page view.
The plugin attaches the chain to the order through woocommerce_checkout_create_order for classic checkout and woocommerce_store_api_checkout_order_processed for Blocks. Test both paths used by your store. An order-processing hook does not by itself establish that payment succeeded; purchase reporting must apply the agreed payment-status rules.
The first-visit gap caused by consent timing
A first-visit timing gap can remain even when the server-side hooks are correct.
On the very first visit from an ad, the consent cookie does not exist yet. The banner has not been answered. Server-side capture runs on template_redirect, checks consent, finds none, and correctly skips — and by the time the visitor accepts, the request carrying the utm parameters is over.
Without another capture after acceptance, the initial campaign parameters can be lost when the customer leaves the landing page.
After consent is accepted, a browser listener can submit the landing parameters to an endpoint that checks consent again. The reviewed plugin uses loyalz_tp_capture. Test acceptance on the landing page, navigation before acceptance and withdrawal. Cached pages or a failed listener can still prevent capture.
What none of this fixes
Server-side delivery does not remove consent obligations or establish that every order came from an ad. The plugin's default touchpoint gate reads CookieYes advertising consent; configurable consent sources and the newsletter-conversion path need separate review.
An operational order record and an advertising touchpoint serve different purposes. Google also distinguishes basic and advanced Consent Mode. See the consent guide before treating every difference as missing tracking.
The reviewed cookie chain is limited to 20 entries and 90 days. Browser deletion, device changes and missing consent can shorten the observed path. Do not treat the recorded path as a complete customer history.
For related checks, see WooCommerce measurement, ad measurement and Loyalz acquisition measurement.
Common questions
Why does my WooCommerce store show fewer conversions than Meta?
First separate received events from attributed conversions. Compare the same order definition, dates and time zone, then inspect missing events, duplicates and attribution settings. A difference in totals alone does not identify the cause.
Do I need the Conversions API or server-side tracking?
They are related but not the same thing. The Conversions API is one destination you can send server-side events to. Server-side capture is recording the event on your own infrastructure in the first place. Do the second first: without it, the Conversions API has nothing reliable to send.
Does the WooCommerce Block checkout break conversion tracking?
A tracker relying only on a classic checkout hook may miss the Blocks path. Check the hooks your integration uses and make a test purchase in the checkout actually deployed. Order creation and confirmed payment are separate events.
Can I track conversions without consent?
Separate necessary order processing from advertising measurement. Respect the consent and legal requirements for each purpose; sending data from a server does not waive them. Basic and advanced Consent Mode also handle denied states differently.
How long is a touchpoint kept?
In our plugin, ninety days and at most twenty touchpoints per visitor. Those are limits, not guarantees: a purchase cycle longer than ninety days loses its earliest touches, and a path longer than twenty entries drops its oldest ones.
See it on your data
On a twenty-minute call we connect one ad account and one month of your orders, and work out the gap between what the platform claims and what your shop took. Profit and POAS stay blank until you enter your margin and costs per order.
Book a demo