GTM4WP Bug: Android Facebook & Instagram Purchases Weren't Tracked

A WooCommerce store using PixelFly asked us a simple question: why does WooCommerce show more orders than our tracking does? Meta Ads and GA4 were short too. Not by a couple of orders, but by about a quarter of them.

We went through the logs. The cause wasn't ad blockers, and it wasn't the server. It was a bug in GTM4WP (Google Tag Manager for WordPress), one of the most popular tracking plugins for WooCommerce. If your store uses it and runs Facebook or Instagram ads, you're probably losing purchases right now.

Here's what we found, how to check your own store, and the one-update fix.

What We Saw in the Logs

PixelFly logs every tracking hit that reaches your server container, along with the browser it came from. So we split one day of the store's traffic by browser and followed each group from page view to purchase.

The pattern was impossible to miss:

• Facebook app on iPhone: 19 checkouts started, 18 tracked. 14 thank-you pages, 14 purchases tracked.
• Facebook app on Android: 14 checkouts started, 0 tracked. 5 thank-you pages, 0 purchases tracked.
• Instagram app: the same. Zero.

Page views and scroll events from those same Android shoppers did arrive, even from the thank-you page. So Google Tag Manager was running fine. Only the e-commerce events were missing.

Then we counted unique orders over two and a half days:

Every order placed inside the Facebook or Instagram app on Android was invisible. For this store that was 27% of all orders. For a shop where most ad traffic comes from Android phones, which is most shops in Bangladesh, the share can be much higher.

The Cause, in Plain Words

Every time a browser asks your website for a page, it sends a few short notes along with the request. They're called headers. One of them, X-Requested-With, normally means "this is a background request", like when your cart updates without reloading the page. GTM4WP watches for it, so it doesn't add tracking data to those background requests.

Here's the problem. When someone taps your ad inside the Facebook or Instagram app on Android, your store opens in the app's own built-in browser. That browser adds the same X-Requested-With note to every page, with the app's name written in it: com.facebook.katana for Facebook and com.instagram.android for Instagram.

Think of it like a sticker on an envelope. GTM4WP had one rule: "if the envelope has a sticker, it's a background request, so don't put the purchase details inside." It only checked whether there was a sticker, never what the sticker said. The Facebook app puts its own sticker on every envelope, so GTM4WP left the purchase details out of every page, including the thank-you page.

No purchase on the page means none of your purchase tags fire: not the Meta Pixel, not GA4, not Google Ads. Server-side tracking gets nothing either, because it can only forward what the browser sends. Product views still worked, because GTM4WP adds those later with JavaScript. That's what makes this bug so easy to miss: your numbers don't drop to zero, they just quietly come up short. The person who reported it described the symptom well: in GA4 it "shows up as paid social campaigns with almost no conversions."

The GTM4WP maintainer confirmed the bug in that issue; the faulty check goes back to 2022. iPhone shoppers aren't affected: the Facebook and Instagram apps on iOS don't send that header, and neither do normal browsers like Chrome.

The Fix: Update GTM4WP to 2.0.6

The plugin's maintainer fixed it in GTM4WP 2.0.6, released on 12 October 2026. It's the first item in the changelog.

We checked older versions too. The same check is in every version we looked at, from 1.20 through 2.0.5. If you're on anything below 2.0.6, you're affected. Updating takes a minute:

1. In WordPress, go to Plugins → Installed Plugins.
2. Find GTM4WP and update it to 2.0.6 or later.
3. Clear your page cache (LiteSpeed Cache, WP Rocket or your host's cache).
4. If any GTM trigger matches the page title or the site search term, check that it still works: 2.0.6 sends them as plain text now, so & becomes &.

Updating fixes tracking from that moment on. Purchases that were already lost can't be sent again.

How to Check If Your Store Was Affected

In GA4: go to Reports → Tech → Tech details, choose Browser, and compare sessions with purchases for Android Webview. Plenty of sessions and almost no purchases is the giveaway.

In PixelFly: open Event Logs for your container. Look at page views of your thank-you (order-received) page where the user agent contains FB_IAB (Facebook app on Android) or Instagram. If those page views arrive but no purchase arrives with them, the bug was hitting your store.

In WooCommerce: compare your order count for a week with the purchases in Meta Events Manager or GA4. A gap of 20% or more on a store with lots of Facebook traffic is worth a closer look, and this bug is a likely cause.

Why PixelFly Caught It

Most tracking tools only show you totals: so many purchases today, so many yesterday. When the total is short, you're left guessing. PixelFly also logs each hit that reaches your container, with the event, the page, the browser and the response. That let us prove two things quickly: our own pipeline counted everything it received, and the missing purchases never left the shopper's phone. Instead of guessing, the store knew exactly what broke and how to fix it.

Our Backup: PixelFly Also Sends the Purchase From Your Server

Updating GTM4WP fixes this bug. But browser tracking will always have weak spots: ad blockers, a shopper who closes the tab, a payment page that never sends them back, the next plugin bug. So the PixelFly WordPress plugin (version 1.3.9 and later) doesn't rely on the browser alone. It also sends every website order straight from WooCommerce:

• Never counted twice. PixelFly matches the browser purchase and the server copy by order number, so each order is counted once.
• The right shopper and the right ad. The plugin saves the shopper's Facebook and Google IDs at checkout, so Meta and GA4 can match the backup purchase to the right person and campaign.
• Safe with COD. With COD Order Protection, unconfirmed COD orders are still held until you confirm them. The backup never sends them early.
• Works with GTM4WP. Keep GTM4WP for your browser tags and just turn off the PixelFly plugin's own DataLayer.

To set it up, install the plugin, add your PixelFly API key and, for an sGTM container, fill in the sGTM Connection. "Send Purchase from Server" is on by default.

Bottom Line

If your WooCommerce store runs Facebook or Instagram ads and uses GTM4WP, update to 2.0.6 today. It takes a minute, and it brings back purchases that Meta, GA4 and your server-side tracking have been missing. Meta's ads also optimise better when they can see all your sales. Then add a server-side backup, so the next browser problem doesn't cost you sales without anyone noticing.

Thanks to @sw33tr for reporting the bug and to the GTM4WP maintainer for fixing it quickly.

Sources

• GTM4WP changelog — version 2.0.6 (12 October 2026)
• GitHub issue #477 — WooCommerce data layer (incl. purchase) is dropped in Android in-app browsers (Facebook, Instagram)