5 campaigns optimizing blind: a Meta Pixel and CAPI audit at StickDecor

StickDecor is a home decor e-commerce store with over 500 active products and live Meta Ads campaigns. The request was direct: audit the Pixel and Conversions API setup, because the Events Manager numbers were not matching the reality of the store.

The symptom

Top-of-funnel events — PageView and ViewContent — were still coming through normally, in the thousands. The events that actually matter for sales were not: Search, AddToCart, InitiateCheckout and Purchase were essentially at zero. Five active ad sets were optimizing for exactly those events. In other words: Meta was spending budget trying to find buyers without receiving a single purchase signal.

That is worse than a bad campaign. A bad campaign delivers bad data. A campaign with no conversion event delivers no data at all, and the algorithm starts optimizing blind.

The diagnosis

The answer was in the Meta for WooCommerce plugin's own log: the access token dropped on July 10, 2026, at 03:34. From that moment on, every event traveling through the Conversions API stopped being delivered. The "access token is missing" error repeated every five minutes in the log, silently, for 17 days.

The Business Manager account also had noise: more than one pixel registered, including obsolete pixels and one belonging to a different client. We confirmed which pixel was the store's legitimate one before touching any configuration — reconnecting to the wrong pixel would have felt like a fix while keeping the problem alive.

The real root cause

The token did not drop on its own. The client uses a separate product feed plugin to populate the Meta catalog, and the official plugin was duplicating that submission, creating a catalog conflict. To resolve the conflict, he disconnected the official plugin — which fixed the catalog and took tracking down with it, as a non-obvious side effect.

Catalog and tracking live inside the same plugin, but they are independent functions. Turning one off to fix the other is a trap that gives no warning.

The fix was to reconnect the plugin keeping only tracking active and specifically disabling catalog synchronization. None of the store products were modified in the process.

The event that never existed

The audit found a second, older problem: the Lead event had never fired. This was not a recent break — it was total absence since the original pixel installation.

The reason is that the store's signup forms run on an external platform embedded in the page, with no native visibility to Meta. The most common workaround would be to request access to that platform's account and configure it there, creating a dependency on yet another client credential.

We solved it on the site side: the forms platform exposes a global "submission complete" event when embedded in that mode. We built a snippet that waits for the script to load, listens for that event — which only fires on a successfully validated submission, never on a validation error — and then fires Lead on the correct pixel. Confirmed end to end in the Events Manager.

What else the audit covered

Review of the account's five custom conversions: two were tied to an old pixel with no activity for over 600 days — candidates for archiving. A third had stopped exactly on the date the token broke, confirming the diagnosis through a second independent path.

Domain verification, mapping of active campaigns against the optimization event in use, and the final documented report with the root cause timeline were also included.

What ships working

Pixel reconnected to the Conversions API with the correct token. Catalog protected, with no duplicate synchronization against the client feed. Lead event implemented and confirmed — something that had never existed since the original install. Domain verified, campaigns mapped and custom conversions reviewed.

Stack

WordPress · WooCommerce · Meta Pixel · Meta Conversions API · WP-CLI over SSH · Hostinger