Shopify customer events / custom pixels not firing.

“Pixel,” “event,” and “not firing” show up in three different problems. This page is only when Shopify Settings → Customer events custom pixels (or app web pixels via the Web Pixels API) do not emit storefront or checkout events. Meta Conversions API / server-side Purchase or AddToCart missing in Events Manager is meta-capi-events-missing. Klaviyo / Google / Meta add-to-cart, begin-checkout, or purchase missing or double-firing after pixels are already installed is add-to-cart-tracking. Admin / app HTTPS webhooks failing HMAC or retries is shopify-webhooks-not-delivering. Cookie banners that block checkout UX are cookie-banner-blocking-checkout.

Open Admin → Settings → Customer events and a clean storefront tab for the same published theme. Capture five proofs before you blame “Meta ads” or “Klaviyo flows”:

1. Pixel surface: is this a Custom pixel in Customer events, an app web pixel, or an old theme additional_scripts / checkout liquid snippet? Status Connected vs Draft vs Disconnected?
2. Sandbox: open the custom pixel editor → Run / sandbox — any red console errors, undefined analytics, or failed network calls on page_viewed?
3. Consent: Customer Privacy / consent banner — did this session grant analytics / marketing? Region with mandatory consent where pixels stay idle until accept?
4. Subscribe names: does the pixel use current Web Pixels API event names (product_added_to_cart, checkout_started, checkout_completed, etc.) — not legacy theme liquid hook names?
5. Checkout scope: are checkout / thank-you / order-status events expected from a custom pixel that only runs on Online Store, or do you need a pixel with checkout permissions / app pixel that covers checkout extensibility?

If you only tested Meta CAPI Test Events, Klaviyo ATC double-fire, or Admin webhook delivery logs, you are on the wrong playbook.

Custom pixels only run when status is Connected on the live store. A Draft pixel, a pixel that failed Connect after a code paste, or an app pixel that was uninstalled and re-added without reconnecting will look like “events not firing” forever. Open Customer events → your pixel → confirm Connected, then use the built-in sandbox / test mode. Fix any syntax error, forbidden DOM access outside the sandbox rules, or calls to APIs that custom pixels cannot reach. Theme editor preview with a pixel “working” in one staff session is not proof a consent-denied visitor fires events.

App web pixels (installed apps) fail differently: permissions revoked, app uninstalled from the sales channel, or the app still using deprecated pixel APIs. Check the app’s pixel health UI and Customer events list for Disconnected / Error badges before rewriting your custom pixel.

Shopify Customer Privacy (and many consent apps) gate Web Pixels until the visitor grants analytics and/or marketing. In regions with strict consent, a custom pixel that never checks init.data.customerPrivacy / consent APIs — or that fires before consent — will appear dead in your network tab while staff who already accepted cookies see events. Retest in a fresh incognito window: decline vs accept, and confirm your pixel respects the granted purposes. A consent banner that blocks the checkout button is a different UX bug (cookie-banner-blocking-checkout); stay here when the banner works but pixels stay silent after decline / before accept.

Also check that you are not mixing “always collect” store settings with a custom pixel that still waits for marketing consent — or the reverse. Align Admin Customer Privacy settings, the banner app, and the pixel’s consent checks, then retest once with a clean cookie jar.

Custom pixels subscribe with the Web Pixels API — typically analytics.subscribe('event_name', …). Wrong or legacy names (theme liquid hooks, gtag-only assumptions, typos like add_to_cart instead of product_added_to_cart) mean the handler never runs even when the pixel is Connected. Prefer Shopify’s standard customer event names, log the event payload in sandbox, then mirror that into your tag / pixel endpoint.

Checkout and thank-you / order status are a separate scope: some events only fire on checkout surfaces, and custom pixels may not see every checkout event depending on permissions and checkout extensibility. If storefront page_viewed works but checkout_completed never appears, prove whether your pixel is allowed on checkout, whether you need an app pixel with checkout coverage, and whether you confused this with thank-you Additional scripts / UI extensions ( related: thank-you upsell and order-status blank playbooks). Do not treat Meta CAPI server dedupe as a substitute for a dead Shopify customer event.

Wrong playbook waste is common here:

• Meta Conversions API / CAPI Purchase or AddToCart missing in Events Manager → meta-capi-events-missing
• Add-to-cart / begin-checkout / purchase missing or double-firing in Klaviyo, Google, or Meta after pixels → add-to-cart-tracking
• Shopify Admin / app webhooks not delivering (HMAC, HTTPS, retries) → shopify-webhooks-not-delivering
• Cookie consent banner blocking add-to-cart or checkout UX → cookie-banner-blocking-checkout
• GA4 purchase event missing (measurement vs customer events plumbing) → ga4-purchase-event-missing

Stay here only when Shopify Customer events custom pixels or app web pixels should fire on the live storefront / checkout — and do not.

Stay DIY if you can spend one afternoon on the list above: prove Connected vs Draft, sandbox console, Customer Privacy consent, Web Pixels API subscribe names, checkout pixel scope, and stop confusing Meta CAPI / ATC double-fire / Admin webhooks with this customer-events path. That is the whole playbook. No agency required. Short answers also live on the merchant FAQ. Related pages: Meta CAPI missing, add-to-cart tracking, webhooks not delivering, GA4 purchase missing.

Pay for help when the work is not flipping one pixel toggle — it is connecting the stack you already have so lead capture is not dying in a broken events path, checkout and ops exceptions land in a channel you already check, and the live store is one workflow instead of a spreadsheet plus a Slack bot you forgot. That is the Latch AI Ops install.

What $997 USD one-time buys: lead capture on the live store, ops alerts in a channel you already check, and a checkout-ready workflow. 72 hours after collaborator access, not after payment. One live Shopify store. Access plus a delivery thread. Store URL collected at checkout. Not a SaaS seat, not a theme agency retainer, not a conversion guarantee, not a brand or theme job.

Other shops' public ranges, not testimonials: a checkout / ops install typically runs $500–$2,500. A full ops consulting block typically runs $2,000–$5,000. $997 is the cheap end of that work, sold as a 72-hour install of three systems — not as an earnings number or conversion-lift claim.

What it does not buy: more orders, recovered revenue, a forever pixel-fire guarantee, a custom theme rewrite retainer, or a case study. Latch AI Ops has not published customer proof because there are no customers yet. You are buying the install.

Checkout is on Whop. Operator is Nico. United States offer. You can revoke collaborator access after handoff. We do not take owner passwords.