Most Shopify stores have a working Meta pixel and a broken attribution stack. Those two states coexist constantly - one does not prevent the other. A pixel fires on every page while the data reaching Meta is still garbage. “That gap is what this checklist finds.”
This is the 30-minute pass I run before I change anything else. Fourteen checks across five areas. Each one either passes, warns, or fails. Most stores I look at fail four or five of them.
The short answer
If you want the list before the explanation:
- Client-side pixel firing on all four key pages
- Server-side CAPI firing (not just configured - actually sending)
- event_id deduplication (85-95% rate is the target)
- PII hashing before send (SHA-256 on email, phone, address fields)
- iOS/ATT server coverage (20-35% server-only purchases is the healthy range)
- Match quality score (above 8.5 passes; below 6.5 is actionable)
- Event coverage (all 9 standard events that apply to your business model)
- Advanced matching params (5 or more per event)
- Checkout extensibility or checkout.liquid status
- Thank-you page dataLayer alignment (order value and currency match)
- Refund event tracking
- Consent Mode v2 (four required signals)
- Double-fire conflicts from attribution tools
- Shopify vs Meta revenue delta (below 15% is healthy)
That list takes 30 seconds to read. The next few thousand words are the explanation - what each one means, how to check it, and what it costs when it fails.
The tracking layer
This is where audits start. Five checks, all about whether events are reaching Meta in the first place.
Check 1: Client-side pixel firing
Fetch the homepage, a product page, the cart, and the checkout thank-you page. Look for fbq('track' calls and _fbq.push. A PASS means the pixel is present and firing the right event names on all four pages.
Worth noting: modern Shopify stores inject the Meta pixel through GTM and the web-pixels-manager sandbox, so you often won't see fbq( in raw HTML. Follow any GTM-XXXX container IDs to the gtm.js bundle and check there too. An absent pixel in static HTML is not automatically a failure. An absent pixel in both static HTML and the GTM bundle is.
Check 2: Server-side CAPI firing
This is the check that surfaces the most expensive problems. A CAPI tag configured in your server container is not the same as a CAPI tag that is actively sending events. Look at server container logs or ask for a screenshot of recent event traffic. PASS means CAPI sent events within the last 24 hours, at minimum for the Purchase event.
Check 3: event_id deduplication
The deduplication key has to be identical on both the web pixel and the server container. If it is not, Meta counts two events for every one actual conversion. If the key does not exist at all, every purchase is double-counted, and Meta's optimizer learns from phantom data.
Check the Events Manager Deduplication tab. A healthy rate is 85 to 95%. Below 85% means double-counting. Above 95% means the server event is being rejected entirely - which is actually worse than no CAPI at all, because your data looks clean but is not.
Check 4: PII hashing
Look at the server container. Every PII field - email, phone, first name, last name, city, state, zip, country - should be SHA-256 hashed before leaving your infrastructure. Meta rejects events with raw PII and the exposure is real from a compliance standpoint.
If you see raw email addresses in a server tag payload, that is a FAIL. Fix it before anything else.
Check 5: iOS/ATT server coverage
After Apple's App Tracking Transparency framework, a material percentage of iOS purchases only appear on the server side - the web pixel was blocked. For a correctly configured CAPI setup, server-only events should be 20 to 35% of total iOS purchases.
If server-only iOS events are below 15%, the CAPI is not actually recovering what the client pixel misses. If it is at 0%, the CAPI is redundant rather than additive - you have built a backup that does not do anything the browser already does not do.
Data quality
These three checks measure whether the events reaching Meta carry enough signal to be useful.
Check 6: Match quality score
Pull the match quality score from Events Manager. Above 8.5 is a PASS. Between 6.5 and 8.5 is a warning - functional but inefficient. Below 6.5 is an actionable failure.
A match quality score below 6.5 means Meta is guessing about who your customers are. The real cost is a CPM increase of 20 to 40%. Your ads cost more per impression because the optimizer cannot find your audience confidently. That is money leaving on every ad dollar you spend.
Check 7: Event coverage
Meta's standard event set has nine events: ViewContent, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase, Search, Lead, CompleteRegistration, Subscribe. Check which of these apply to your business model and verify they are all firing.
PASS means all relevant events are firing. A warning is 6 to 8 with the core three (Purchase, AddToCart, InitiateCheckout) present. A failure is fewer than 6, or Purchase missing.
Upper-funnel events matter more than they used to. Meta's optimizer uses the full funnel to identify who is likely to buy, not just the Purchase event in isolation.
Check 8: Advanced matching params
Every event should include as many advanced matching parameters as are available: hashed email (em), hashed phone (ph), first name, last name, city, state, zip, country, and external_id. The target is 5 or more params per event.
The single highest-leverage fix I have seen on a cold store is passing external_id - a hashed Shopify customer ID - on every authenticated event. In one case, that alone moved match quality from 3.8 to 6.2.
One thing Shopify's native CAPI integration gets wrong: it only passes hashed email on the Purchase event, not on ViewContent or AddToCart. That drops match quality by 1 to 1.5 points on every upper-funnel event. If you are using the native integration and nothing custom, this is almost certainly happening.
Shopify integration specifics
Check 9: Checkout extensibility
For Shopify Plus stores: verify the checkout extensibility web pixel is installed and that the Purchase event fires server-side on the thank-you page. For non-Plus stores: check whether checkout.liquid is still in use. Shopify deprecated checkout.liquid in August 2024. Stores still on the old flow often have broken Purchase event firing because the page structure changed and no one updated the tags.
Check 10: Thank-you page dataLayer alignment
Pull the order data from Shopify and compare it to what your tags are sending to Meta. The order value, currency, item count, and item IDs should match exactly.
Common failure: tax and shipping inflating the revenue figure reported to Meta. Another common one: a store that does business in CAD sending USD to Meta because no one set the currency code. Both cause ROAS figures in Ads Manager to be meaningless.
Check 11: Refund event tracking
When an order is refunded, does a negative Purchase event fire? This is not critical the way Check 2 is - it is a WARN more than a FAIL - but it inflates ROAS reporting over time and makes your data drift from reality.
Check for a refund webhook that fires back to Meta on order cancellation or partial refund. Most stores I look at do not have this.
Consent and compliance
Check 12: Consent Mode v2
If you have EU or UK traffic - and most Shopify stores do - Consent Mode v2 is not optional. Four signals need to be set: ad_storage, analytics_storage, ad_user_data, and ad_personalization. All four, with the correct default state for non-consenting users.
If none of these are present, the risk is on two fronts. First, GDPR exposure. Second, Meta can stop serving ads to EU users if consent signals are absent. That is a compliance problem and a revenue problem at the same time.
Attribution conflicts and revenue reconciliation
Check 13: Double-fire conflicts
If Klaviyo, Triple Whale, or Northbeam is installed, check whether any of them have their own Meta tags firing. These tools often come pre-loaded with conversion tracking that conflicts with your primary Meta tag setup.
The failure state here is two tags firing the same event from different sources. Inflated event counts, reduced match quality, and an optimizer that cannot figure out what actually happened.
Check 14: Shopify vs Meta revenue delta
Pull the last 30 days of Shopify revenue. Pull the last 30 days of Meta-attributed revenue. Calculate the delta as a percentage of Shopify revenue.
Below 15% is healthy for most DTC businesses. Between 15% and 30% is a warning - material leak, usually a combination of iOS ATT impact and incomplete CAPI. Above 30% is a failure. At that scale, Meta cannot optimize ads correctly because the data model is wrong.
This is the check that converts the abstract technical problems above into a number someone with a P&L can care about.
When something fails
Fix order matters. A store that fails six checks should not fix them in parallel.
Start with Check 2 (server-side CAPI firing) and Check 3 (event_id dedup) before touching anything else. Those two have the highest compounding effect - every other check becomes more meaningful once the event stream is clean and accurate.
Then Check 6 (match quality) and Check 8 (advanced matching params) together, because they interact. Better params raise match quality; match quality improvement changes what other checks look like in Events Manager.
After those four are clean, the rest become easier to diagnose and fix.
If any of these 14 checks fail and you want the dollar figure attached to each one, the CAPI Leak Report runs the full scan automatically and outputs a fix stack with dollar-impact estimates per check.
Related questions
For a structured breakdown of how I rebuild these tracking setups end-to-end for DTC brands, the work page has the case studies with the technical details.
The products page has the full stack of tools I have built around this methodology, from the automated scan up to the done-with-you infrastructure rebuild.
FAQ
Why does match quality matter if my pixel is firing?
The pixel fires events. Match quality measures how many of those events Meta can tie to a real person in its ad platform. A pixel that fires 10,000 events with no PII attached has a match quality near zero - Meta has 10,000 anonymous signals it cannot act on. The optimizer prices your audience based on what it knows, not what you think you're sending.
What is the expected iOS server coverage range after ATT?
For a correctly configured CAPI setup, server-only events should represent 20 to 35% of total iOS purchases. That range reflects the proportion of iOS users who have opted out of tracking. If your server-only rate is 0%, the CAPI is redundant. If it is above 35%, something is wrong with your web pixel's iOS firing.
My Shopify-native CAPI integration is on - why is match quality still low?
The native integration has documented gaps. It only passes hashed email on the Purchase event, not on ViewContent or AddToCart. It does not pass external_id. And it often lacks the full advanced matching param set. You get something better than nothing, but you do not get a well-configured setup without custom implementation on top of it.
Which tools are most likely to cause double-fire conflicts?
Klaviyo, Triple Whale, and Northbeam are the most common. They are designed for attribution and often ship with their own Meta conversion tags enabled by default. The first sign is usually a deduplication rate above 95%, which sounds good until you realize it means server events are being rejected entirely.
How is the CAPI Leak Report different from running this checklist myself?
The full report runs the actual checks against your store's live data - pixel, GTM container, Events Manager, and revenue figures - and returns a structured output with a dollar-impact estimate per failing check and a prioritized fix stack. This checklist tells you what to look for. The report tells you what it found and what it is costing you.
Sources and specifics
- Match quality below 6.5 correlates with a 20-40% CPM increase on Meta campaigns (Meta Events Manager documentation)
- iOS ATT server-only purchase rate expectation: 20-35% of iOS conversions (observed benchmark across multiple DTC audits)
- event_id deduplication healthy range: 85-95% (outside this range indicates either double-counting or event rejection)
- Shopify checkout.liquid deprecated August 2024 for Shopify Plus checkout customization
- Shopify native CAPI integration passes hashed email on Purchase event only, not on ViewContent or AddToCart