Guide

Shopify Tracking Debugging Guide

By Comercio Services Tracking Team · August 7, 2026 · 9 min read

Shopify tracking bugs cluster in five places: the theme, conflicting apps, Shopify's checkout sandbox, the order webhook feeding server-side purchase events, and consent apps gating the pixel script. Debug them in that order — theme, apps, checkout, webhook, consent — because each one rules out a whole class of causes before you move to the next, and it's the fastest path to the actual fault instead of guessing.

Most "OpenAI Ads isn't tracking my Shopify store" reports aren't one bug. They're five different failure modes that happen to produce the same symptom: events missing, or numbers that don't match reality. Below is the order that finds the real cause fastest, plus what to do once you've found it.

The 10-minute triage: where exactly do events stop?

Before touching any code, run one test order and note precisely where events stop appearing. This single step eliminates more guesswork than anything else in this guide.

Open your browser's dev tools, go to the Network tab, and filter for bzr.openai.com. Then walk the funnel in order:

Storefront — load a product page. Do you see a request fire (a contents_viewed call)? Add the item to cart. Does items_added fire?
Checkout — start checkout. Does checkout_started appear? Dev tools become less reliable here since checkout runs in Shopify's sandboxed environment, so treat a missing request as inconclusive rather than definitive at this stage.
Post-purchase — complete the order (a real order or Shopify's test mode). Does an order_created event eventually show up in OpenAI Ads Manager's event stream, even if it didn't appear directly in your Network tab? Server-side events arrive through a webhook, not the browser, so they won't show up in this same Network tab check.

Write down exactly where the trail goes cold. "Nothing on the storefront at all" points somewhere very different than "storefront events are fine but checkout is empty" or "checkout looks right but no purchase ever lands in Ads Manager." That single distinction determines which of the next five sections actually applies to you.

1. Theme-level issues

If storefront events (page_viewed, contents_viewed, items_added) are missing entirely, start with the theme. This is the most common failure point because it's also the most common place for things to get overwritten.

Snippet placement in theme.liquid. The JavaScript Pixel needs to load early in the page — typically inside <head> in your theme's layout file, theme.liquid:

<head>
  
  <script async src="https://bzrcdn.openai.com/sdk/oaiq.min.js"></script>
  <script>
    window.oaiq = window.oaiq || function () {
      (window.oaiq.q = window.oaiq.q || []).push(arguments);
    };
    oaiq("init", { pixelId: "YOUR-PIXEL-ID" });
  </script>
</head>

If this block is missing, misplaced deep in the body, or wrapped in a conditional that doesn't evaluate the way you expect, nothing downstream will work — there's no oaiq to call.

Theme updates overwriting code. If tracking worked last month and stopped recently, check your theme's update history first. Updating a theme, especially through the Shopify theme editor's "update" flow, can silently replace theme.liquid with a version that doesn't include your snippet. This is by far the most common "it just stopped working" cause on Shopify specifically, because nothing else changed from your side — the theme changed under you.

Duplicate snippets after theme swaps. The opposite problem: switching themes, publishing a duplicate as a test, or having a developer add the snippet again "just in case" can leave two copies of the pixel init code running. This doesn't always break things outright, but it can cause oaiq("init", ...) to run twice, which complicates debugging later even if it doesn't cause duplicate events by itself.

Check the current live theme's theme.liquid directly in the Shopify theme code editor — don't trust that it's there because it was there once.

2. App conflicts

If the snippet in theme.liquid looks correct but numbers seem inflated, or you're not sure what's actually installed, the next stop is your app list.

Shopify stores commonly run multiple apps that touch pixels, tracking, or checkout data — a general marketing app, a separate conversion-tracking app, possibly a manual install from a previous developer, all potentially initializing oaiq or firing the same standard events independently. When two sources both fire items_added for the same add-to-cart action, OpenAI Ads counts both as separate events unless they're deduplicated by a shared event_id under the same Pixel ID.

How to inventory what's installed:

Go to Shopify admin → Apps and check every app with access to theme code, checkout, or order data — not just ones with "pixel" or "tracking" in the name.
Search your theme code for oaiq and bzrcdn.openai.com to confirm how many places initialize it, and with what Pixel ID each one uses.
Check Shopify's customer events settings (admin → Settings → Customer events) for any custom pixels beyond the one you expect — an old implementation left active after a migration is a common source of this.

The fix here isn't complicated once you've found it: install the pixel in exactly one place, using one Pixel ID, and remove or disable the redundant one.

3. Checkout sandbox limitations

If storefront events are clean but nothing appears from checkout_started onward, this is very likely not a bug — it's expected behavior for a theme-only install.

Shopify restricts third-party script access at checkout. You cannot edit checkout.liquid and inject arbitrary JavaScript the way you can with theme.liquid, because Shopify doesn't render checkout from your theme at all. A pixel snippet that works flawlessly on product and cart pages will simply never execute at checkout — not because it's broken, but because that page isn't reachable by theme code.

The sanctioned path for anything at or after checkout is Shopify's customer events system (also called web pixels), where a custom pixel runs inside a sandboxed environment with restricted access to the page. It subscribes to Shopify's own checkout lifecycle events and calls oaiq("measure", "checkout_started", ...) from inside that sandbox.

If you never set up a custom pixel, this explains the entire gap by itself — there's nothing to debug beyond "this piece was never built." If you did set one up and it's still not firing, confirm two things: that it's actually registered and enabled in the customer events settings (code that exists but isn't activated in Shopify won't run), and that it re-initializes oaiq with the same Pixel ID inside its own sandboxed context, since it's a separate execution environment from your theme's pixel init.

4. Webhook and server-side failures

If checkout-side browser events look fine but purchases never show up as order_created in OpenAI Ads Manager, the problem has moved server-side.

The reliable source of truth for a completed purchase on Shopify isn't a browser event — it's the orders/create webhook, which Shopify fires the moment a real order is placed, independent of whether any browser-side script ran. Your webhook handler is responsible for turning that payload into a server-side event sent to the Conversions API.

Check these, roughly in order of how often they're the actual cause:

Is the webhook registered at all, and against your current live theme or app — not a decommissioned one from a previous setup?
Is your endpoint returning a fast, successful response? Shopify disables webhooks that fail or time out repeatedly, silently, without necessarily surfacing an obvious alert.
Did downtime cause missed events? If your endpoint was down, redeploying, or erroring during a window, orders placed in that window may never have triggered a successful CAPI call, and Shopify does not automatically retry indefinitely.
Is the payload actually reaching the Conversions API correctly formatted — amount as an integer in the currency's minor unit (8998 for $89.98, not 89.98), currency present whenever amount is present, and contents[] using only documented fields?

Webhook failures are the hardest of the five to catch by casual browsing, because nothing looks wrong from the storefront — the whole failure happens after the shopper has already left. This is exactly why webhook health deserves its own explicit check rather than an assumption that "it's probably fine since checkout looked okay."

Last on the list, but not least common: a cookie-consent or privacy-management app can block the pixel script from loading until a visitor explicitly accepts, and most visitors dismiss a banner without clicking "accept."

This produces a specific, deceptive pattern: your pixel test (loading the site fresh, in an incognito window, before interacting with any consent banner) shows nothing firing, and you conclude the pixel is broken — when it may be working exactly as configured, just gated behind consent that most traffic never grants.

Verify behavior in both states. Load the site fresh and check the Network tab for bzr.openai.com before touching the consent banner. Then accept the banner and check again. If events only appear in the second case, your consent tool is doing its job — the question becomes whether that's the coverage you intended, not whether something's broken. If that's genuinely reducing your measured conversions more than expected, the fix is adjusting what the consent tool allow-lists, consistent with your privacy policy, not disabling the check.

Verifying the fix

Once you've identified and corrected the actual cause, don't just assume it's fixed — confirm it the same way you diagnosed it.

Place a real test order and walk the same funnel step by step: product view, add to cart, checkout, confirmation.
Use dev tools at each browser-reachable step to confirm requests to bzr.openai.com are firing with correct data — check amount is an integer in minor units and currency is present.
Check Shopify's customer events debugging tools (in the admin's customer events settings) to confirm any custom pixel is registered and firing, since dev tools alone are less reliable at checkout.
Check your webhook logs for a successful call following the test order, and confirm the corresponding order_created event appears in OpenAI Ads Manager's event stream a few minutes later.
If the event fires but shows 0 against a campaign, confirm the event type — or exact custom event name — matches what's configured on that specific campaign; a mismatch there looks identical to a tracking failure but isn't one.

If you'd rather have someone else run this whole sequence and hand you a clear diagnosis instead of doing the triage yourself, the $450 tracking audit is a 48-hour structured review that pinpoints exactly where events are breaking — and it's credited toward a full fix if you decide to have that done too.

For the full picture of which Shopify events should map to which OpenAI Ads standard events in the first place, see tracking Shopify product views, cart, checkout, and purchases. And for the complete manual-versus-app setup comparison referenced throughout this guide, see OpenAI Ads pixel and CAPI for Shopify.

Want this done for you?

Fixed-scope setup, tested end-to-end and documented.

Explore the service Take the free audit