Do You Need a PIM? Product Data Is the Agent-Readiness Bottleneck
18% of top retail product pages publish price validity. 13% publish delivery time. 11% publish return days. That is why agents can't transact with you.
A PIM is the least exciting purchase in ecommerce and the one that decides whether half your other projects work. Feeds, marketplaces, translations, international duty, structured data, and now whether an AI assistant can responsibly recommend your product to somebody. All of it runs on the same underlying thing: complete, consistent product attributes with one authoritative home.
Here's the finding that should end the debate about whether this matters. SALT.agency audited 207 product pages from 29 top-traffic retailers, filtered to 141 readable ones, and scored them against what an agent needs to transact[1]:
- 18% published
priceValidUntil - 13% published
shippingDetails.deliveryTime - 11% published
hasMerchantReturnPolicy.merchantReturnDays - 70% had none of the three
- 65% had no GTIN
- 15% returned 403 to the crawler entirely
And the same audit found 99% had price and availability, 99% had an MPN or SKU, and 96% had brand[1]. So this isn't a story about neglected catalogues. It's a story about catalogues that are fine for the last decade's requirements and missing exactly the fields the next one needs.
What a PIM actually is, and what it isn't
A PIM is one authoritative store of product attributes that feeds every channel. Not a DAM (that's assets), not an ERP (that's stock and money), not your platform's catalogue (that's one channel's view of the data).
The distinction that matters practically: a PIM is the place where "material: 100% merino wool" is stored once, and a platform catalogue is where it appears. If you sell on your store, Amazon, Google Shopping and a marketplace, and you've typed that string four times, you don't have a PIM, you have four divergent copies and a future support ticket.
What you get that you can't get from a spreadsheet
- Completeness scoring. Which SKUs are missing which attributes, per channel, as a number you can act on.
- Channel-specific requirements. Google wants certain fields[2], your marketplace wants others, your own PDP wants a third set. One source, three outputs.
- Localisation. Attribute values per locale, not per spreadsheet tab.
- Workflow. Who enriched what, when, and did anyone approve it.
Does this actually impact you? The honest threshold
Most PIM content is written by PIM vendors, so the answer is always yes. It isn't always yes.
You probably don't need one if you have under about 500 SKUs, one sales channel, one language, and you author your own product copy. Your platform's native fields plus discipline will do. Buying a PIM here adds a system and solves nothing.
You probably do if two or more of these are true:
- More than about 2,000 SKUs, or high SKU churn
- Three or more sales channels with different data requirements
- More than one language or market
- Product data arriving from suppliers in inconsistent formats
- Someone whose actual job is maintaining a product spreadsheet
- You're selling internationally and need HS codes and country of origin on everything (see the international piece)
The clearest single tell: if the answer to "where does the authoritative colour value live?" is "depends", you have the problem.
What we found: the platforms' native limits are the real constraint
We read the current documentation on custom attributes for all four major platforms, because the honest first question isn't "which PIM" but "can my platform hold this data at all". The answer varies more than we expected.
Shopify
Metafields are the mechanism, and the limits are documented precisely. Each app can create up to 256 metafield definitions per resource type, and merchants can create up to 256 of their own[3]. Most metafield types cap at 64KB, JSON at 128KB, and list types at 128 items except metaobject references at 256[3].
Two limits bite in practice and neither is the headline number. Only 128 metafield definitions can power smart collections, and only 50 can be used as admin filters on products, dropping to 5 on orders[3]. So you can store far more than you can merchandise or filter on, and that gap is where "we put it in a metafield" stops being a plan.
The variant ceiling moved to 2,048 per product on 15 October 2025[4], which removes one of the historical reasons to model complex products outside Shopify.
Adobe Commerce
Genuinely the strongest native product data model of the four. Attributes, attribute sets, attribute groups, per-store-view values and per-website scope[5]. For a technical catalogue with hundreds of attributes and multiple markets, Magento can often be the PIM.
The cost is that it's a database designed for flexibility, which is why Magento catalogue performance is a specialist discipline.
BigCommerce
Custom fields and modifiers on the Catalog API, workable for moderate complexity[6]. Reaches its limits earlier than Magento and later than a naive Shopify setup.
WooCommerce
Product attributes plus post meta, which means effectively unlimited and completely unstructured. That's the best and worst answer. There's no ceiling and no discipline, and the REST API will happily serve whatever chaos you created[7]. Woo catalogues drift faster than any other platform we look at, for exactly that reason.
The finding
Native attribute storage is rarely the binding constraint. Governance is. All four platforms can hold the data. None of them tells you which SKUs are missing what, enforces a value list, or stops two people entering "Navy" and "navy blue". That's the thing you're actually buying when you buy a PIM, and it's why "we'll just use metafields" works at 300 SKUs and fails at 3,000.
The attributes that now matter, and why
The requirement set changed. Structured data used to be about rich snippets. It's now about whether a machine can complete a purchase decision. Our agentic commerce readiness checklist sets out the three attributes that decision turns on.
| Attribute | Why it matters now | Adoption |
|---|---|---|
gtin | Stable identity across every channel[2] | 35% have it[1] |
priceValidUntil | An agent won't commit to a price it can't trust[8] | 18%[1] |
shippingDetails.deliveryTime | "When will it arrive" is the second question always[9] | 13%[1] |
merchantReturnDays | Risk terms before committing someone else's money[10] | 11%[1] |
| Material, colour, size, audience | How filtering and comparison work | Highly variable |
| HS code, country of origin | Duty at checkout, customs[11] | Usually absent |
| Per-variant images | An agent showing the wrong colour is a return[14] | Patchy |
Google's merchant listing and product structured data documentation is the practical reference for how to express these[12][13], and the Merchant Center product data specification is what your feed has to satisfy[2].
Note the pattern in the adoption column. The fields that have been required for feeds for a decade are near-universal. The three that determine whether an agent can transact are at 11% to 18%[1]. That's a lead you can take cheaply, and it will close.
Reading the SALT data properly
The temptation is to read those numbers as "retailers have bad product data". Look again at the full breakdown and a more precise story appears[1]:
| Field | Present | How long it has been a feed requirement |
|---|---|---|
| Price and availability | 99% | Since the beginning |
| MPN or SKU | 99% | Since the beginning |
| Brand | 96% | Since the beginning |
| GTIN | 35% | Strongly recommended, conditionally required[2] |
| priceValidUntil | 18% | Only mattered once agents appeared |
| deliveryTime | 13% | Same |
| merchantReturnDays | 11% | Same |
There's a clean line through that table. Retailers publish exactly the fields somebody has required of them, and nothing more. Where a channel enforced a field, adoption is near-total. Where it didn't, adoption is near-zero.
Which is not laziness. It's rational behaviour under a decade of feed specs that only checked certain boxes. It also means the gap closes the moment a major channel starts enforcing the new fields, and the merchants who moved early get a window rather than a moat.
Diagnose the source before you act on it. SALT is an SEO agency publishing research that argues for the service it sells, and the sample is 141 pages, which is small. Against that: the underlying checks are deterministic and reproducible. You can run the same test on your own PDP in a browser in about a minute, which is more than can be said for most vendor research. Do that rather than trusting either the agency or me.
If you are on Shopify
When metafields are enough
Under roughly 2,000 SKUs, one language, and a stable attribute set. Define metafields properly with types and validation rather than free text, use metaobjects for anything with structure[15], and you'll be fine for a long time.
When they stop being enough
Three signals, in the order they usually appear.
You hit the 50-definition admin filter limit and can no longer find products by the attribute you care about[3]. You start needing per-locale attribute values and discover Shopify's translation model is theme-and-content-shaped rather than attribute-shaped. Or you add a second sales channel with different required fields and start maintaining two versions.
The thing to do regardless
Audit metafield completeness. Export your catalogue, count blanks per field, and rank by revenue. You'll find that your top 200 products by revenue are 80% complete and your long tail is 20% complete, and the long tail is where feed rejections come from.
Not on Shopify? The other platforms
WooCommerce
The most flexible and the most likely to rot. Product attributes are global or per-product, and the per-product ones are where inconsistency breeds. Force global attributes with defined terms for anything you filter or feed on, and treat per-product attributes as a smell.
The REST API makes exporting for audit trivial[7]. Do it monthly. A Woo catalogue that nobody audits will develop three spellings of every colour inside a year.
Magento and Adobe Commerce
Often you already have the PIM and don't know it. Attribute sets, per-scope values, and a proper import framework cover most of what a mid-market merchant would buy Akeneo for[5].
If you do go external, Akeneo's API documentation is the clearest public example of what a PIM integration surface looks like[19].
Where a separate PIM still earns its place on Magento: when product data has to reach channels that aren't Magento, or when the people enriching data shouldn't have admin access to a commerce platform. Both are real and neither is about the data model.
BigCommerce
Custom fields work well up to moderate complexity and the Catalog API is clean for syncing from an external source[6]. If you're on BigCommerce with a complex catalogue, the external-PIM pattern is usually the right one earlier than on Magento.
Headless and custom
Worth remembering that headless stores are systematically undercounted in platform statistics, because the usual fingerprints disappear[20]. You are less unusual than the numbers suggest.
You almost certainly need a PIM, because the whole point of your architecture is multiple front ends consuming one source, and that source has to be authoritative about something. If your Next.js storefront and your marketplace feed read from different places, you built the problem you were trying to avoid.
Build, buy, or neither: the decision table
| Situation | Do | Roughly |
|---|---|---|
| <500 SKUs, one channel, one language | Native fields plus discipline | £0 |
| 500 to 2,000 SKUs, two channels | Native fields plus a monthly completeness audit | £0 plus a day a month |
| 2,000+ SKUs, three or more channels | A PIM | See below |
| Multi-language or multi-market | A PIM, sooner | Localisation is where spreadsheets die |
| Supplier data arriving in many formats | A PIM with import mapping | The clearest ROI case |
| On Magento with one storefront | Use Magento's attribute model[5] | £0 incremental |
| Headless, multiple front ends | A PIM from day one | Architectural, not optional |
On cost, and this is where the category is unhelpful: the major PIM vendors don't publish list pricing for their managed tiers. Akeneo publishes a free open-source Community Edition you host yourself[16] and quotes its SaaS packages. Pimcore's pricing page is likewise quote-led for anything serious[17].
Treat any third-party number you read as unverified. Get two quotes, and price the implementation separately from the licence, because implementation is usually the larger figure and it's the one that varies by an order of magnitude depending on how bad your existing data is.
The product data audit
Do this before you buy anything. It takes a morning and it tells you the size of the problem.
| # | Check | Target |
|---|---|---|
| 1 | SKUs with a GTIN | Above 90% for anything manufacturer-branded[2] |
| 2 | SKUs with material or composition | 100% in apparel |
| 3 | Distinct values in your colour field | Should be a short controlled list, not 340 strings |
| 4 | SKUs with per-variant images | 100% where colour varies |
| 5 | SKUs with alt text on the primary image | 100% (see accessibility) |
| 6 | SKUs with HS code and country of origin | 100% if you ship internationally[11] |
| 7 | priceValidUntil in your structured data | Present[8] |
| 8 | Delivery time in structured data | Present[9] |
| 9 | Return days in structured data | Present[10] |
| 10 | Descriptions identical to the manufacturer's | Count them. Duplicate copy is a ranking problem |
| 11 | Feed rejection rate in Merchant Center | Under 2% |
| 12 | robots.txt treatment of AI crawlers | Deliberate, not accidental[18] |
Row 12 is there because 15% of the pages in the SALT sample returned 403 to the crawler[1]. Some of those are deliberate policy. Most are a WAF rule somebody added during a scraping incident and nobody revisited.
What to do this week
- Export your catalogue to a spreadsheet and count blanks per field. That number is your business case.
- Count distinct values in your colour and size fields. If it's more than double what it should be, you have a governance problem, not a tooling problem.
- View source on your best-selling product page and check for the three agentic attributes[1].
- Check your robots.txt and WAF for accidental AI crawler blocks[18].
- Pull your Merchant Center rejection list and group by reason. It's a free completeness audit somebody already ran for you.
- Pick your top 200 products by revenue and get them to 100% completeness. Not the whole catalogue. The 200.
- Decide who owns product data. A named person. If it's "everyone", it's nobody, which is how you got here.
The takeaway
You probably don't need a PIM. You definitely need product data governance, and at some catalogue size those become the same thing.
The reason to care now rather than next year is that the requirement set moved and almost nobody has noticed. Price validity at 18%, delivery time at 13%, return terms at 11%[1]. Three fields, cheap to add, and they're the difference between an assistant being able to recommend your product and having to skip it.
I've been guilty of the opposite mistake for most of my career: treating product data as a job for the merchandising team and an integration problem for engineering, with nobody actually owning the quality of it. Every project that went wrong later traced back there. Feeds, translations, filters, search relevance. Same root.
Go and count how many distinct colour values are in your catalogue. Genuinely, go and count.
Sources
- Reza Moaiandin, SALT.agency, reported in "70% Of Top Retailers Are Invisible To Agentic Commerce", Search Engine Journal, 21 July 2026 (207 PDPs from 29 retailers, 141 analysed). SALT is an SEO agency; the underlying field checks are reproducible.
- Google, "Product data specification", Merchant Center Help. Accessed 22 July 2026.
- Shopify, "Metafield limits", shopify.dev. Accessed 22 July 2026.
- Shopify, "We've increased the product variant limit to 2048", 15 October 2025.
- Adobe, "Catalog introduction, Adobe Commerce". Accessed 22 July 2026.
- BigCommerce, "Catalog". Accessed 22 July 2026.
- WooCommerce, "WooCommerce REST API". Accessed 22 July 2026.
- Schema.org, "Product". Accessed 22 July 2026.
- Schema.org, "OfferShippingDetails". Accessed 22 July 2026.
- Schema.org, "MerchantReturnPolicy". Accessed 22 July 2026.
- Shopify, "Duties and import taxes". Accessed 22 July 2026.
- Google, "Merchant listing structured data". Accessed 22 July 2026.
- Google, "Product structured data". Accessed 22 July 2026.
- Google, "Product variant structured data". Accessed 22 July 2026.
- Shopify, "Metaobjects", shopify.dev. Accessed 22 July 2026.
- Akeneo, "Everything you need to know about our PIM versions". Accessed 22 July 2026.
- Pimcore, "Pimcore pricing". Accessed 22 July 2026.
- OpenAI, "OpenAI crawlers and user agents". Accessed 22 July 2026.
- Akeneo, Akeneo PIM API documentation. Accessed 22 July 2026.
- HTTP Archive, "Web Almanac 2025: Ecommerce". Accessed 22 July 2026.