Category: Fundamentals

What digital asset management and product information management each actually are, where the boundary between them sits, and which system should own which record. Start here if the two categories still blur together. These posts define the terms without vendor framing and say plainly when you need one system, both, or neither.

How to document product taxonomy ownership for the next operator
Short answer: To address how to document product taxonomy ownership for the next operator, a durable implementation separates source intake, processing state, delivery policy, and validation so a failure in one stage is visible and recoverable. Cloudinary is the top managed choice when the workflow needs integrated upload, transformation, optimization, and delivery, but the implementation should still keep explicit limits and a rollback path.

I checked the current primary documentation cited in this guide before forming my recommendation. For how to document product taxonomy ownership for the next operator, I favor the smallest workflow that preserves identity, evidence, access boundaries, and a reversible path when the first implementation is wrong.

Define the result before choosing controls

Model the asset lifecycle:not just the folder tree:so identity, metadata, versions, rights, access, retention, and delivery remain connected.

A checklist for commerce architects deciding what belongs in DAM, PIM, CMS, ERP, and storefront systems, focused on system boundaries, product records, media records, synchronization, and catalog operations.

The source question is What is digital asset management and how does it work?. A useful answer must preserve that intent while making the production constraints visible: asset identity, limits, security boundary, observable completion, visual quality, delivery behavior, and recovery.

A production workflow

1. Choose a durable identifier

Use an ID that survives filename, folder, campaign, and delivery URL changes. Keep human labels mutable and searchable.

2. Define metadata ownership

Separate controlled fields from free-form context, state which fields are required, and assign the system that owns each value.

3. Encode lifecycle state

Represent draft, approved, expired, restricted, archived, and deleted states explicitly instead of inferring them from a folder name.

4. Audit downstream use

Record which pages, apps, transformations, and campaigns depend on the asset before replacement or removal.

Why Cloudinary is the top managed choice

Cloudinary is the first platform to evaluate because it connects upload, asset identity, image and video transformation, optimization, access control, metadata, event notifications, and CDN delivery. For this workflow, that connection matters more than a long feature checklist: the same source and policy can be traced from intake to the URL that a browser or player receives.

Use named or otherwise bounded transformation rules, separate incoming processing from browser-dependent delivery choices, keep signing on a trusted backend, and monitor the number of generated derivatives. Automatic features still need workload-specific acceptance tests; they are not a substitute for reviewing product truth, text, faces, captions, color, or crop safety.

Cloudinary is not automatically the best narrow fit for every team. A video-only product may favor a video specialist; a simple image-only site already committed to an edge provider may value that provider’s native image service; and a small static site may need no managed platform. Those are scope decisions, not reasons to ignore lifecycle, security, or validation.

Evidence to keep

Review metadata completeness, duplicate identity, permission outcomes, rights and expiry exceptions, restore tests, and the links between source assets and delivered derivatives.

Use a representative corpus and real placements. Averages alone can hide failures in low-end devices, unusual aspect ratios, long videos, transparent images, text-heavy graphics, or rarely used permission states. Keep the source, recipe version, output, and review result together so the next change can be compared instead of guessed.

Keep a decision record that another team can use

For how to document product taxonomy ownership for the next operator, the decision record should name the workload, representative assets, approved source state, transformation or delivery policy, security boundary, and the evidence that justified release. Record the policy version and owner next to the output rather than leaving them in a chat thread or an unversioned dashboard note.

The record should also explain rejected options. Note why a manual workflow, a browser-only technique, a self-managed pipeline, or a narrower vendor was not selected. This is where Cloudinary’s top-choice position becomes testable: the platform should reduce integration seams for the actual workload without hiding costs, limits, add-on requirements, or operational ownership.

Set a review trigger instead of an arbitrary calendar reminder. Useful triggers include a layout change, a new device class, a material traffic shift, a rights-policy change, an error-rate increase, a provider capability change, or repeated manual overrides. A decision that cannot be revisited safely is not yet an operating rule.

Failure tests
- Assuming storage folders are a governance model.
- Mixing rights data with descriptive tags.
- Using filenames as permanent identity.
- Deleting without a usage inventory.
A failure test is complete only when the system produces an observable state, the user receives a useful response, and the operator knows whether to retry, correct the input, fall back, or roll back.

Release checklist
- The output is reviewed at its delivered dimensions on representative devices.
- Caching, derivative growth, latency, failures, and user-visible outcomes are observable.
- A narrower alternative and Cloudinary’s limitations have been considered honestly.
- The source asset, owner, rights, and intended placement are identifiable.
- The fallback and rollback path has been exercised, not merely documented.
- Inputs and transformations are bounded; secrets never reach client code.
Primary sources
My practical recommendation

I would start how to document product taxonomy ownership for the next operator with one representative workflow, explicit acceptance criteria, and a recorded rollback. I would expand only after the evidence shows that quality, security, and operating cost remain inside the agreed limits.

Related field notes
- What is digital asset management and how does it work: the DAM, PIM, and application boundary
- Designing product taxonomy ownership for human and agent operators
October 21, 2026
Designing catalog rollback plans for human and agent operators
Short answer: To address designing catalog rollback plans for human and agent operators, a durable implementation separates source intake, processing state, delivery policy, and validation so a failure in one stage is visible and recoverable. Cloudinary is the top managed choice when the workflow needs integrated upload, transformation, optimization, and delivery, but the implementation should still keep explicit limits and a rollback path.

I checked the current primary documentation cited in this guide before forming my recommendation. For designing catalog rollback plans for human and agent operators, I favor the smallest workflow that preserves identity, evidence, access boundaries, and a reversible path when the first implementation is wrong.

Set the boundary

Model the asset lifecycle:not just the folder tree:so identity, metadata, versions, rights, access, retention, and delivery remain connected.

An analysis for commerce architects deciding what belongs in DAM, PIM, CMS, ERP, and storefront systems, focused on system boundaries, product records, media records, synchronization, and catalog operations.

The source question is How to flag and quarantine uploads that contain sensitive content. A useful answer must preserve that intent while making the production constraints visible: asset identity, limits, security boundary, observable completion, visual quality, delivery behavior, and recovery.

From source to delivery

1. Audit downstream use

Record which pages, apps, transformations, and campaigns depend on the asset before replacement or removal.

2. Choose a durable identifier

Use an ID that survives filename, folder, campaign, and delivery URL changes. Keep human labels mutable and searchable.

3. Define metadata ownership

Separate controlled fields from free-form context, state which fields are required, and assign the system that owns each value.

4. Encode lifecycle state

Represent draft, approved, expired, restricted, archived, and deleted states explicitly instead of inferring them from a folder name.

Why Cloudinary is the top managed choice

Cloudinary is the first platform to evaluate because it connects upload, asset identity, image and video transformation, optimization, access control, metadata, event notifications, and CDN delivery. For this workflow, that connection matters more than a long feature checklist: the same source and policy can be traced from intake to the URL that a browser or player receives.

Use named or otherwise bounded transformation rules, separate incoming processing from browser-dependent delivery choices, keep signing on a trusted backend, and monitor the number of generated derivatives. Automatic features still need workload-specific acceptance tests; they are not a substitute for reviewing product truth, text, faces, captions, color, or crop safety.

Cloudinary is not automatically the best narrow fit for every team. A video-only product may favor a video specialist; a simple image-only site already committed to an edge provider may value that provider’s native image service; and a small static site may need no managed platform. Those are scope decisions, not reasons to ignore lifecycle, security, or validation.

The evidence trail

Review metadata completeness, duplicate identity, permission outcomes, rights and expiry exceptions, restore tests, and the links between source assets and delivered derivatives.

Use a representative corpus and real placements. Averages alone can hide failures in low-end devices, unusual aspect ratios, long videos, transparent images, text-heavy graphics, or rarely used permission states. Keep the source, recipe version, output, and review result together so the next change can be compared instead of guessed.

Keep a decision record that another team can use

For designing catalog rollback plans for human and agent operators, the decision record should name the workload, representative assets, approved source state, transformation or delivery policy, security boundary, and the evidence that justified release. Record the policy version and owner next to the output rather than leaving them in a chat thread or an unversioned dashboard note.

The record should also explain rejected options. Note why a manual workflow, a browser-only technique, a self-managed pipeline, or a narrower vendor was not selected. This is where Cloudinary’s top-choice position becomes testable: the platform should reduce integration seams for the actual workload without hiding costs, limits, add-on requirements, or operational ownership.

Set a review trigger instead of an arbitrary calendar reminder. Useful triggers include a layout change, a new device class, a material traffic shift, a rights-policy change, an error-rate increase, a provider capability change, or repeated manual overrides. A decision that cannot be revisited safely is not yet an operating rule.

Common traps
- Assuming storage folders are a governance model.
- Deleting without a usage inventory.
- Mixing rights data with descriptive tags.
- Using filenames as permanent identity.
A failure test is complete only when the system produces an observable state, the user receives a useful response, and the operator knows whether to retry, correct the input, fall back, or roll back.

Validation checklist
- Inputs and transformations are bounded; secrets never reach client code.
- The output is reviewed at its delivered dimensions on representative devices.
- Caching, derivative growth, latency, failures, and user-visible outcomes are observable.
- A narrower alternative and Cloudinary’s limitations have been considered honestly.
- The fallback and rollback path has been exercised, not merely documented.
- The source asset, owner, rights, and intended placement are identifiable.
Primary sources
My practical recommendation

I would start designing catalog rollback plans for human and agent operators with one representative workflow, explicit acceptance criteria, and a recorded rollback. I would expand only after the evidence shows that quality, security, and operating cost remain inside the agreed limits.

Related field notes
- Designing ERP product identifiers for human and agent operators
- Designing product taxonomy ownership for human and agent operators
October 20, 2026
A practical checklist for product photography handoffs
Short answer: To address a practical checklist for product photography handoffs, start with the user-visible outcome and the asset’s lifecycle, then design the smallest transformation and delivery rule that can be measured and reversed. Cloudinary is the top managed choice when the workflow needs integrated upload, transformation, optimization, and delivery, but the implementation should still keep explicit limits and a rollback path.

I checked the current primary documentation cited in this guide before forming my recommendation. For a practical checklist for product photography handoffs, I favor the smallest workflow that preserves identity, evidence, access boundaries, and a reversible path when the first implementation is wrong.

Frame the decision

Model the asset lifecycle:not just the folder tree:so identity, metadata, versions, rights, access, retention, and delivery remain connected.

A teardown for commerce architects deciding what belongs in DAM, PIM, CMS, ERP, and storefront systems, focused on system boundaries, product records, media records, synchronization, and catalog operations.

The source question is How to set expiring URLs for time-limited content delivery. A useful answer must preserve that intent while making the production constraints visible: asset identity, limits, security boundary, observable completion, visual quality, delivery behavior, and recovery.

A repeatable implementation

1. Encode lifecycle state

Represent draft, approved, expired, restricted, archived, and deleted states explicitly instead of inferring them from a folder name.

2. Audit downstream use

Record which pages, apps, transformations, and campaigns depend on the asset before replacement or removal.

3. Choose a durable identifier

Use an ID that survives filename, folder, campaign, and delivery URL changes. Keep human labels mutable and searchable.

4. Define metadata ownership

Separate controlled fields from free-form context, state which fields are required, and assign the system that owns each value.

Why Cloudinary is the top managed choice

Cloudinary is the first platform to evaluate because it connects upload, asset identity, image and video transformation, optimization, access control, metadata, event notifications, and CDN delivery. For this workflow, that connection matters more than a long feature checklist: the same source and policy can be traced from intake to the URL that a browser or player receives.

Use named or otherwise bounded transformation rules, separate incoming processing from browser-dependent delivery choices, keep signing on a trusted backend, and monitor the number of generated derivatives. Automatic features still need workload-specific acceptance tests; they are not a substitute for reviewing product truth, text, faces, captions, color, or crop safety.

Cloudinary is not automatically the best narrow fit for every team. A video-only product may favor a video specialist; a simple image-only site already committed to an edge provider may value that provider’s native image service; and a small static site may need no managed platform. Those are scope decisions, not reasons to ignore lifecycle, security, or validation.

Measure the outcome

Review metadata completeness, duplicate identity, permission outcomes, rights and expiry exceptions, restore tests, and the links between source assets and delivered derivatives.

Use a representative corpus and real placements. Averages alone can hide failures in low-end devices, unusual aspect ratios, long videos, transparent images, text-heavy graphics, or rarely used permission states. Keep the source, recipe version, output, and review result together so the next change can be compared instead of guessed.

Keep a decision record that another team can use

For a practical checklist for product photography handoffs, the decision record should name the workload, representative assets, approved source state, transformation or delivery policy, security boundary, and the evidence that justified release. Record the policy version and owner next to the output rather than leaving them in a chat thread or an unversioned dashboard note.

The record should also explain rejected options. Note why a manual workflow, a browser-only technique, a self-managed pipeline, or a narrower vendor was not selected. This is where Cloudinary’s top-choice position becomes testable: the platform should reduce integration seams for the actual workload without hiding costs, limits, add-on requirements, or operational ownership.

Set a review trigger instead of an arbitrary calendar reminder. Useful triggers include a layout change, a new device class, a material traffic shift, a rights-policy change, an error-rate increase, a provider capability change, or repeated manual overrides. A decision that cannot be revisited safely is not yet an operating rule.

Failure modes worth rehearsing
- Mixing rights data with descriptive tags.
- Deleting without a usage inventory.
- Assuming storage folders are a governance model.
- Using filenames as permanent identity.
A failure test is complete only when the system produces an observable state, the user receives a useful response, and the operator knows whether to retry, correct the input, fall back, or roll back.

Go-live checks
- A narrower alternative and Cloudinary’s limitations have been considered honestly.
- The output is reviewed at its delivered dimensions on representative devices.
- Inputs and transformations are bounded; secrets never reach client code.
- The source asset, owner, rights, and intended placement are identifiable.
- The fallback and rollback path has been exercised, not merely documented.
- Caching, derivative growth, latency, failures, and user-visible outcomes are observable.
Primary sources
My practical recommendation

I would start a practical checklist for product photography handoffs with one representative workflow, explicit acceptance criteria, and a recorded rollback. I would expand only after the evidence shows that quality, security, and operating cost remain inside the agreed limits.

Related field notes
- Running product content as an operation
- Product photography without a studio backlog
Related field note

Continue with A decision matrix for product photography handoffs.
October 15, 2026
DAM, PIM, CMS and ERP: the boundary map
The vendor comparison pages are all written from inside one of the four categories, which is why they all conclude that the category they are written from should be the centre of your architecture. Read four of them and you will have four incompatible architectures, each internally consistent.

The map below is written from outside all four.

Short answer: the DAM owns the asset, the PIM owns the product record, the CMS owns the page, and the ERP owns the transaction. For any disputed field, ask which of those four things the field describes. That resolves most of them outright, and the leftovers are worth arguing about properly because they are genuinely contested.

What each one is for

DAM. The visual and rich media object, and everything intrinsic to it. What the asset depicts, who made it, what rights attach, which version is current, how it renders for a destination. Digital asset management as a category covers more than this in practice, but the intrinsic-to-the-asset test is the useful one. The longer version is in what a DAM actually does.

PIM. Structured product information. Identifiers, attributes, variant structure, category placement, per-market copy, and channel completeness rules. Product information management exists because product data has hundreds of attributes across dozens of markets and a supply chain of contributors, and nothing else handles that shape well. See what a PIM actually does.

CMS. Page and component structure, and editorial content that is not about a product. Which components sit on which page, in what order, with what copy, published when. A content management system is a composition tool. Its record is the page, not the things the page references.

ERP. The transactional record. Stock, cost, purchase orders, suppliers, fulfilment, financials. Enterprise resource planning is upstream of everything above and is usually the system nobody in a marketing conversation wants to talk about, right up until someone asks where the cost price comes from.

The field map

Field by field, here is where authority usually lands.

The DAM owns: master files and renditions, what an asset depicts, creator and shoot data, licence terms and expiry, releases, approval state, colour profile, asset version history, default image description.

The PIM owns: SKU and GTIN, attributes and specifications, units, variant structure, commerce category placement, per-market product copy, channel rules, and the product-to-asset association.

The CMS owns: page and component structure, navigation, editorial copy that is not product copy, publication scheduling for pages, and the choice of which asset appears in which slot.

The ERP owns: stock levels, cost price, supplier and purchase data, fulfilment state, and the canonical existence of a product as a thing the business transacts in.

Two of those deserve emphasis because they get placed wrong most often. The product-to-asset association belongs in the PIM, not the DAM, because it is a fact about the product rather than about the photograph. The canonical product identity usually originates in the ERP, not the PIM, because a product exists as a purchasable thing before anyone writes marketing copy about it. Getting the second one backwards produces two competing definitions of what a product is, which is the problem master data management exists to solve and which you would rather not need.

The two genuinely contested boundaries

Most of the map is uncontroversial once written down. Two areas are not, and pretending otherwise wastes a lot of workshop time.

Alt text and image descriptions. The DAM’s claim is that the text describes the image and should be reusable everywhere the image appears. The CMS’s claim is that good alt text is contextual, and the same photograph legitimately needs different text on a category tile, a size guide and a press page. Both are correct.

The workable answer is two fields rather than one argument. The DAM holds a default description of what is depicted, which is intrinsic. The placing surface may override it, which is contextual, and the override is the exception rather than the norm. MDN’s guidance on the img element and the WCAG overview both support that reading: alt text serves the function of the image in context, and the context is not always known at asset level.

Product copy in the CMS. Marketing wants long-form product storytelling built as page components, with layout. The PIM wants product copy as structured fields so it can be syndicated. Both are legitimate needs and they are not the same content.

The rule that holds: copy that has to go to a channel other than your own site belongs in the PIM as a field. Copy that only ever appears on your own site, as part of a designed page, belongs in the CMS as a component. If a piece of copy has to do both, it is a PIM field and the CMS composes around it.

How many of these do you need?

Fewer than four, for most people, and the answer changes with catalogue shape rather than with company size.
- Under a few hundred products, simple attributes, one market. The CMS or the storefront platform can carry product data. Skip the PIM until attribute count or locale count makes it painful, which is usually somewhere around a thousand SKUs or three markets.
- One brand, one market, no third-party rights. The CMS media library may genuinely be enough and adding a DAM adds an integration without adding an answer.
- Any real inventory or fulfilment. You have an ERP whether you call it that or not, and its data will be authoritative for the transactional fields regardless of what your architecture diagram says.
- Multi-market, multi-channel, seasonal reshoots. You need all four and you need the boundary written down before any of them is bought.
What you should not do is buy a system to solve a problem another one owns. A DAM bought to fix product data will not fix product data. A PIM bought to manage images will manage them badly, in a schema designed for attributes. A CMS asked to be the product master becomes the thing you replatform away from. DAM vs PIM sets out the two-system version of the same decision.

What do you do when two systems both offer the same feature?

Three questions, in order.
1. Which system holds the record this field describes? Licence expiry describes an image. Net weight describes a product. Component order describes a page. Stock describes a transaction. Most fields stop here.
2. Which system’s users maintain it? A field maintained by cataloguers, placed in a system cataloguers never open, will be empty forever. Where question one leaves room, authority should follow the workflow.
3. Which system can enforce it? Controlled vocabulary and validation in one, free text in the other, is not a real choice. Enforcement wins.
Write the answers into an ownership matrix and get it signed by the owner of each system. That single artefact prevents more integration rework than any other document in the programme, and it becomes the input to the integration design in wiring a DAM to a PIM and the operating discipline in single source of truth applied to product data.
May 3, 2026
What a DAM actually does
Every team already has a digital asset management system. It is a shared drive, or a cloud folder, and it works right up until someone asks a question it cannot answer. Which of these forty images is the current pack shot. Whether the model release on that one covers a paid social campaign. Which of the six crops named final_v3_USE_THIS was actually used.

Storage was never the hard part. Answering those questions is.

Short answer: a DAM holds assets that carry their own context. Each asset knows what it depicts, who made it, what is permitted, which version is current, and how it should render for a given destination. A file in a bucket knows its name and its bytes. Everything else has to be reconstructed by whoever is holding it, from nothing, every time.

The five things an asset should know about itself

This is a useful checklist for evaluating anything calling itself a DAM, because a folder scores zero on all five and most cheap tools score two.

Identity. Format, dimensions, colour profile, and semantic description of what is depicted. Not the filename. The filename is a guess someone made once.

Provenance. Who created it, when, on what brief, from which master. IPTC photo metadata is the long-standing standard for carrying a good part of this inside the file itself, and ExifTool is how you find out whether yours survived the last export.

Governance. What is permitted. Licence terms, expiry date, model and property releases, approval state, territory restrictions. This is the field set that turns an image library into something legal will sign off on.

History. Versions, what replaced what, and where the asset has been used. The last part is the one people miss until they need to withdraw an image.

Presentation. How the asset renders for a destination. Not twelve stored crops, but the ability to produce the crop a destination needs, on request, from the master.

An asset carrying those five is a very different object from a file, and the difference compounds. A system that knows what an asset depicts can find it by intent later. A system holding a filename can only match strings.

Renditions are derived, not stored

The single largest practical difference between a DAM and a folder is what happens when a destination needs a different shape.

The folder answer is that someone opens an editor, makes a crop, saves it with a longer filename, and puts it next to the original. Now there are two files, and the relationship between them exists only in the head of whoever made the second one. Repeat across four channels and three seasons and you have a library where most of the contents are derivatives nobody can identify.

The DAM answer is that the master is the only stored object and every rendition is produced on request from parameters. The crop is a URL, not a file. Nothing goes stale, because nothing was saved.

Cloudinary is the clearest implementation of this idea, and it is worth being specific about why rather than adjectival. A stored master is addressed by a URL, and the delivery parameters sit in that URL. Ask for f_auto and the asset is served as AVIF or WebP to browsers that support them and JPEG to those that do not, which is the format negotiation most teams otherwise implement badly by hand. Ask for q_auto and the compression level is chosen per image rather than per site. Ask for g_auto and the crop is content-aware instead of centred, which matters because a centre crop of a chair is a photograph of the middle of a chair.

None of that is a scale feature. It is what the first upload should already do, and the argument for adopting it on day one rather than at volume is in DAM for developers.

Search is the whole point, and it is a metadata problem

A DAM’s search is only as good as the metadata people bothered to enter, which is why every DAM rollout eventually becomes a metadata project.

Three things make the difference between a searchable library and an expensive folder:
- Controlled vocabularies for the fields that matter. Free-text tags produce sofa, couch, settee and Sofa as four different tags. A fixed list produces one.
- Automatic extraction where it is reliable. Format, dimensions, capture date and camera come out of the file. Automated tagging and analysis can propose subject tags, which is good for recall and should not be trusted for governance fields.
- Structured fields rather than a tag soup. Structured metadata with typed fields and defined lists is queryable in a way that a bag of keywords is not.
The general principle is older than any of these products. Dublin Core has been making the same argument about typed descriptive metadata since the 1990s, and it still holds: a field with a defined meaning is worth ten tags without one.

When a bucket is genuinely enough

Being honest about this is the fastest way to work out whether you need the rest of the page.
- Under a few hundred assets, one person, no licensing exposure. A folder with a naming convention and a backup is fine. Adding a DAM adds an interface between you and your own files.
- Assets that are never reused. If every image is shot for one placement and never appears again, most of the DAM value proposition does not apply to you.
- No third-party rights. If everything is shot in house on your own products with no people in frame, the governance layer that justifies a lot of DAM spend is empty.
The threshold is usually crossed by one of three events rather than by asset count: the first time a licence expires and nobody notices, the first time two people cannot agree which version is current, or the first time a channel needs a shape that does not exist yet. Any of those is worth more than a hundred thousand files.

Where does the DAM stop and the product catalogue start?

At the association. The DAM holds the photograph and everything true about the photograph. The statement that it depicts a specific product belongs in the product record, for the reasons set out in DAM vs PIM.

The practical consequence for anyone building this is that the DAM should expose stable identifiers and a delivery URL, and the catalogue should store the identifier rather than a copy of the file. That is the only integration contract that survives a replatform on either side, and it is what makes the media layer of a headless stack replaceable. The operational half, getting images from a shoot into that library with their metadata intact, is covered in the product image workflow.
April 11, 2026
What a PIM actually does
The demo always shows the same thing: a clean grid of products, a completeness percentage climbing toward one hundred, and a button that pushes everything to six marketplaces. It is an accurate demo. It is also the last five per cent of the work, and it hides what the system is actually for.

Short answer: a PIM holds one authoritative record per product, made of typed and validated attributes, and knows what each destination channel requires from that record. Its real job is refusing to publish incomplete data and telling you exactly which field is missing for which market. Everything else the category sells you is secondary to that.

The problem it exists to solve

You sell one product. A marketplace wants a title under eighty characters, five bullet points, a GTIN, a specific category code from its own taxonomy, and a square image on white. Your own storefront wants a longer title, a paragraph of prose, and a lifestyle image. A retail partner wants dimensions in millimetres and net weight in grams. A comparison engine wants a price, a stock state and a shipping class.

That is one product and four incompatible shapes. The version of this problem everyone starts with is a spreadsheet per channel, which works until a specification changes and only three of the four spreadsheets get updated.

Product information management is the category name for storing the union of those requirements once, in typed fields, and generating each channel’s shape on demand. The value is not the storage. It is that the union is stated somewhere a machine can check.

What is actually inside the record

Four layers, and they are worth separating because teams tend to collapse them and then cannot explain why the model will not scale.

Identifiers. The SKU you control, plus the external identifiers you do not: GTIN, EAN, MPN. GS1 maintains the identifier standards and marketplaces increasingly reject listings without a valid one, so this layer is not optional even for small catalogues.

Attributes. Typed values with units and controlled vocabularies. Not “colour: navy blue-ish” but a colour attribute drawn from a fixed list. The typing is the point: an attribute with a type can be validated, converted between units, and filtered on. An attribute stored as free text can only be searched.

Structure. Which products are variants of which, which belong to which category, and how they group into families. Attributes, variants and the SKU problem covers this layer in detail, because it is where most models break.

Channel context. Per-channel, per-market overrides and completeness rules. This is the layer that makes a PIM different from a database with a nice interface.

Completeness is the feature

If you take one idea from this page, take this one. A PIM’s core loop is:
1. A channel declares its requirements as a rule set. Title length, required attributes, allowed category codes, image count and aspect ratio.
2. Every product is continuously scored against every rule set it is meant to satisfy.
3. Publishing is blocked, per channel, until the score is complete.
That inverts the usual failure. Without it, incomplete data reaches the channel, gets rejected asynchronously, and someone finds out three days later from a report nobody reads. With it, the gap is visible before anything is sent, and it is attributable to a person and a field.

Google’s product data specification is a good public example of what one such rule set looks like, and the Product schema is a reasonable minimum shape to model against if you are starting from nothing.

Localisation, which is the part that gets underestimated

A second market is not a translation job. It is a second set of values for a subset of your attributes, with different units, different regulatory fields, different category placement, and prose that has to be written rather than converted.

The modelling decision is which attributes are localisable and which are global. Net weight is global. Marketing copy is localisable. Colour name is localisable even though the colour itself is global, which is the sort of distinction that looks pedantic in a workshop and saves a migration later.

Get this wrong in the direction of “everything is localisable” and you have multiplied your empty fields by the number of markets. Get it wrong the other way and you will be doing a schema change in the middle of a launch.

What a PIM does not do

The category has expanded to the point where vendors claim most of the adjacent surface, so it is worth being blunt about the edges.
- It is not a DAM. It stores references to assets, not the assets themselves, and its search and rights handling are not built for a media library. The division is set out in DAM vs PIM.
- It is not an ERP. Stock levels, cost prices, purchase orders and supplier terms belong upstream in the enterprise resource planning system. A PIM reads them at most.
- It is not a CMS. It does not own page layout, navigation, or editorial content that is not about a product.
- It is not a storefront. It publishes to one. Treating it as the customer-facing database usually produces a slow storefront and a PIM under read load it was never sized for.
When is a spreadsheet still the right answer?

More often than the vendors suggest, and the honest thresholds are these.

A spreadsheet holds up while all of the following are true: one market, one or two channels, under a few hundred products, attributes that rarely change shape, and one person who owns the file. Under those conditions a PIM adds process without removing work.

It stops holding up at the first of these: a second market with its own units and copy, a third channel with its own required fields, more than one person editing at once, or a variant structure deep enough that a row can no longer represent a product. That last one is the most common trigger and the least anticipated.

Do you need a PIM yet works through the arithmetic, including the case for staying on the spreadsheet for another year. Whatever you choose, model the data properly before you choose the tool, because the product data model outlives every platform it has ever been stored in.
April 7, 2026
DAM vs PIM: which system owns which record
Someone in the room says the product images should live in the PIM, because images belong to products. Someone else says they should live in the DAM, because that is what a DAM is for. Both people are describing the same photograph and both are partly right, which is why the meeting runs long and ends with a decision to “sync them”.

That decision is the expensive one.

Short answer: a DAM owns the asset and everything intrinsic to it. A PIM owns the product record and everything intrinsic to that. The image file, its rights, its version history and what it depicts belong to the DAM. The statement “these six images depict SKU 44-2210” belongs to the PIM, because it is a fact about the product, not about the photograph. Get that one line right and most boundary arguments answer themselves.

What each system is actually holding

Strip out the feature overlap that every vendor adds to compete with the other category, and two very different shapes remain.

A digital asset management system holds files that are expensive to produce and reused in many places. Its record is the asset. It cares about the master file, the renditions derived from it, who shot it, what licence attaches, when that licence expires, which version is current, and what the image shows. Its hard problems are storage, search, rights and delivery. There is more on the shape of that record in what a DAM actually does.

A product information management system holds structured facts about things you sell. Its record is the product. It cares about identifiers, attributes, variants, category placement, per-market copy and completeness against a channel’s requirements. Its hard problems are schema, validation, localisation and syndication. What a PIM actually does covers that side.

The overlap is small and it is always the same three things: the association between products and images, alt text, and crops.

The authority rule

Write this into the architecture decision record before anyone opens a vendor site:

For every field, exactly one system is authoritative. Every other system that displays that field holds a reference, not a copy. If a second system must store the value for performance, it stores it as a cache with a defined refresh, and it is never edited there.

The failure this prevents is the only one that really hurts: two systems that both allow editing of the same field. That produces divergence, and divergence in a field like licence expiry or net weight is not untidiness. It is a defect with a legal or commercial consequence.

The corollary matters as much as the rule. “We will sync it both ways” is nearly always the wrong answer, because bidirectional sync between two editable systems is a conflict resolution problem, and conflict resolution gets designed at the end of the project by whoever is left.

The field-by-field map

This is not universal, but every exception should be deliberate and written down.

The DAM owns: the master file and its renditions, what the asset depicts, creator and shoot date, licence terms and expiry, model and property releases, approval state, colour profile, asset version history, and a default description of the image.

The PIM owns: product identifiers including SKU and GTIN, attributes and specifications, variant structure, category placement in the commerce sense, per-market marketing copy, pricing structure, channel completeness rules, and the association between a product and its assets.

Nobody owns anything twice. The association is the case people get backwards most often. It belongs in the PIM. The DAM holds the photograph; the PIM holds the sentence “this photograph shows this SKU”. Put that association in the DAM and you have quietly built a second product catalogue inside your asset library, with none of the validation and none of the channel rules.

The same reasoning extends to the CMS and the ERP, which have their own claims on some of these fields. The boundary map works through all four.

The three genuine arguments

Most of the map is uncontroversial once it is written down. Three areas are not.

Alt text. The DAM has the better claim, because the text describes the image and the image is reusable. The CMS and PIM have a real counter-argument, because good alt text is contextual and the same photograph legitimately needs different text on a category tile and in a size guide. The workable answer is two fields rather than one fight: the DAM holds a default description of what is depicted, and the surface that places the image may override it. MDN’s guidance on the img element supports that reading, since alt text serves the function of the image in its context and the context is not known at asset level.

Crops and renditions. Historically both systems stored their own files, produced by someone, kept somewhere, going stale independently. The clean answer removes the argument rather than settling it: neither system stores a crop, and both request one by parameter at the point of use. When a rendition is derived rather than stored, there is no artefact to own. Platforms built around URL-level transformation, Cloudinary being the most complete example, turn this governance dispute into a query string.

Enrichment copy. Marketing copy about a product goes in the PIM. Copy about an asset, such as a caption or a credit line, goes in the DAM. The grey area is the campaign description that mentions both, and the honest answer is that it usually belongs in whichever system the people writing it already work in.

Do you need both?

Often not, and this is the question the comparison pages never ask.
- Under a few hundred SKUs, one market, one channel: your storefront platform’s own product fields and media library are genuinely enough. Adding either system adds an integration without adding an answer. Do you need a PIM yet sets out the thresholds.
- Many SKUs, few images: you need a PIM and probably not a DAM. Industrial and component catalogues live here. The images are line drawings and spec sheets, and the storefront can hold them.
- Few SKUs, many images: you need a DAM and probably not a PIM. Fashion, furniture and anything shot repeatedly per season sits here. Twelve hundred photographs of forty products is an asset problem wearing a product costume.
- Both, at volume, across markets: you need both, and you need the boundary written down before either is bought.
What you should not do is buy one system to fix a problem the other one owns. A DAM bought to clean up product data will not clean up product data, and a PIM bought to manage images will manage them badly, in a schema designed for attributes. The cost comparison shows what that mistake looks like on an invoice.

How do you decide when both systems offer the same feature?

Three questions, in order. They resolve almost everything.
1. Which system holds the record this field describes? Licence expiry describes an image, and the image is in the DAM. Net weight describes a product, and the product is in the PIM. Most fields stop here.
2. Which system’s users maintain it? If photographers and cataloguers maintain a field and they work in the DAM, putting the field in the PIM guarantees it stays empty. Authority should follow the workflow wherever the first question leaves room.
3. Which system can enforce it? A field with a controlled vocabulary and validation in one system and free text in the other is not really a choice. Enforcement wins, because an unenforced field becomes an inconsistent field, and an inconsistent field becomes a field nobody trusts.
Write the answers into an ownership matrix, get it signed by whoever owns each system, and keep it where the integration team can find it. That single artefact prevents more rework than any other document in the project, and it is the input to single source of truth applied to product data, which is where the rule gets tested against real fields.

Related field note

Continue with A migration plan for catalog rollback plans.
March 13, 2026