Shopify Web Pixels Explained for Merchants
How the Shopify Web Pixel API works, why it replaced theme scripts, and what merchants need to know about the sandbox.
Written by Mantas Jurgutis — Founder, Adsify — builds the Google & Meta automation merchants use daily
Editorially reviewed by Adsify Editorial on January 20, 2026 — Reviewed against Shopify, Google Ads and Meta official documentation.
What a Web Pixel actually is
A Web Pixel is code registered through Shopify's Web Pixel API that runs inside a sandboxed environment separate from your storefront theme. Instead of pasting a Google or Meta script into theme.liquid, merchants (or apps acting on their behalf) register a pixel that subscribes to standardized customer events like page_viewed, product_viewed, checkout_started and checkout_completed. Shopify runs this sandbox on every page, including checkout, which is why Web Pixels can see events that old theme-based scripts never could. The sandbox has no access to the DOM, cookies outside its own storage partition, or arbitrary network calls beyond what Shopify permits.
Why Shopify moved away from theme scripts
Before Web Pixels, merchants added tracking by editing checkout.liquid or theme.liquid directly, which meant every pixel vendor had full access to the page, could slow down checkout, and could leak customer data across apps. Shopify's Settings > Customer events area consolidates every pixel into one auditable list, and each pixel declares what data it needs. This matters for PCI compliance on checkout pages and is the underlying reason Shopify deprecated additional scripts and checkout.liquid customizations in favor of checkout extensibility and Web Pixels.
First-party vs custom pixels
Shopify offers two flavors: app-owned first-party pixels, which apps like Meta or TikTok's official integrations register automatically when installed, and custom pixels, which merchants add manually under Settings > Customer events > Add custom pixel using JavaScript. Custom pixels are useful for smaller tools or GA4 setups but run with more restrictions than app pixels, including limits on outbound network requests. Most merchants running Meta and Google ads should prefer the app-provided pixel over a hand-rolled custom pixel, since the app vendor maintains it against Shopify's API changes.
The standard event catalog
Web Pixels expose a fixed set of standard events: page_viewed, collection_viewed, product_viewed, product_added_to_cart, cart_viewed, checkout_started, checkout_contact_info_submitted, checkout_address_info_submitted, checkout_shipping_info_submitted, payment_info_submitted, and checkout_completed. Each event payload includes structured data such as line items, prices, currency and, on checkout_completed, order and customer identifiers. Because these are standardized, an app pixel behaves consistently across every Shopify theme, whereas old theme scripts had to be rewritten per theme when developers changed markup.
What Web Pixels cannot do
Because the sandbox isolates pixels from the page, a Web Pixel cannot modify checkout UI, read arbitrary cookies set by other scripts, or block checkout from completing. If you relied on a theme script to change button text, apply a discount, or read a third-party affiliate cookie, that logic has to move elsewhere, typically into a checkout UI extension or a Shopify Function, which are separate APIs from the Web Pixel API. Merchants migrating legacy tracking often discover mid-project that the old script was doing double duty as both a pixel and a UI hack.
Checking what pixels are firing
Go to Settings > Customer events in the Shopify admin to see every registered pixel, its status, and a live activity log that shows recent events with timestamps. This is the fastest way to confirm whether an app actually fired checkout_completed for a real order, without needing browser dev tools. If an app's pixel is missing from this list entirely, the app likely isn't using the Web Pixel API and may still be relying on deprecated methods that Shopify will stop supporting.
Consent and the pixel sandbox
Web Pixels respect the storefront's customer privacy settings. If a visitor has not granted marketing consent and you have Shopify's customer privacy API or a consent management platform wired in, standard events can be withheld from pixels that require marketing consent until the visitor accepts. This is separate from, but complementary to, consent mode v2 signals sent to Google. Merchants in the EU need both layers configured correctly or they will see pixels firing for visitors who explicitly declined tracking.
Server-side events versus the pixel
The Web Pixel API only covers what happens in the browser sandbox. For events like refunds, or for closing the gap when a browser blocks the pixel, Meta's Conversions API and Google's Enhanced Conversions ingest events server-side using order data from Shopify webhooks, independent of whether the browser pixel fired. A mature setup runs both: the Web Pixel for browser-side signals and speed, plus a server-side feed for reliability and event matching.
Debugging a missing checkout_completed event
A common support ticket is 'my pixel isn't tracking purchases.' Start in Settings > Customer events and look for the pixel's activity log around the time of a real test order. If checkout_completed appears there but not in Meta Events Manager or Google Ads, the issue is in how the pixel maps Shopify's payload to the ad platform's event schema, not in Shopify itself. If checkout_completed never appears at all, the pixel registration itself is broken, often because the app was uninstalled and reinstalled without re-registering.
Multiple pixels, one order
It's normal for a store to have several pixels active at once: Google's app, Meta's app, a GA4 custom pixel, and possibly Adsify's own pixel for profit and POAS tracking. Each one independently subscribes to the same checkout_completed event and can fire its own conversion call. Shopify does not deduplicate between apps, so if two apps both send the same purchase to the same ad account, you can end up with inflated reported revenue on that platform.
Why speed matters at checkout
Shopify budgets execution time for pixels running on the checkout page to keep checkout fast; a poorly written custom pixel that blocks on a slow network call can be throttled. This is one reason app-maintained pixels tend to outperform hand-written custom pixels: vendors optimize for the sandbox's constraints and update their code when Shopify changes limits, whereas a custom pixel pasted in 2023 may silently degrade as Shopify tightens the sandbox.
Testing before launch
Before trusting a pixel with ad spend decisions, place a real low-value test order (Shopify Payments test mode or a $1 product) and confirm in Settings > Customer events that checkout_completed logged with the correct order value and currency, then confirm the same event landed in Google Ads' conversion diagnostics or Meta Events Manager's test events tool within a few minutes. Skipping this step is the single most common cause of merchants discovering, weeks into a campaign, that conversions were never actually recorded.
What this means for attribution
Because Web Pixels only see events in the browser during the session in which they load, they cannot attribute a purchase to an ad click that happened three days earlier on a different device unless the browser cookie or Shopify's own click-id capture carried that context forward. This is exactly why gclid and fbclid capture, plus server-side matching, matter more as privacy restrictions increase; the pixel alone was never a full attribution system, just the first-party event source.
Where Adsify fits in
Adsify installs as a first-party Web Pixel alongside sending the same order data server-side via Meta's Conversions API and Google's Enhanced Conversions, so a single order can be matched to the original ad click even if the browser pixel was blocked. That combination is what lets Adsify's optimizer, which re-evaluates campaigns every 6 hours, work from consistent conversion data rather than the partial picture a browser-only pixel provides.
Practical takeaway
Treat the Web Pixel API as the event source, not the whole tracking stack. Verify events in Settings > Customer events, understand that consent settings can suppress events legitimately, and pair browser pixels with server-side APIs before trusting reported conversion numbers for budget decisions. Merchants who skip verification typically discover the gap only after a month of misallocated ad spend.