How to Fix a Low Meta Catalog Match Rate on Magento 2 (Pixel Product IDs vs Your Catalog)

TL;DR

Start with the number in Commerce Manager: the rate across all catalogs, then per event, over 28 days with up to a 48-hour delay [3]. Take a few IDs Meta couldn't match and look for them in your catalog's id and item_group_id columns. On Magento the pixel's IDs come from one setting plus the product type, and the catalog has to hold the same values. Purchases of configurable products arrive as product_group, so read the Purchase rate on its own.

Key Takeaways

• Meta recommends keeping catalog match rate above 75%, and ideally above 90% [3].
• Several catalogs on one pixel split the rate: Meta's example shows 50% for one catalog while it's 90% across both [2].
• The Meta pixel's Product Identifier [ ID / SKU ] sits in Meta Pixel Tracking Settings, and GA4's Child vs Parent option doesn't reach Meta [1].
• Since v1.15.5 (July 29, 2025), configurable, bundle and grouped products go to Meta labeled product_group [1].
• Meta matches product IDs to the catalog's id and product_group IDs to item_group_id [4].
• After a change, wait 48 hours before reading the rate, then judge the trend across the 28-day window [4].

Where does Commerce Manager show the Meta catalog match rate?

In Commerce Manager > Catalog > Events, for the catalog connected to your pixel [3]. Meta defines the number this way: "Catalog match rate is the percentage of content IDs in events Meta receives from your website or app (via your pixel or app SDK) that match products in a connected catalog" [2].

"Match rate is shown for a 28 day timeframe with a 48-hour delay" [3], so what you see today is mostly last month's events. The main rate covers the catalog you opened, and Meta puts a second one beside it, "showing events that match products in at least one catalog connected to this dataset" [3]. Below them, each event carries its own: "Click on an event such as view, add to cart or purchase to view match rate for that specific event" [3].

Event counts on this screen run lower than in Events Manager, because "Commerce Manager only shows events that can be matched to products in this catalog" [3]. That gap is normal.

Meta's target is to keep the rate "above 75%, and ideally above 90%" [3]. If the screen says the rate is paused, that's a different issue: "Match rate may be paused if you don't use a catalog for advertising in 28 days" [4].

Find the low rate, then the event behind it

Work through Commerce Manager in this order:

1. Compare the catalog rate with the all-catalogs rate. Meta's example: 100 content IDs, 50 matching Catalog 1 and 40 matching Catalog 2, and "The match rate for Catalog 1 is only 50%, despite being 90% across both catalogs" [2]. A store with one catalog per store view or per country can see this pattern, and no identifier setting fixes it. Meta's advice is "keeping all your products in one catalog" [2].
2. Open ViewContent, Add to cart and Purchase separately. All three low at about the same level points at the identifier. A healthy product-view rate next to a weak Purchase rate is the product_group case covered further down.
3. Download the issues report. Under Critical issues and Warnings, "Click Download issues report on the right to download a report containing samples of each issue" [3]. Take three IDs from it.
4. Find those IDs on both sides. Search the catalog's id and item_group_id columns for each one, then look the product up in Magento under Catalog > Products, where the grid shows both the product ID and the SKU.

If you've ever pasted an ID from that report into the catalog search and got nothing back, that's the mismatch this article traces.

Consent decides how many events reach Meta in the first place: with Magento's Cookie Restriction Mode on, the pixel waits for the shopper to accept the cookie banner, and since v1.17.4 the addon's server events wait for consent too, but only when Require Visitor Consent for Server-Side Events is switched on [1], as our guide to server-side tracking and consent explains.

What does the extension put in content_ids?

On GA4 PRO, the Meta (Facebook) pixel is configured under Admin → WeltPixel → Google Analytics 4 eCommerce PRO GTM Settings → Meta Pixel Tracking Settings → Meta Pixel Tracking Configuration [1]. The one field that decides content_ids there is Product Identifier [ ID / SKU ]: "Choose the Product Identifier type you want to send to Facebook for enabled events" [1]. It arrived in v1.12.9 (September 5, 2023) [1], and a store that never changed it shows ID. The Meta pixel is a PRO feature (see our Standard vs PRO comparison).

GA4's Child vs Parent switch is a Google Analytics setting: "Choose whether to send the Child or Parent product identifier to Google Analytics" [1]. The Meta section has no such option, so a store that set GA4 to Child still sends Meta the parent. That switch matters for Google, and our guide to product feed data vs GA4 item data covers that side.

What the pixel sends then depends on the product type:

• A simple product goes out under its own ID or SKU, with content_type set to product.
• A configurable, bundle or grouped product goes out as the parent's ID or SKU, with content_type set to product_group. That's the v1.15.5 change (July 29, 2025): "the correct content_type parameter (product vs product_group) is sent for Configurable, Bundle & Grouped vs Simple Products. Previously, product was sent for all product types" [1]. The v1.15.7 release (September 2, 2025) restated it for configurable products [1].

For configurable and bundle products it applies on every product event, purchases included. A shopper who picks a red medium shirt and checks out still reaches Meta as the parent shirt.

Which catalog column does each ID have to equal?

Meta's troubleshooting page asks that content_ids "exactly match the IDs (or group IDs) in your catalog", with product "if your pixel is sending individual IDs" and product_group "if your pixel is sending group IDs (item_group_id in your catalog)" [4]. Meta's catalog reference adds that id should be "the item's SKU if possible" and "must exactly match the content ID for the same item in your Meta Pixel", and that item_group_id takes "the same group ID in this field for all variants of the same product" [5].

So simple products have to match id, and parents have to match item_group_id. Match the setting to whatever your catalog holds:

• If id holds child SKUs and item_group_id holds the parent SKU, set Product Identifier to SKU. Configurable products then match at group level and simple products on id.
• Catalogs keyed on Magento's numeric product IDs in both columns line up with ID, the setting you probably already have.
• With no item_group_id at all, configurable events have nothing to match, whichever option you pick. Add the group column to the catalog.
• When the catalog uses IDs neither option produces, such as a store code glued to the SKU, no setting in Magento will match it, and the catalog source is what has to change.

Since the WeltPixel Product Feed builds Google feeds only [7], your Magento Facebook product feed comes from the data source you connected to the catalog in Commerce Manager, and that's where its columns get fixed. For where the identifier field sits among the other pixels, see our guide to setting up the Meta pixel and the other ad pixels from one admin.

Why do purchases of configurables arrive as product_group?

Because the extension labels by product type, and a configurable product is a group. Meta's catalog-ads guide draws the line by event instead. It says that if "the page is about a group of related products that vary by size, color, and so on", you use product_group, and "A common use case is a ViewContent page where the user has not chosen a size yet. Do not use product_group with AddToCart or Purchase" [6]. And: "All AddToCart and Purchase events should use content_type=product because people buy specific products" [6].

The extension sends the parent with product_group on add to cart and purchase for configurable and bundle lines, the same as on the product page. Meta's pages don't say how a parent-level Purchase matches a catalog whose id column holds child SKUs, and we haven't measured it. So treat the per-event rates as your evidence. On a store that sells mostly configurable products, a Purchase rate well below the ViewContent rate points here, and under Meta's troubleshooting rule a group-level ID has to match an item_group_id holding the same parent ID or SKU the pixel sends [4].

If you also run the Meta Conversions API addon, its server events follow the same product_group rule (the v1.15.5 entry says the change also ships in the Meta Conversions API Addon [1]) and use the same Product Identifier, so one catalog fix covers both; the addon itself is covered in our Meta Conversions API guide for Magento 2.

After the switch: 48 hours, then 28 days

Make one change, then give Meta's window time to show it. On illustrative dates, with the 48-hour delay, the rate Commerce Manager shows on Black Friday, November 27, covers roughly October 29 to November 25, so October 28 is the latest change date that leaves the whole window on the new IDs.

1. Change Product Identifier, save the configuration and flush the Magento cache, as the user guide says after each pixel change [1].
2. With the test events tool in Events Manager open [4], view a simple product, view a configurable product and place a test order. Check content_ids and content_type on each event against the catalog row.
3. Wait. Meta says the rate "may take up to 48 hours to reflect any changes or fixes you make" [4].
4. Read the trend over the following weeks. Because the window is 28 days [4], old and new IDs sit side by side until the old ones age out.

FAQ

Is catalog match rate the same as Event Match Quality?

No. Catalog match rate is the share of content IDs that match products in a connected catalog [2]. Event Match Quality scores the customer information on events.

Will switching GA4's Child vs Parent setting fix my Meta match rate?

No. That option sends "the Child or Parent product identifier to Google Analytics" [1], and the Meta pixel doesn't read it. Change the Meta section's Product Identifier or the catalog.

Why does Commerce Manager say my match rate is paused?

Meta may pause it when a catalog hasn't been used for advertising in 28 days [4]. Commerce Manager shows a notice on the Events tab when that happens.

Set the Meta pixel's Product Identifier on the Magento 2 Google Analytics 4 extension to match your catalog's id and item_group_id columns, then check the match rate per event in Commerce Manager after 48 hours.

Sources

1. WeltPixel Google Analytics 4 User Guide and Change Log (Meta Pixel Tracking Settings; General Configuration; v1.12.9, v1.15.5, v1.15.7 and v1.17.4 entries), retrieved October 14, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
2. About catalog match rate, Meta Business Help Center, retrieved October 14, 2026, https://www.facebook.com/business/help/1183006658734497
3. View catalog match rate for Meta Advantage+ catalog ads, Meta Business Help Center, retrieved October 14, 2026, https://www.facebook.com/business/help/946671458738854
4. Troubleshoot catalog match rate issues, Meta Business Help Center, retrieved October 14, 2026, https://www.facebook.com/business/help/644889989181423
5. Catalog fields reference, Meta for Developers, retrieved October 14, 2026, https://developers.facebook.com/documentation/ads-commerce/catalog/reference
6. Dynamic product audiences: choosing the right content_type, Meta for Developers, retrieved October 14, 2026, https://developers.facebook.com/documentation/ads-commerce/marketing-api/audiences/guides/dynamic-product-audiences
7. WeltPixel Product Feed User Guide, retrieved October 14, 2026, https://docs.weltpixel.com/ProductFeed/User-Guide-WeltPixel-Product-Feed.html