Quick Answer: Pinterest CAPI can report purchases correctly while still failing to match them to your product catalog, because the item_id in your conversion event and the item_id in your catalog feed use different formats. Most Shopify catalogs use a compound ID like shopify_US_[product_id]_[variant_id], not a raw variant ID, and Pinterest won't match anything else.

Key Takeaways

• Pinterest can count a purchase correctly while completely failing to match it to a catalog item, since conversion counting and catalog matching are two separate systems.
• The most common cause is sending a raw Shopify variant ID in the CAPI event when the catalog uses a compound ID combining a locale prefix, the product ID, and the variant ID.
• Product IDs, variant IDs, and SKUs are not interchangeable for matching purposes. Pinterest catalogs are almost always variant-based, so a product-level ID won't resolve to a specific variant.
• Running both the Pinterest Tag and CAPI with different item_id formats creates a mismatch that's especially hard to diagnose, since both signals look individually plausible on their own.
• The fix is to trace one variant end-to-end, from Shopify's product and variant IDs to the exact string in your catalog feed, and confirm your CAPI payload matches it character for character.

What does a Pinterest CAPI product ID mismatch actually mean?

It means the identifier in your conversion event and the identifier in your catalog feed are different strings, even when they refer to the same product, so Pinterest can't connect the two.

When Pinterest receives a conversion event, ViewContent, AddToCart, Checkout, or Purchase, it tries to match the item identifier inside that event to a corresponding entry in your Pinterest catalog. That catalog is built from a product feed, typically synced from Shopify, where each item has an item_id field Pinterest uses as its reference point. If the value sent in your CAPI event doesn't exactly match the value in that feed, Pinterest sees two unrelated strings, not two references to the same product.

The consequences are specific rather than obvious. Without a catalog match, Pinterest can't attribute the conversion to a specific product or Shopping Ad. Dynamic product ads lose the behavioral signal they need to retarget viewers of that exact item. Product-level reporting shows blank or aggregated data instead of item-level breakdowns. And because Pinterest's optimization relies on matched conversion signals, campaign performance suffers from signal starvation even while overall conversion counts look completely normal, which is exactly what makes this hard to catch in standard reporting.

How does Pinterest match conversion events to your Shopify catalog?

By comparing the item_id string in the conversion event against the item_id string in the catalog feed, with zero tolerance for variation in prefix, separators, or ordering.

Your Pinterest catalog is a structured list of items with fields including title, description, price, availability, image, and critically, item_id. The most common format for Shopify-sourced feeds combines a market locale, the product ID, and the variant ID into one compound string, for example shopify_US_7890123456_1234567890, not a raw Shopify ID on its own. When a CAPI event sends just 1234567890 as the item_id, Pinterest looks for an exact match to that string in the catalog, doesn't find one, and the match fails silently, with no error surfaced anywhere in standard reporting.

What are the four common product ID mismatch patterns on Shopify?

Raw variant IDs sent instead of the compound format, product IDs sent instead of variant IDs, SKUs that don't match catalog values, and mismatched formats between the Pinterest Tag and CAPI running side by side.

Events send raw variant IDs, the feed uses the compound format. This is the most common pattern. A server-side integration pulls the variant ID directly from Shopify's order object, the natural thing to do, but the compound catalog format isn't obvious from Shopify's data model and most documentation doesn't emphasize it. Symptom: purchase events arrive normally, but item-level reporting stays empty and dynamic retargeting doesn't improve.

Events send product IDs instead of variant IDs. Shopify has two levels of identification, the product as a whole and each purchasable variant. Pinterest catalogs built from Shopify feeds are almost always variant-based, since price and availability differ by variant, so a product-level ID resolves to the product group at best and can't identify the specific variant. Symptom: some higher-level reporting looks fine, but variant-level matching and Shopping Ad optimization both fail.

Events send SKUs that don't match catalog item_ids. This works only if the catalog also uses SKUs as item_ids, rarely true for Shopify-sourced feeds, and Shopify variants can have blank or duplicate SKUs that change over time, creating partial matching that's hard to diagnose. Symptom: inconsistent matching, some items report correctly, others show no match despite recorded purchases.

The Pinterest Tag and CAPI send different formats. When both are active, the browser pixel might send a raw variant ID while the server event sends the compound format, or vice versa, and Pinterest receives two signals for the same conversion with different identifiers. Symptom: item-level reporting that varies inconsistently by channel, and deduplication that appears to work at the event level while failing at the item level.

How do you choose one ID standard and enforce it everywhere?

Confirm the exact format your catalog actually uses first, then construct that same string from Shopify order data, and apply it consistently across both CAPI and the browser tag.

Identify your catalog's actual format. Before changing anything, check the item_id field for a specific product variant in your Pinterest catalog feed file or Ads Manager's catalog diagnostics. Confirm the format rather than assuming it.

Map that format to your Shopify order data. For a compound format, you need the market locale prefix, the Shopify product ID, and the Shopify variant ID, all available on each order line item.

Update your CAPI event payload. For Purchase and AddToCart events, the items array should use the constructed identifier, not the raw variant ID, formatted as a string with the full prefix and both ID components, no variation in separators or ordering:

>{
  "event_name": "purchase",
  "event_time": 1710000000,
  "event_name": "purchase",
  "event_time": 1710000000,
  "custom_data": {
    "currency": "USD",
    "value": 129.00,
    "items": [
      {
        "item_id": "shopify_US_7890123456_1234567890",
        "quantity": 1,
        "item_price": 129.00
      }
    ]
  }
}

Apply the same format to the Pinterest Tag. If the browser tag runs alongside CAPI, mismatched formats between the two reintroduce the exact problem you just fixed server-side.

Handle multi-variant orders correctly. Every line item in a multi-item order needs its own correctly formatted item_id. A single product-level ID for a multi-variant purchase won't match any catalog entry correctly.

Should you use variant IDs, product IDs, or SKUs?

Variant IDs, combined into the compound catalog format, are the reliable default for most Shopify stores. Product IDs and SKUs each have narrower, more fragile use cases.

Variant ID vs. Product ID vs. SKU for Pinterest Matching

How do you test and validate the fix?

By tracing one specific variant end-to-end and confirming the constructed identifier matches the catalog character for character, not by assuming the fix worked.

Trace a single variant. Find its variant ID and product ID in Shopify, construct the expected compound item_id, and confirm that exact string exists in your Pinterest catalog feed.

Place a test order and inspect the payload. Confirm the item_id in the CAPI event matches the catalog value exactly.

Check Pinterest Events Manager for item-level matching. A confirmed catalog match shows item-level data, not just aggregate totals.

Verify pixel and CAPI use the same format. Trigger a test AddToCart from the browser and compare its item_id against the CAPI payload's item_id. They need to be identical.

Monitor item-level reporting after the fix. Over the following days, watch for item-specific data to populate in Shopping campaign analytics.

How do you prevent mismatches from coming back?

By documenting the canonical format, treating tracking changes as requiring QA, and watching for anything that silently changes catalog configuration.

Document your canonical item_id format, including exactly where each component comes from in Shopify, so anyone touching tracking or feed configuration knows the standard before changing anything.

Treat tracking changes as requiring QA. Any change to your theme, feed management tool, or server-side setup should include tracing one variant through the full pipeline before rolling out.

Watch for new feed tools or catalog reconfigurations. Switching feed apps, changing catalog settings, or adding new market locales can silently change the item_id format your catalog uses, and if CAPI events don't update to match, mismatches return immediately.

Common mistakes to avoid

• Assuming conversion counts confirm catalog matching. They're separate systems. Correct purchase counts tell you nothing about whether item-level matching is working.
• Using the raw Shopify variant ID because it's the natural field to pull from the order object. The compound catalog format isn't obvious from Shopify's data model, and this is the single most common cause of mismatches.
• Fixing CAPI without checking the browser tag, or vice versa. Mixed formats between the two reintroduce the same failure even after one side is corrected.
• Assuming SKUs are a safe fallback identifier. Blank and duplicate SKUs are common enough on Shopify that SKU-based matching is fragile unless hygiene is genuinely strict across every variant.
• Changing feed tools or catalog settings without re-verifying the item_id format. A silent format change on the catalog side breaks matching even if nothing changed in your CAPI setup.

How does Aimerce handle both sides of this problem?

By treating catalog structure and CAPI event formatting as one pipeline instead of two separately maintained pieces, so the item_id format stays consistent by design rather than by coordination.

On the catalog side, Aimerce's catalog enrichment cleans and structures product data before it reaches Pinterest, keeping item_ids formatted consistently while also optimizing titles and descriptions for Pinterest's visual search. On the conversion side, Aimerce's Pinterest server-side tracking generates purchase events directly from Shopify's order creation signal, constructs item_ids in the exact format the catalog uses, and delivers them to Pinterest CAPI with complete line-item data and hashed customer identifiers for probabilistic matching. Because both sides come from the same system, the format doesn't have to be manually kept in sync across two separate tools.

FAQ

What is the correct item_id format for Pinterest CAPI events on Shopify? For most Shopify stores synced through Pinterest's native integration or a standard feed tool, the format typically combines a market locale, the Shopify product ID, and the Shopify variant ID into one compound string. Confirm the exact format your specific catalog uses before assuming it, since Pinterest treats the id field as an arbitrary string defined by whatever feed source generated it.

Why are my Pinterest conversions recording but not showing item-level data? This is the classic symptom of a product ID mismatch. Pinterest received and counted the conversion event but couldn't match its item_id to a catalog entry. Item-level reporting, dynamic retargeting, and product-level optimization all depend on that catalog match succeeding.

Should I use the same item_id format for the Pinterest Tag and Pinterest CAPI? Yes. If the browser-based Pinterest Tag and server-side CAPI events use different formats, Pinterest receives conflicting signals for the same conversions, and both touchpoints need to use the identical format your catalog feed uses.

Does server-side tracking for Pinterest automatically fix product ID mismatches? No. Server-side tracking improves delivery reliability, but it doesn't automatically construct item_ids in the format your catalog expects. That has to be explicitly configured from the product ID and variant ID available in the Shopify order record.

Can I use SKUs as item identifiers for Pinterest CAPI on Shopify? Only if your Pinterest catalog feed also uses SKUs as item_ids and every variant has a unique, stable SKU. For most Shopify stores this isn't the case, and the compound Shopify ID format is more reliable.

How do I check what item_id format my Pinterest catalog is using? Download your catalog feed file from your feed management tool or Pinterest Ads Manager's catalog section, and find the id or item_id column for any product variant. That value is the exact string your CAPI events need to send for that item.

Is Pinterest CAPI worth setting up for Shopify stores? Yes, particularly for stores running Pinterest Shopping Ads or dynamic retargeting. Without it, purchase events depend entirely on the browser-based Pinterest Tag, exposed to the same ad blocker and browser restriction issues affecting all client-side tracking.

Sources

[1] Pinterest Business Help, "Get started with retail catalogs"

[2] Pinterest Business Community, "Product IDs included in your Add to Cart"

Related reading

• Pinterest Conversion API for Shopify: The Aimerce Advantage
• Why TikTok Isn't Tracking Shopify Purchases (ttclid)
• OpenAI Ads Conversion Events and Deduplication, Explained