September 20, 2026 · The lunalink.ai team

Is your Shopify analytics broken if the tracking snippet isn’t in the page source?

HTML code displayed on a screen, demonstrating web structure and syntax. — Photo by anshul kumar on Pexels

You open your Shopify homepage, choose View Source, and search for your analytics snippet.

Nothing.

It is easy to conclude that tracking is broken. We nearly did exactly that on our own homepage.

We searched the HTML for our tracking snippet, found nothing, and almost declared our analytics dead. The tracking was running. Its key lived in the compiled JavaScript bundle, not in the HTML the server sent first.

That distinction matters. Your page source is one piece of evidence. It is not the final answer.

View Source shows the first HTML response

View Source shows the HTML sent by your server when the page first loads. It can show a normal theme script, a Google Tag Manager container, or an iframe.

But analytics can load after that first response.

A browser can download JavaScript, run it, and then load another script. Shopify pixels can also run outside the normal theme HTML. App pixels are installed through apps and run in Shopify's strict sandbox. Custom pixels are set up in Settings → Customer events and run in a separate sandbox. Shopify's pixel documentation explains the difference.

A custom pixel can create a script element in the browser, set its `src`, then add it to the page. There may be no literal `<script src="...">` for that analytics tool in the HTML you see in View Source. Shopify shows this pattern in its custom pixel guidance.

So this test:

Open View Source
Search for a tracking ID
Find nothing
Conclude tracking failed

is incomplete.

It can still reveal a problem. But it cannot prove one on its own.

Check the request, not only the source

The useful question is simpler: did the visitor's browser send a request to the analytics service?

Google makes the same distinction in Tag Assistant. A source-code scan looks for implementation code. A request check looks for the request that fires and sends information to Google's servers. Those are different checks.

For a Shopify merchant, Chrome Developer Tools is usually the tie-breaker.

Here is a practical way to check your own storefront.

1. Open your store in Chrome. 2. Right-click the page and choose Inspect. 3. Open the Network tab. 4. Reload the page while the Network tab is open. 5. Use the filter box to search for part of your analytics provider's domain or endpoint. 6. Click a matching request and inspect its details.

You are looking for a request that appears when the page loads or when you take the action you are testing.

If you are checking product tracking, open a product page after you have DevTools open. If you are checking checkout tracking, follow the same path you expect a customer to follow. One homepage reload cannot test every event.

In DevTools, inspect the request and its initiator. Google specifically recommends checking the tag, request, and initiator when a tag seems active but cannot be found in page source. See Google's guidance here.

The initiator can help you find what loaded the request. It may point to a JavaScript bundle, a pixel, a tag container, or another script.

That is how we should have approached our own check first. We searched for a snippet in the homepage HTML. We should have watched what the browser actually did.

Shopify pixels often load after the theme HTML

Shopify's pixel system is one reason source inspection can mislead you.

Pixels can subscribe to events such as `page_viewed` and `product_viewed` after they load. Shopify also provides checkout-related events through its Web Pixels API. The event list and coverage are documented here.

This means you need to test both parts:

Did the pixel load?
Did the expected event fire?

Say your product page view tracking is missing. You may see the analytics script load in Network, which tells you the first part worked. Then you may need to inspect requests after opening a product page to see whether the `product_viewed` event resulted in a request.

That is more useful than asking whether a script appears in View Source. It separates a loading problem from an event problem.

Shopify also provides Shopify Pixel Helper for testing app pixels and custom pixels. It can show how a pixel loads and receives events. Shopify recommends it for this kind of testing.

If you use a custom pixel, check Settings → Customer events first. Confirm it is configured there, then test the storefront with Pixel Helper and DevTools open.

Test consent before changing your code

A correctly configured pixel may not load for every visitor.

Shopify's pixel manager loads an app pixel only after the visitor grants the privacy permissions that pixel requires. Web pixels also follow your store's privacy settings. If you use another consent tool, it needs to pass consent to Shopify through the Customer Privacy API. Shopify documents those rules here.

So test at least two cases if consent applies to your store:

A visitor who has not granted consent
A visitor who has granted the relevant consent

Do not treat one result as universal.

If the request appears only after consent, that may be the intended behaviour. If it never appears after consent, you have a more focused problem to investigate.

You can check this in under a minute. Open a private browser window, visit the store, make one consent choice, and inspect Network. Then repeat with the other choice.

Rule out blockers and duplicate requests

Your own browser may not behave like a customer's browser.

Ad blockers can block a web pixel entirely. Browser privacy protections can also reduce third-party attribution even when a pixel runs. Shopify says this does not affect its own order records and reports, but it can reduce or remove third-party attribution. Shopify explains the difference here.

For a cleaner test, use a browser profile with extensions disabled. Then repeat the check in the browser you normally use. If the request appears in the clean profile but not your usual one, an extension or browser setting may be involved.

Also look for duplicates.

Shopify's troubleshooting guidance recommends checking for multiple requests to the same analytics endpoint during one page load or event. Two copies can happen when an old setup and a new pixel both send the same event. Its migration guide also recommends inspecting requests and using `console.log` while testing.

A simple test:

Reload one page once.
Filter Network to the analytics endpoint.
Count the matching requests.
Repeat after one clear action, such as opening a product page.

You are not trying to memorise every request. You are looking for an obvious pattern: none, one expected request, or repeated copies.

When a missing snippet is a real warning

Do not swing too far the other way. Missing source code is not proof that analytics works either.

If you expect a standard Google Tag Manager snippet in your theme and it is missing, that deserves attention. Google notes that a container can be present in source but fail to execute when the expected container response is missing. It also warns that non-standard setups can send requests without a standard snippet. Its advice is to use preview or debug tools and verify the request behaviour.

The right conclusion is not “source never matters.”

It is this: source tells you how the page began. Browser requests tell you what actually happened.

Before you remove code, reinstall an app, or ask a developer to rebuild tracking, open DevTools and reload one page. Check whether the browser sent the request you expected.

That small check may save you from fixing something that was already working.

Sources

shopifyanalyticspixelstroubleshooting