Meta Pixel Not Tracking on Shopify? Start Here

Fourteen orders in Shopify since midnight. Zero purchases in Events Manager. Or the version that confuses people more: PageView climbing all day, ViewContent looking healthy, and Purchase flat as a table.

A meta pixel not tracking shopify orders is not one fault. It is three faults wearing the same costume, and the fix for each one is useless against the other two. Either the code is absent from the page, or the code is present and firing while the request never leaves the shopper's device, or the request arrives at Meta intact and matches nothing worth crediting.

Most troubleshooting lists hand you a long row of settings to toggle and hope one of them was the culprit. Do it the other way round. Prove which layer the signal dies at, then fix only that layer.

Why is the Meta pixel not tracking Shopify orders: absent, blocked, or unmatched?

An absent pixel and a blocked pixel produce the same empty dashboard, so the dashboard cannot tell them apart. The shape of what is missing can.

• Absent code fails completely and consistently. No events, no partial events, nothing in Test Events even when you browse the store yourself with every blocker disabled. If your own session produces nothing, stop looking at Meta and go look at the page.
• A blocked request fails partially and unevenly. Your test works, colleagues' tests work, and the daily totals still sit well under your order count. The code is fine. The network is not.
• A matched-nothing event fails invisibly. Volume looks correct, Purchase counts roughly track orders, and the ad-level rows are still empty. Nothing is broken in the sense you were expecting.

Work top to bottom. Each row rules out everything above it.

What does Test Events tell you in the next sixty seconds?

Test Events is the fastest instrument you own, because it is close to real time and it shows the payload, not just a count. Run this before you change a single setting.

1. Open Events Manager, select the pixel you believe your store is using, and open the Test Events tab.
2. Use the flow it gives you to open your storefront in a fresh browser window with no ad blocker and no extensions.
3. Load a product page. Watch for PageView and ViewContent.
4. Add to cart, then start checkout. Watch for AddToCart and InitiateCheckout.
5. Complete an order using Shopify's test payment gateway. Watch for Purchase.
6. Click into the Purchase event and read its parameters, not just its name.

You now know which of the three layers failed, and you have not touched anything yet.

Meta's Pixel Helper browser extension is a useful second opinion here, because it reads what is actually on the page rather than what Meta received. If Pixel Helper sees the code and Test Events sees nothing, your request is dying between the two.

Is the pixel ID on your page the one you are staring at in Events Manager?

This is the single most common cause I find on stores that swear the install is correct, and it costs about ten seconds to rule out.

• Old agency pixels linger in themes. Someone hardcoded a base snippet into theme.liquid three years ago. It still fires, perfectly, into an ad account nobody opens any more.
• Duplicate pixels get created during onboarding. A business manager with three pixels named after the same brand is normal. Meta will happily receive events into one while you refresh reports on another.
• The ID is the proof. View source on your storefront and search for the numeric ID. Compare it character by character with the ID in Events Manager. Do the same on the checkout and thank-you pages, which may be served by an entirely different mechanism.

If they do not match, you do not have a tracking problem. You have a pixel with excellent data that you have never looked at.

Did Shopify's Facebook & Instagram channel quietly take ownership of it?

The sales channel is the most common install path, which means it is also the most common source of surprises after a theme change or an app uninstall.

• The channel binds a specific pixel at connect time. Reconnecting the channel, changing the connected business account, or having a colleague reconnect it can rebind it to a different pixel than the one your reports are built on.
• Customer data sharing level changes the payload, not the count. If sharing was reduced, your events keep arriving and keep looking present while carrying far less to match on. That symptom belongs to layer three, not layer one, and it is frequently misdiagnosed.
• A hardcoded snippet plus the channel is a real risk. If the theme also carries a base snippet for the same ID, you are now sending from two places. That is a different article's problem, but it starts here.

Confirm what the channel is bound to before you disconnect anything. Disconnecting is not a diagnostic step. It is a change that destroys the evidence.

Why does PageView fire while Purchase never does?

Because they do not run in the same place, and they have not for some time. Your storefront pages are your theme. Checkout is not.

• Checkout runs in a sandbox with a defined API. Shopify's Web Pixels API gives you controlled APIs inside a Lax or Strict sandbox per Shopify's documentation. Code written for a normal page, expecting free access to the document and to globals, does not behave there the way it does on a product page.
• Additional scripts are not the answer any more. Anything you pasted into a legacy checkout script box is not carried forward into modern checkout. A PageView that works and a Purchase that never appears is the exact fingerprint of this.
• The event has to be registered as a web pixel. If nothing is registered for checkout, checkout sends nothing, forever, no matter how correct your theme install looks.

Test it directly. Place one test order and watch Test Events during the checkout steps rather than after them. If InitiateCheckout appears and Purchase does not, you have narrowed it to the final page. If neither appears, checkout has no pixel at all.

Is the request dying before it leaves the shopper's device?

This is the layer people skip, because their own test passed. Your test passing is not evidence about anyone else.

• Content blockers drop the request outright. The browser makes no call, so there is nothing to debug on Meta's side. From Events Manager it looks identical to an uninstalled pixel, just at a smaller scale.
• In-app browsers are their own world. A shopper who taps an ad inside a social app finishes checkout in an embedded browser with different storage rules and, often, a lost session partway through.
• Storage gets cleared on a schedule you do not set. Safari deletes all script-writable storage after seven days of Safari use without interaction on the site as documented by WebKit, which removes the identifiers a returning buyer would have carried.
• Real networks drop things. Tabs close, mobile connections stall, and a browser-side request that never completes leaves no trace anywhere.

The fix for this layer is not a setting. It is sending the event from somewhere the browser cannot veto, which is what server-side tracking exists to do.

Why do events arrive and still credit no ad?

Here the pixel is working exactly as designed and the reports are still empty, which is the most frustrating version of all.

• No click identifier means no ad to credit. If the click parameters were never captured, or were cleared before checkout, Meta receives a purchase it cannot connect to any click. The event counts. The campaign does not.
• Thin payloads match fewer people. Fewer customer information parameters means fewer successful matches, and a lower match rate shows up as missing conversions rather than as an error.
• Landing page redirects strip parameters. A redirect chain that drops query strings between the ad click and the product page removes the identifier before anything has a chance to store it.

Check this by opening one real Purchase event in Test Events and reading what it actually contains. An event with a name, a value and almost nothing else is not a tracking failure. It is a matching failure, and no amount of reinstalling will change it.

What does Trackproof do the moment the browser refuses?

Trackproof is our Shopify app, it is free, and it has no reviews yet because it is new. It sends your events from the server rather than relying on the shopper's browser to complete a request, which is a direct fix for layer two and a partial fix for layer three, because a server-sent event can carry parameters the browser would have lost.

Be clear about what it does not do. If your problem is layer one, no server-side tool on the App Store rescues you. Code that was never installed cannot be sent from anywhere, and you need to fix the install first. If what you actually want is a full analytics build rather than a focused conversion fix, Trackproof is the wrong shape of tool and you should look at the larger tracking suites instead. I have gone through what they cost and where they beat us in our Analyzify alternatives roundup.

Diagnose the layer first. Then choose the fix that belongs to it.