Quick Answer: Headless migrations get planned as design and engineering projects, page speed, redirects, checkout flow, because something visibly breaks if those are wrong. Tracking doesn't get the same scrutiny because nothing visibly breaks, the dashboard still loads, the numbers are just quietly wrong from day one. Event completeness, match quality, express checkout coverage, and multi-pixel setups all degrade silently unless someone specifically verifies them during the migration, not months after.

Key Takeaways

• A theme-to-headless migration gets planned around what visibly breaks if it's wrong, page speed, redirects, checkout flow. Tracking doesn't get the same scrutiny because nothing visibly breaks when it's wrong, the dashboard still loads and numbers still show up, they're just quietly incomplete from launch day.
• Four specific things degrade during migration: event completeness (Purchase gets built first, AddToCart and InitiateCheckout are often partial or missing), match quality, express checkout coverage, and multi-pixel setups where a general "tracking is verified" check leaves a second pixel unchecked.
• Meta's EMQ benchmarks are worth knowing directly: 8.6 to 9.3 is considered strong for Purchase, 7.5 or higher solid for AddToCart and InitiateCheckout. A fresh, unverified headless build often sits well below both.
• EMQ doesn't recover instantly once a gap is fixed. It improves gradually as clean, complete data accumulates, which is why catching a gap during migration matters more than catching it months later.
• The one concrete check that separates "tracking is probably fine" from "tracking is actually fine" is comparing Meta Pixel purchase counts against Shopify's placed-order data for the same window, run in the first week after launch, not the first quarter.

Headless migrations get sold on speed and flexibility. Faster page loads, more design control, a frontend that isn't locked into Shopify's theme constraints. All of that is usually true.

What doesn't get mentioned nearly as often is what happens to your attribution data during and after that migration, if nobody's specifically responsible for verifying it. This isn't a headless problem in the sense that headless is bad. It's a headless problem in the sense that nothing about the migration forces anyone to check.

Why is the migration itself the highest-risk moment?

Because headless removes the theme layer, and tracking apps that relied on that layer lose what they were plugged into, true on day one of a headless build, and quietly true during the migration itself.

A theme-to-headless migration usually gets planned and executed as a design and engineering project. Page speed, SEO redirects, checkout flow, these get attention because someone owns them and something visibly breaks if they're wrong. Tracking often doesn't get the same scrutiny, because nothing visibly breaks. The dashboard still loads. Numbers still show up. They're just wrong, quietly, from the day the new frontend goes live.

By the time anyone notices ROAS looking soft, weeks or months of data have already been generated on an incomplete or misfiring setup. That data feeds ad platform algorithms, informs budget decisions, and in Meta's case specifically, affects EMQ scores that take time to recover once they've dropped.

What actually degrades, specifically?

Four distinct things, each easy to miss for a different reason.

Event completeness. Purchase tends to get implemented first, because it's the event everyone's watching. AddToCart, InitiateCheckout, and PageView are more likely to be partial or missing entirely on a fresh headless build, and these are exactly the events retargeting and full-funnel optimization depend on.

Match quality. Meta's EMQ score reflects how much verified customer data arrives with each event. A rushed manual implementation is more likely to miss fields, email, phone, or other match parameters, that a properly configured server-side pixel would capture automatically. Benchmarks worth knowing here: Meta considers 8.6 to 9.3 strong for Purchase, and 7.5 or higher solid for AddToCart and InitiateCheckout. A fresh headless build that hasn't been checked often sits well below both.

Express checkout coverage. Shop Pay, Apple Pay, and PayPal skip the standard checkout flow. If nobody built tracking for those paths specifically, that revenue exists in Shopify and is invisible everywhere else. This is one of the more common gaps precisely because it doesn't show up unless someone checks for it directly.

Multi-pixel setups. Brands running more than one Meta Pixel, common in multi-brand operations or agency-managed accounts, need each pixel individually verified. A migration checklist that verifies "tracking" once, in general, can leave a second pixel broken and unnoticed for as long as nobody looks specifically at it.

What Degrades During Migration, At a Glance

Why doesn't anyone catch this in real time?

Because there's no error state for any of this. A missing AddToCart event doesn't throw a warning. A low EMQ score doesn't block campaign delivery, it just makes every dollar of ad spend less efficient.

The signal that something's wrong is a slow decline in reported performance, which looks exactly like normal market softness, seasonality, or ad fatigue until someone runs the actual comparison: Meta Pixel purchase counts against Shopify's placed-order data for the same window. That comparison is the one concrete thing that separates "tracking is probably fine" from "tracking is actually fine." Everything else is inference.

What should a migration checklist actually include?

Five tracking-specific items worth adding to the project plan directly, not treated as implied by "tracking is set up."

• Verify Purchase, AddToCart, InitiateCheckout, and PageView are all firing, not just Purchase.
• Check express checkout paths separately from standard checkout.
• If running multiple Meta Pixels, verify each one independently.
• Run the Meta Pixel-to-Shopify-order comparison within the first week of launch, not the first quarter.
• Check Meta's Diagnostics tab for parameter-level warnings before assuming a clean pixel.

None of this requires new tooling. It requires someone treating tracking verification as a defined step in the migration, the same way page speed testing or redirect mapping already is.

What does skipping this actually cost?

More than a single broken metric. It's every downstream decision made on top of incomplete data: ad budget allocated based on ROAS that doesn't reflect real performance, retargeting audiences built on incomplete event data, and months of EMQ recovery time after the fact, since Meta's match quality score improves gradually as clean data accumulates, not instantly once a gap is fixed.

This is why a managed server-side tracking layer built specifically for headless matters more at the migration stage than almost any other point. Aimerce's Hydrogen and custom JS integration paths are designed to avoid exactly this gap between "the migration is done" and "tracking is actually verified," delivering complete event data to every connected platform from launch day, not from whenever someone finally runs the comparison.

Common mistakes to avoid

• Treating tracking as implied by "the migration is done" rather than a defined checklist item. Page speed and redirects get scrutiny because someone owns them explicitly. Tracking needs the same explicit ownership.
• Verifying Purchase and assuming the rest of the funnel is fine. AddToCart, InitiateCheckout, and PageView are the events most likely to be partial specifically because Purchase gets built first.
• Waiting for a quarterly review to run the Shopify-vs-Meta comparison. By then, months of ad spend have already been allocated against incomplete data.
• Verifying "tracking" once when running multiple Meta Pixels. A general check can pass while a second, unverified pixel stays silently broken.
• Assuming a fixed gap means an immediately recovered EMQ score. Recovery is gradual, which is exactly why catching gaps early matters more than fixing them late.

FAQ

How long does it take to notice broken tracking after a headless migration? Often weeks to months, since there's no error state. The first visible signal is usually softer-looking ROAS or retargeting performance, which gets misattributed to market conditions rather than a tracking gap.

Does a low EMQ score recover immediately once tracking is fixed? No. EMQ improves gradually as clean, complete event data accumulates. Fixing a gap stops further damage, but recovering the score takes time, which is part of why catching gaps early matters more than fixing them late.

What's the single fastest way to check if a headless migration broke tracking? Compare Meta Pixel purchase event counts against actual Shopify placed-order counts for the same time window. A mismatch confirms a gap exists and gives you a starting point for finding it.

Which events are most likely to be missing after a headless migration, specifically? AddToCart, InitiateCheckout, and PageView, more than Purchase. Purchase tends to get implemented first since it's the event everyone watches, which means the others are more likely to be partial or skipped entirely.

Why does express checkout need to be checked separately during a migration specifically? Because Shop Pay, Apple Pay, and PayPal skip the standard checkout flow a migration project typically tests against. That revenue exists in Shopify and stays invisible everywhere else unless someone checks those specific paths.

If we're running multiple Meta Pixels, does verifying tracking once cover all of them? No. Each connected pixel needs independent verification. A general "tracking is working" check can pass while a second pixel, common in multi-brand or agency-managed accounts, stays broken and unnoticed.

When should the Meta Pixel-to-Shopify-order comparison actually happen? Within the first week after launch, not the first quarter. Running it early is what catches a gap while it's still cheap to fix, before months of ad spend have been allocated against incomplete data.

Sources

[1] Madgicx, "How to Improve Event Match Quality for Higher ROAS" (event-specific EMQ benchmark ranges)

Related reading

• Why Does Tracking Break When You Go Headless on Shopify?
• How to Verify Your Headless Shopify Tracking Is Firing
• Hydrogen vs. Custom JS: How Headless Tracking Differs