PixelProof answers a narrow question: which of the Meta pixels, GA4 tags, and Google Tag Manager containers on your Shopify storefront break when Shopify's Aug 26, 2026 checkout-extensibility upgrade removes the Additional Scripts field and checkout.liquid support? This page explains exactly how that scan works, what data sources the rules are encoded from, and what the scan does not cover.
1. What the scan does
When you enter a Shopify storefront URL, PixelProof performs three sequential steps from our own server (never from your customers' browsers, and never from your Shopify admin):
- Fetch the storefront's public HTML. A headless HTTP request from our scanner IP hits the root URL and up to 4 additional product/collection URLs discovered from the site's own sitemap.xml. We do not authenticate, do not read cookies, do not interact with checkout, and do not attempt a test order.
- Grep for tracking-loader patterns. The response bodies are scanned for known Meta Pixel, GA4, and GTM initialization patterns:
fbq('init', 'PIXEL_ID'),gtag('config', 'GA_ID'),dataLayer.push(...),_learnq(Klaviyo),Shopify.analytics, and equivalent subscription-style loaders. Each match records the pixel ID, the injection surface (checkout.liquid vs Additional Scripts vs theme.liquid vs Web Pixels API vs Meta channel app), and whether that surface is scheduled for removal on Aug 26. - Cross-check pixel IDs against Meta's Graph API public metadata. For any Meta pixel ID found, we call Meta's Graph API to confirm the pixel is active and pull the last-event timestamp Meta will surface publicly. A pixel that's installed on the page but hasn't received an event in 30+ days is a real signal (usually a misconfigured event, sometimes ad-blocker interference) — the scan flags it separately from the "will break on Aug 26" class.
2. Data sources for the ruleset
The rules-version string pixelproof-scan-v1-2026-08-14 maps to three primary sources, all first-party from Shopify or Meta:
- Shopify Web Pixels API documentation — the authoritative Shopify docs for the sandboxed pixel-registration system that replaces Additional Scripts and checkout.liquid pixel injection.
- Shopify Checkout Extensibility documentation — the framework that becomes mandatory on Aug 26, 2026 for non-Plus stores, replacing the legacy checkout.liquid theme file.
- Meta Conversions API documentation — the server-to-server alternative to the browser Meta Pixel, used to determine whether a store has a functional CAPI backstop when the browser pixel fails.
Third-party interpretations (agency blog posts, Reddit threads, Shopify community forums) are not encoded as rules. If our reading of the primary docs is wrong, that's a scanner bug that lands on /corrections, not a "different interpretation."
3. Rules the scan actually applies
The current ruleset checks for eight failure modes ahead of the Aug 26 upgrade. Every rule below has a rule ID (visible in the scan response's result.rules[] array) and a citation to the Shopify or Meta doc it's derived from:
- PP-R01: Meta Pixel injected via Additional Scripts (order-status page) — will stop firing Aug 26 on non-Plus stores.
- PP-R02: Meta Pixel injected via checkout.liquid theme edit — same deprecation window as PP-R01.
- PP-R03: GA4 tag firing only from checkout.liquid without a Web Pixels API fallback.
- PP-R04: GTM container fires from theme.liquid but its dataLayer.push events depend on Shopify variables removed in the upgrade (e.g. legacy checkout event names).
- PP-R05: Meta Conversions API (CAPI) is NOT configured — meaning the browser pixel is the only tracking path, no server-side backstop when the browser fails.
- PP-R06: CAPI is configured but the browser pixel and CAPI events do not share a common event_id — Meta will double-count, showing an inflated conversion number that will collapse when the browser pixel breaks.
- PP-R07: Pixel is installed but Meta's Graph API reports zero events in the last 30 days (misconfiguration signal, not an Aug 26 signal).
- PP-R08: Multiple duplicate Meta Pixel IDs found on the same page (usually one from the Meta channel app and one from theme code) — will fire the event twice per action.
Each rule in the response body carries the same three fields: ruleId, severity (critical / high / medium), and citation (a URL back to the Shopify or Meta doc that defines the underlying behavior).
4. What this scan does NOT cover
- Not a full GDPR / CCPA / CPRA privacy audit. Tracking pixels are subject to those laws, but scanning for cookie-consent implementation is a separate tool — see our free Cookie Consent Checker.
- Not a substitute for testing your own checkout with a real order in Shopify's test mode. A green PixelProof scan means the tracking-loader patterns look correct; only a real completed test order confirms the events actually fire end-to-end.
- Does not cover Shopify Plus checkout customizations that go beyond Additional Scripts + checkout.liquid — the Aug 26 upgrade is a non-Plus deprecation, and Plus stores have a longer migration path.
- Does not cover non-Meta / non-Google trackers (TikTok, Pinterest, Snap, LinkedIn) yet — those platforms have their own pixel APIs and are scheduled for a future scanner rev.
- Does not authenticate against your Shopify admin, does not read your Meta Ads Manager, does not access your GA4 property. Every check runs against publicly reachable data only.
5. Known false-positive and false-negative modes
The most common false positive is a store that has already migrated to the Web Pixels API but still has commented-out legacy pixel code left in checkout.liquid — the grep matches, but those lines won't actually fire. If you get a PP-R01 or PP-R02 result on a store you know has migrated, please email a link to your storefront to hello@citationsafe.com and we'll refine the grep pattern.
The most common false negative is a pixel injected via a Shopify app whose script tag is rendered server-side only for authenticated buyers — our scanner hits the unauthenticated storefront path, so an authenticated-only pixel won't be detected. This is a real limitation and disclosed in the scan result UI.
6. Version history
pixelproof-scan-v1-2026-08-14 is the current ruleset. Previous versions:
pixelproof-scan-v1-2026-08-14— added PP-R07 and PP-R08 (event-freshness + duplicate-pixel checks).pixelproof-scan-v0-2026-08-05— initial ship with PP-R01 through PP-R06.
Back to PixelProof · Portfolio methodology · PixelProof glossary · PixelProof roadmap