Tracking & attribution
The pixel that wasn't firing
Our own store's conversion tracking looked healthy and was silently broken. Finding out why changed how we build tracking for everyone.
Published 24 August 2026
100%of purchases recovered into reporting
Context
Floreva is a skincare brand we own and operate, a live WooCommerce store taking real orders, and its Meta pixel was under-reporting purchases. Page views and product views came through normally, but purchase counts in Meta never matched the orders actually landing in WooCommerce, and the gap was wide enough to make ad spend impossible to judge.
The constraint
Nothing threw an error. The pixel was installed correctly, the events were configured correctly, and the testing tools said everything was fine. A silent failure with no error message is the hardest kind to chase, and every day it continued, budget decisions were running on numbers that were wrong.
What we built
- Traced the failure to LiteSpeed Cache's JavaScript-delay optimisation: it defers scripts until the user interacts, and on an order-confirmation page many buyers never interact before leaving. The browser-side pixel simply never ran.
- Rebuilt purchase tracking server-side with Meta's Conversions API, so the purchase event fires from the server the moment the order is written, independent of the browser entirely.
- Hashed customer email and phone before transmission, so Meta can match and attribute without ever receiving raw personal data.
- Added matched event IDs across the browser and server events so the two deduplicate instead of double-counting.
The result
Rebuilding purchase tracking server-side with Meta's Conversions API recovered 100% of purchases into reporting, conversions now reconcile against the actual WooCommerce order table, and ad decisions run on real numbers.
What we'd do differently
Check the caching layer before the tracking code. We lost time assuming the bug was in our implementation when it lived in a performance plugin three layers away; a cache-and-defer audit is now the first step of every tracking job we take on.
Why this matters for you: Nearly every WordPress store runs a caching plugin with some form of JavaScript deferral, and a large share of them have a version of this problem without knowing it: it never produces an error, just quietly wrong numbers.