Your Events Manager shows purchase events firing green. Your Meta pixel is installed and verified. But your Dynamic Product Ads are serving the wrong items—or worse, showing a generic fallback product that doesn’t exist in your catalog. This is the content_ids mismatch: over 60,000 WooCommerce stores are sending the wrong product identifier in purchase events, while their ad platforms wait for a value that never arrives.

The events are correct. The identifier is wrong. And the difference is invisible until you check your catalog match rate.

The content_ids Mismatch Nobody Warned You About#

Dynamic Product Ads on Facebook, TikTok Shopping, and Google Dynamic Remarketing all work the same way: they receive a product identifier from your purchase event, look it up in your product catalog, and serve the matching ad creative. When those identifiers don’t match, the platform either shows the wrong product or falls back to generic creative.

What is content_ids? It’s Meta’s parameter for product identifiers in purchase events. Every product in your Facebook Product Catalog has an “id” field. Your purchase events need to send that exact same value in content_ids. If they don’t match, Meta can’t link the event to a catalog product.

Here’s where WooCommerce creates the problem. Every WooCommerce product is a WordPress post. It has a post ID—a number automatically assigned by WordPress (e.g., 4521). It also has a SKU—a product code you set manually (e.g., SHOE-BLK-42). These are different values.

Most standard tracking plugins send the WordPress post ID as content_ids. Most catalog feeds export using SKU. The result: your event says “product 4521” but your catalog knows “SHOE-BLK-42”. No match. Dynamic Ads serve generic creative—or the wrong product entirely.

According to Meta’s own documentation, the content_ids parameter should contain the same IDs uploaded in your catalog. If you send product IDs that don’t match your catalog, your Dynamic Ads may not show correctly.

You may be interested in: Your WooCommerce Pixel Is Counting the Same Conversion Twice

Why Plugins Default to Post ID#

It’s not a bug—it’s a default. WordPress post IDs are always available. SKUs require the store owner to populate them consistently, and not every WooCommerce store does. So plugins take the path of least friction: they send the post ID because it’s guaranteed to exist.

The problem compounds with variable products. A WooCommerce variable product (a t-shirt in sizes S, M, L) has a parent post ID and a separate variation post ID for each size. Catalog feeds typically export the parent product with the parent SKU. The plugin fires the event with the variation post ID. The mismatch is now two levels deep: wrong ID type, and the wrong product level entirely—variation post ID versus parent SKU.

This is why fixing it in a plugin isn’t straightforward. The plugin would need to know which ID format your specific catalog uses, for each platform, and then resolve variation IDs back to parent SKUs when appropriate. That logic doesn’t ship by default.

Meanwhile, 31.5% of your visitors are running ad blockers (Statista, 2024) that block browser pixels entirely—so the events that do fire need to carry the right data. A misfired identifier compounds an already incomplete signal.

How to Diagnose the Mismatch#

There are three places to check, depending on which platform you’re troubleshooting.

Meta Events Manager: Open your pixel, click on Purchase events, and look for the Matched Products percentage. A healthy catalog integration shows 80%+ product match. If you’re seeing 0–20%, you have a content_ids mismatch. You’ll see which IDs were sent versus which were found in your catalog.

TikTok Events Manager: Under Diagnostics, the platform shows item_id match rates. TikTok’s equivalent of content_ids is item_id—same principle, different parameter name. Low match rates break TikTok Shopping ads in exactly the same way.

Google Tag Assistant: For Dynamic Remarketing, inspect the ecomm_prodid value being sent on your thank-you page. Then cross-reference it with your Google Merchant Center feed’s item_id field. Google requires ecomm_prodid values to match Merchant Center feed IDs exactly—any mismatch results in no product shown in the ad (Google Ads Help, 2025).

The performance cost is concrete. Facebook Dynamic Product Ads generate 34% higher click-through rates when catalog matching is working correctly (Meta Business Help Center, 2025). That 34% gap isn’t from better creative—it’s the difference between the actual product and a generic fallback image.

You may be interested in: Why GA4 Data-Driven Attribution Silently Fails Small WooCommerce Stores

What the Correct Mapping Looks Like#

The rule is simple: send the same value in content_ids that appears in your catalog’s “id” field.

If your Facebook Product Catalog is built from a WooCommerce feed that uses SKU as the product ID, your purchase events need to send SKU in content_ids. If your feed uses the WooCommerce post ID, send post ID. The catalog and the event must speak the same language.

For variable products, it gets more specific. Some catalog setups import each variation as a separate catalog item with the variation SKU as the ID. Others import only the parent product with the parent SKU. You need to know which your catalog uses—then send that exact identifier in the event.

• Simple products: Send SKU if your catalog uses SKU; send post ID if your catalog uses post ID.
• Variable products: Determine whether your catalog has variation-level items (send variation SKU) or parent-level items (send parent SKU). Post IDs almost never match catalog IDs for variable products.
• TikTok item_id: Same logic—match your TikTok catalog feed’s identifier field exactly.
• Google ecomm_prodid: Must match the item_id in your Google Shopping Merchant Center feed.

WooCommerce product variations each have a separate post ID distinct from the parent product—and most catalog feeds export the parent SKU (WooCommerce Developer Documentation, 2025). For variable-product stores, the mismatch is systematic, not occasional.

The Architecture That Fixes It Once#

Browser-side plugins fix this per plugin, per update cycle, per platform. Every time a plugin updates, you’re checking the identifier mapping again. Every time you add a new ad platform, you’re solving the same problem in a different configuration panel.

Server-side tracking with Transmute Engine™ solves this at the data layer. The Transmute Engine is a dedicated Node.js server that runs first-party on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures the WooCommerce order object—including both post ID and SKU for every product—and sends it via API to your Transmute Engine server. The server then maps the correct identifier to each platform’s outPIPE based on your catalog configuration. One decision. Every platform gets the right ID, every time.

60,000+ WooCommerce stores are running catalog ads with wrong product identifiers. The fix isn’t a plugin tweak—it’s sending the right data from the right layer.

Key Takeaways#

• Dynamic Product Ads on Facebook, TikTok, and Google require purchase events to send a product identifier that matches exactly what’s in your product catalog.
• Most WooCommerce tracking plugins send WordPress post IDs by default, while most catalog feeds export using SKU—these are different values and the mismatch is silent.
• WooCommerce variable products add a second layer: variation post IDs vs. parent SKUs in catalog feeds.
• Diagnose via Meta Events Manager matched products percentage, TikTok item_id match rate, or Google Tag Assistant vs. Merchant Center feed comparison.
• Server-side tracking reads WooCommerce order data directly and maps the correct identifier per platform—one configuration, not a repeated per-plugin fix.

If your Dynamic Product Ads aren’t serving the right items, the pixel isn’t the problem—the product identifier is. See how Seresa fixes this at the data layer.