the silent killer of Meta match quality: catalog and event ID drift .
your match quality scores are dropping and you don't know why. odds are your catalog is fed by one tool and your conversion events by another — and they don't agree on what a SKU is.
Match quality is Meta’s score for how reliably your conversion events line up with the people who saw your ads, the products in your catalog, and the offline data you ship back. it’s graded as Excellent, Good, Fair, or Poor on a per-event basis, and it has a direct, measured effect on bidding efficiency.
Most teams treat it as a customer-data problem — make sure to send hashed email, hashed phone, IP, user-agent, click ID. that helps. but for ecommerce, the dimension that quietly tanks match quality more often is product identity: does the SKU you sent in the Purchase event match the SKU in your Commerce Catalog?
Half the stores we onboard have this broken without realizing it.
How the drift happens
Picture the typical Shopify stack. you have:
- a catalog feed sent to Meta Commerce Manager — built by Shopify’s native Facebook channel, by an app like Flexify, or by a feed manager.
- a conversion event source — Shopify’s native pixel/CAPI integration, or a server-side wrapper like Stape or Elevar.
Each of these tools has its own opinion about what the canonical “product ID” is. and Shopify products carry no fewer than five candidate identifiers any of them could pick:
- the Shopify
product_id(a numeric like8472619038) - the Shopify
variant_id(also numeric) - the merchant SKU (
SW-MERINO-CHAR-M) - the variant
handle - the GTIN, if set
Your catalog tool might use the merchant SKU. your pixel/CAPI tool might use the variant_id. Meta receives both and has no way to know they’re the same product. match quality drops, and Advantage+ campaigns optimize against an incomplete picture of what actually sold.
retailer_id in Commerce content_ids on Purchase content_ids on Purchase How to find it (in 90 seconds)
- open Commerce Manager → Catalog → Events.
- look at “Content matched to catalog” for the last 7 days. if it’s below 80%, you have drift. below 50% is critical.
- open Events Manager → your dataset → Diagnostics. filter for “Content IDs not found in catalog”. expand a sample event. compare the
content_idsvalue to what’s in your catalog feed.
If they don’t match, you’ve found it. now the question is which tool is wrong.
Shopify’s pixel sometimes emits content_ids in the form shopify_PRODUCTID_VARIANTID. if your catalog uses raw variant_id, this format won’t match. always normalize to one canonical format across both feed and events.
The fix
Pick one canonical product identifier and use it everywhere. our recommended order of preference:
- GTIN, if every product has one. cross-retailer compatible, future-proof, recognized by every ad platform’s catalog.
- Merchant SKU, if every product has a unique one. human-readable, stable across Shopify migrations, easy to debug.
- Shopify variant_id as a last resort. works, but breaks if you ever migrate platforms or rebuild a product.
Whichever you pick, both your catalog feed’s id field and your conversion event’s content_ids field need to use the same value. that’s the entire fix. it’s just hard to enforce when those two fields are produced by two different apps that don’t talk to each other.
Why a unified pipeline matters
This is, candidly, why we built Maximo as a single product covering both the catalog and the tracking. the typical Shopify stack solves them with two separate apps that have no knowledge of each other — one ships the catalog, the other ships events, and the merchant is left to manually verify they agree on identifiers.
When the same system generates both, ID consistency is enforced by construction. we use the same canonical identifier (you choose: GTIN or SKU) across the catalog feed sent to every channel and the conversion events sent server-side. match quality stops being something you have to audit; it’s a property of the pipeline.
Stats are aggregated across our private beta cohort, fall 2025 – spring 2026.