Product data is the constraint on everything downstream
Search relevance, filtering, marketplace eligibility, ad feeds, localization and every AI feature you might want later all read from the same product record. When that record is inconsistent, each of those systems fails in its own way, and the failures look unrelated.
This is why product data work tends to be undervalued and then urgently funded. It rarely presents as a product data problem. It presents as poor on-site search, a rejected marketplace feed, or a launch that slips a quarter.
The work
Almost every engagement starts with taxonomy and attribute modelling, because a PIM implemented on top of an unresolved taxonomy simply relocates the problem into more expensive software.
- Taxonomy and attribute schema design, including which attributes are channel-specific and which are global
- Catalog migration and de-duplication, with a matching strategy for records that exist in several systems
- Variant and configurable product modelling, which is where most catalog migrations lose fidelity
- Digital asset management, and the linking rules between assets and variants
- Syndication to storefronts, marketplaces, retail partners and ad feeds
- Localization and translation workflow, including which fields are translated and which are transcreated
- Data quality rules and completeness scoring, so gaps surface before a channel rejects them
AI enrichment, in the right order
Applied to a well-modelled catalog, AI genuinely changes the economics of enrichment: attribute extraction from unstructured supplier data, categorization, tagging, description drafting, translation and duplicate detection at a scale that was previously a headcount decision.
Applied to a poorly-modelled catalog, it generates plausible text that entrenches existing errors and is harder to audit than the gaps it replaced. We will not sequence it that way, even when asked.
Systems we work across
Akeneo, Salsify, inriver, Syndigo, Plytix, Pimcore, Productsup and Stibo Systems, alongside custom product data services where an off-the-shelf PIM would add licensing cost without adding capability.
For catalogs under roughly a thousand SKUs with a single channel, we will often tell you that a PIM is premature and that the money is better spent on the taxonomy itself.
Common questions
- Do we need a PIM, or can the commerce platform handle product data?
- A commerce platform is enough while you have one storefront, one language and a catalog someone can hold in their head. The threshold is usually crossed by a second sales channel or a second locale, because each one wants a different subset of attributes in a different shape. If your product launches are gated by a spreadsheet, you are already past it.
- Where should product data live if we also have an ERP?
- ERP owns commercial attributes: cost, supplier, dimensions, tax classification. PIM owns descriptive and marketing attributes: copy, imagery, taxonomy, channel-specific variants. The common mistake is enriching in ERP because it is already there, which puts marketing work behind a finance change process.
- How long does a PIM implementation take?
- The software is rarely the slow part. Modelling the taxonomy and attribute schema takes weeks and requires decisions only your merchandising team can make. A realistic first-channel go-live is two to four months; catalogs with heavy variant complexity or many locales take longer.
- Can AI write our product descriptions?
- It can draft them well when it is reading structured attributes rather than guessing from a title. That is the actual dependency: enrichment quality is a function of data quality, so the sequence is schema first, then attribute extraction, then generation. Running it in the other order produces fluent copy that is quietly wrong.