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.

100%of purchases recovered into reporting

Context

Floreva is our own skincare brand, a live WooCommerce store taking real orders. Its Meta pixel reported page views and product views normally, so the setup looked fine. But purchase numbers in Meta never lined up with the orders actually landing in WooCommerce, and the gap was wide enough to make ad spend impossible to judge.

The constraint

Nothing was throwing an error. The pixel was installed correctly, the events were configured correctly, and testing tools said it was fine. A silent failure with no error message is the hardest kind to chase, and every day it continued we were making budget decisions on numbers that were wrong.

What we built

Traced the failure to LiteSpeed Cache's JavaScript-delay optimisation. It defers scripts until user interaction, and on the order-confirmation page many visitors never interact before leaving. The browser-side pixel simply never ran.
Rebuilt purchase tracking server-side using Meta's Conversions API, so the event fires from the server the moment the order is written, independent of the browser entirely.
Hashed customer email and phone before transmission for privacy-safe matching, so Meta can attribute without receiving raw personal data.
Added matched event IDs across the browser and server events so the two deduplicate instead of double-counting.

The result

Purchase events stopped depending on whether a customer's browser cooperated. Reported conversions reconciled against the actual order table, which meant ad decisions could finally be made on real numbers.

What we'd do differently

We'd check the caching layer first, before the tracking code. We lost time assuming the bug was in our implementation when it was in a performance plugin three layers away. Now a cache-and-defer audit is the first step of any tracking job we take on.

Why this matters for you: Nearly every WordPress store runs a caching plugin with some form of JavaScript deferral. A large share of them have a version of this problem and no idea, because it never produces an error, just quietly wrong numbers.