Dynamic product ads deliver 34% lower cost per acquisition than standard ads (Meta, 2025). But here’s the thing — that performance depends entirely on one invisible handshake: the product ID your pixel fires must match the product ID in your catalog feed. Every major WooCommerce tracking plugin uses a different default product identifier. PixelYourSite sends raw post IDs. Facebook for WooCommerce prepends wc_post_id_. Pixel Manager recommends post ID but offers SKU. When these don’t align with your catalog feed, dynamic remarketing breaks silently across every platform — no error messages, just wrong products or empty ad slots.

The Silent Product ID Mismatch Nobody Warns You About

Dynamic remarketing works by matching two data streams. Stream one: the pixel event that fires when a visitor views or purchases a product on your store. Stream two: your product catalog feed uploaded to Facebook, Google Merchant Center, or TikTok. Both streams include a product identifier. When they match, the platform shows that exact product in ads. When they don’t, the system either shows wrong products or shows nothing at all.

The problem? WooCommerce has no standard product identifier format across its plugin ecosystem.

Every WooCommerce product has at least three possible identifiers: a WordPress post ID (a unique number like 42), a SKU (an alphanumeric string like BLUE-HOODIE-L), and for variable products, a variation ID (a separate post ID for each size or colour). Each tracking plugin picks a different default. Each catalog feed plugin picks a different default. And nobody tells you they need to match.

Facebook for WooCommerce GitHub issue #809 has documented this problem since 2018 — store owners consistently report that their pixel fires product IDs in one format while their catalog uses another. The result: Facebook surfaces “Products Are Missing From Your Catalogs” warnings, ad delivery degrades, and remarketing campaigns underperform without any obvious cause (Facebook for WooCommerce GitHub, 2018–2025).

Which Plugin Sends What: The Default Product ID Map

Here’s where it gets messy. Each popular WooCommerce tracking plugin has its own default product identifier, and they don’t agree with each other:

PixelYourSite sends raw WordPress post IDs by default. A product with post ID 42 fires as content_ids: ['42'] in the Facebook pixel event.

Facebook for WooCommerce (Meta’s official plugin) prepends a prefix. That same product fires as content_ids: ['wc_post_id_42']. Different format, same product — and Facebook treats them as two different items (GitHub Issue Analysis, 2025).

Pixel Manager for WooCommerce (by SweetCode) defaults to post ID and explicitly recommends it over SKU. Their documentation states that SKUs create debugging issues because they can contain special characters and aren’t guaranteed to be unique across variable products (SweetCode, 2025).

Conversios uses post ID as its default identifier.

GTM4WP sends SKU by default — the opposite of what most other plugins choose.

The pattern is clear: if you switch tracking plugins, your product IDs change format without warning. Every campaign built on the previous ID format breaks immediately. And if you’re running multiple tracking plugins simultaneously — a scenario that creates its own set of conflicts — you could be sending different IDs to the same platform from different scripts.

The Catalog Feed Side of the Equation

The tracking plugin is only half the mismatch. Your product catalog feed — the file uploaded to Facebook Commerce Manager, Google Merchant Center, or TikTok Catalog — has its own product ID settings controlled by a completely separate plugin.

CTX Feed (one of the most popular feed generators) lets you choose between SKU and post ID for the g:id field. WooCommerce Product Feed Pro defaults to post ID. ATUM Export uses its own ID format. Google Listings & Ads sends the WooCommerce product ID.

The mismatch pattern looks like this:

• Your tracking plugin sends 42 (raw post ID) in the pixel event
• Your catalog feed sends BLUE-HOODIE-L (SKU) as the g:id
• Facebook can’t match them — so your dynamic product ads show nothing or show random products

This isn’t a bug in any single plugin. It’s an architectural gap in the WooCommerce ecosystem where two categories of plugins — tracking and feed generation — were built independently with no shared standard for product identification.

You may be interested in: How to Audit Your WooCommerce Marketing Pixels: The 15-Minute Check That Reveals What’s Actually Firing

Variable Products Make Everything Worse

Simple products are complex enough. Variable products add another layer of chaos.

A WooCommerce variable product (like a hoodie in three sizes) has a parent post ID and separate variation IDs for each option. When someone views the large blue hoodie, should the pixel fire the parent ID or the variation ID? The answer depends on which plugin you’re using and which platform you’re targeting.

Facebook requires the specific variation ID for dynamic ads to show the correct size and colour. Google Merchant Center uses item_group_id for the parent and id for the variant. TikTok expects the variation-level ID to match the catalog’s product_id.

If your tracking plugin sends parent IDs and your catalog feed includes variation-level IDs, every variable product in your store has a mismatch. That could be 60–80% of your catalog for stores with size and colour variants.

How to Fix the Mismatch: Aligning Three Systems

Fixing this requires aligning three independent systems. There’s no single button. You need to check each system, pick one canonical ID format, and force all three to use it.

Step 1: Pick Your Canonical Identifier

Use WordPress post ID. It’s always unique, always numeric, always present, and recommended by the most-used plugins. SKUs work if your catalog is immaculate, but post IDs are safer because they’re auto-generated and can’t be duplicated.

Step 2: Configure Your Tracking Plugin

In your tracking plugin’s settings, find the product identifier option and set it to post ID (or “WordPress ID”). If you’re using Facebook for WooCommerce, be aware it adds the wc_post_id_ prefix — you’ll need your catalog feed to use the same prefix format, or switch to a tracking plugin that sends raw IDs.

Step 3: Configure Your Catalog Feed Plugin

In your feed plugin (CTX Feed, Product Feed Pro, etc.), set the g:id or id field to use the same format. If your tracking plugin sends 42, your feed must list 42 as the product ID — not the SKU, not a prefixed version.

Step 4: Verify the Match

Use Facebook’s Pixel Helper browser extension to see the content_ids value on a product page. Then check your catalog in Commerce Manager to confirm the matching product has the same ID. Pixel load order also matters here — if multiple scripts fire, the one that reaches Facebook first determines the content_ids value.

This alignment process must be repeated for every platform: Facebook, Google Merchant Center, and TikTok each have separate catalogs with separate ID fields.

Why This Problem Keeps Coming Back

Even after alignment, the mismatch re-emerges whenever you update a plugin, switch tracking tools, or add a new ad platform. 92% of websites have at least one third-party script impacting performance (HTTP Archive, 2024), and WooCommerce stores typically run multiple tracking and feed plugins simultaneously. Each update can change default ID behaviour without warning.

The root cause is architectural: client-side tracking plugins and catalog feed plugins are independent systems with no shared configuration layer. There’s no central place in WooCommerce that says “this is the canonical product ID format” and enforces it across all outputs.

You may be interested in: Facebook Pixel Not Tracking Purchases on WooCommerce: The 2026 Server-Side Fix

The Architectural Fix: One Pipeline, One ID

Server-side tracking eliminates the product ID mismatch by design. Instead of multiple browser-side plugins each choosing their own ID format, a single server-side pipeline controls exactly what product identifier gets sent to every platform.

Transmute Engine™ is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures WooCommerce events and sends them via API to the Transmute Engine server, which formats and routes them to GA4, Facebook CAPI, Google Ads, TikTok, and more — all using one canonical product ID. The mismatch problem becomes architecturally impossible because one system controls all output.

Key Takeaways

• Dynamic product ads deliver 34% lower CPA — but only when your pixel product IDs match your catalog feed IDs exactly
• Every WooCommerce tracking plugin uses different default product identifiers: PixelYourSite uses raw post IDs, Facebook for WooCommerce adds a wc_post_id_ prefix, GTM4WP sends SKUs
• Catalog feed plugins have their own defaults — creating a two-sided mismatch that breaks dynamic remarketing silently
• Variable products compound the problem — parent IDs vs variation IDs must be consistent across pixel events and catalog entries
• The fix requires aligning three systems: tracking plugin ID format + catalog feed ID format + platform catalog configuration — and re-checking after every plugin update

Stop debugging product ID mismatches across six plugins. See how Transmute Engine sends one canonical ID to every platform from a single pipeline.