A thing I didn’t fully appreciate until recently:

“Server-side tracking” and “better Meta attribution” are not automatically the same thing.

A lot of setups assume that once Purchase events are sent through CAPI/server-side pipelines, attribution problems are basically solved.

But after digging into different architectures (GTM + Stape forwarding flows vs backend-native CAPI flows), I realized they fail in very different ways.

In browser-assisted server-side setups (web GTM → sGTM/Stape → Meta), the browser is still effectively the source of truth.

So if the browser-side event/session breaks first:

• ad blockers
• browser changes
• thank-you page failures
• delayed purchases
• session loss

…the server-side Purchase event may never be generated correctly in the first place, which can eventually lead to Shopify/Meta purchase mismatches or even duplicate Purchase events if deduplication breaks along the way.

On the other hand, backend-native CAPI systems are much more reliable for event delivery because the backend/order system becomes the conversion source of truth.

But those setups have a different problem:

Meta still needs identity continuity.

If browser identity signals (fbc/fbp/IP/UA/hashed identifiers) are not persisted and propagated correctly, Meta may successfully receive the Purchase event while still failing to attribute it back to the original ad click — resulting in the same “Meta underreporting” symptoms from a completely different failure point.

Which means:

successful event delivery ≠ successful attribution.

That distinction cleared up a lot of confusion for me around:

• Meta underreporting
• low EMQ
• Shopify vs Meta purchase mismatch
• “server-side but still inaccurate” setups
• browser/server deduplication problems

I’ve been auditing the signal loss on the Android side for a client in the APAC region over the last few days, and I’ve stumbled upon a "black hole" even more elusive than iOS 14.

It reminded me of my time as an Android Engineer at Meta. Back then, to optimize engagement metrics for Reels ads, we pushed the "swipe-left-to-click to ad destination" threshold to an extremely aggressive angle and distance just to capture every bit of user intent. I’ll admit—I personally “fine-tuned” that triggering angle and distance to be as small as possible to secure my 2024 bonus (Got an EE rating for 2024, but looking back, I highly doubt the advertisers would thank me).

While that UI strategy was great for CTR metrics and helped Meta collect more money from its Advertisers, it’s been a total disaster for tracking.

The Technical Reality: Why "Angle" Kills your "Signal"

When you have such a sensitive trigger, you get a massive surge of accidental or high-frequency "cold starts" and WebView handoffs.

I remember during internal QA, even the high-end test devices the company issued us—like the Samsung S21 and Pixel 9 Pro—would occasionally crash or force-close the Facebook app because my triggering code was so aggressive that it overwhelmed the main thread.

If premium flagship phones were struggling, imagine what happens on the mid-to-low-end Android devices that dominate the APAC market. This frantic switching triggers the system's LMK (Low Memory Killer) almost instantly. The OS sees the rapid resource spike and decides to "clean house." It executes background processes at the millisecond level—meaning your GTM, Pixel, and even CAPI handoff scripts are often killed before they can even say "hello" to your server.

The "Logic Swap": Why CNAME/CAPI isn't enough

Here is the part most advertisers miss: The OS isn't just failing the script; it's effectively "swapping" the device identity.

Because LMK wipes the process state so aggressively, when the user eventually lands on your page or switches back, the session continuity is broken. Even if you have a CNAME or 1st-party cookies, the "hand that holds the cookie" (the process state) has been severed.

For Meta's servers, this often looks like a completely new, isolated request with no context. This is why even with a "perfect" CAPI setup, you are still seeing a 35-40% "hidden leakage" in Android-heavy markets.

Closing Thoughts

On Android, we need to fight this physical truncation of signals at the OS level, not just a browser-level cookie issue.

If you are running high-volume Android traffic, I’d suggest looking deeper into your Edge-side logic injection. You need to find a way to align the identity before the OS has a chance to execute the process. Just hope this technical deep-dive helps some of you understand why your Meta events numbers won't match Shopify's.