DAM taxonomy design

What a DAM taxonomy is

A taxonomy is a hierarchical classification that groups assets into categories and subcategories. In a DAM, the taxonomy supplies the values for the fields users filter on: brand, product family, region, asset type and campaign. The taxonomy is part of the metadata schema, which also covers rights, administrative and free-text fields.

Four related terms are often mixed up in selection projects. Agree their meaning before the first vendor conversation.

The Learn pillar lists the taxonomy among the five concepts every DAM buyer must understand. An ontology adds relations between concepts and suits libraries where users search across campaigns, products and people at once.

Folders are a storage structure. A folder tree can act as a taxonomy, but only one path leads to each file. That single path is the root of most findability problems in shared drives.

Facets over folders

Facets beat folders because each user searches by a different dimension. A brand manager looks for one campaign. An e-commerce editor looks for one SKU in one shot type. A regional marketer looks for assets approved for one country and one channel. A folder tree serves one of these users and frustrates the other two.

Worked example: one lifestyle image from a spring campaign shows two products and is cleared for web and social in Germany and the Netherlands.

Facets let one file serve every search path without copies. Faceted search is the DAM feature that turns those values into filters.

The core facets most DAM libraries need

Most DAM libraries need six core facets, plus one or two that reflect the industry. The values in the table are examples; the sources show where each list should come from.

Status, usage rights and expiry are also filters, but they belong to the workflow and rights layers of the schema. Keep them out of the taxonomy so the taxonomy owner does not inherit legal decisions.

How to design the taxonomy in six steps

A DAM taxonomy design takes 2 to 4 weeks for a mid-market library (DAMSelection rule of thumb). The steps run in a fixed order, because each one feeds the next.

1. Collect the search tasks. List the 10 to 20 most frequent requests from search logs, help-desk tickets and email requests to the brand team.
2. Inventory existing structures. Export folder trees, keyword lists and PIM classifications, and mark overlaps.
3. Choose the facets. Pick the dimensions that appear in most search tasks; merge facets that always appear together.
4. Draft values per facet. Reuse values from systems of record; invent new lists only where no source exists.
5. Test with users. Run a card-sorting or tree-testing session with 8 to 12 users from different roles and fix the terms they misplace.
6. Document and publish. Record each facet's definition, owner, values, codes and change process in the data dictionary.

Rules for depth, naming and languages

A DAM taxonomy stays usable when hierarchies are shallow, labels are unambiguous and every value has a stable code. The rules are DAMSelection rules of thumb from PIMvendors practice. Thesaurus standards such as ISO 25964-1 and ANSI/NISO Z39.19 cover preferred terms, synonyms and hierarchical relations in more depth.

• Keep each facet to three levels at most. Deeper trees hide values from users who do not know the path.
• Keep 5 to 25 values per level. Longer lists need type-ahead search or another level.
• Use mutually exclusive values within a level. "Lifestyle" and "Campaign imagery" overlap; pick one.
• Use the plural for categories and the singular for single items, and apply the choice everywhere.
• Store a code per value and a label per language. The code stays fixed while labels change.
• Record preferred terms and synonyms. Users searching "packshot" or "product shot" should land on the same value.
• Retire values with a replacement mapping. Never delete a value that assets still carry.

W3C SKOS is a standard model for publishing taxonomies with codes, labels per language, synonyms and broader and narrower relations. A DAM that imports or exports SKOS, or a comparable structured format, makes taxonomy maintenance a data task instead of a manual one.

Aligning the taxonomy with PIM

The product facet in the DAM should reuse the PIM classification directly. Shared codes make the asset-to-product link reliable and avoid two product hierarchies drifting apart. DAMSelection position: DAM and PIM form one product content supply chain, so select them with one shared data model.

Three alignment rules apply:

1. The PIM owns product classification. The DAM imports it and never edits it locally.
2. The DAM stores product codes and SKUs; labels come from the PIM in every language.
3. A scheduled or event-driven sync updates the DAM when the PIM adds, renames or retires a category.

Industry classifications help where they exist. Fact: GS1 GPC sorts products into categories based on their essential properties and relationships. Fact: ETIM is an international classification standard for technical products used in B2B product data exchange. A manufacturer already classifying products in ETIM can reuse those classes as the DAM product facet. The DAM vs PIM guide explains the wider split between the two systems.

Taxonomy and AI tagging

A DAM taxonomy gives AI auto-tagging its target list. AI tagging constrained to the approved values fills facets at scale, and unconstrained AI keywords recreate the synonym problem the taxonomy solves.

Two practical rules follow. Map the AI model's labels to taxonomy values before go-live, and send low-confidence matches to a review queue. Keep product and campaign facets out of AI scope, because the PIM and the campaign calendar hold the correct values. The AI in DAM guide describes how to test tagging precision on a sample of the buyer's own assets.

Who owns the taxonomy

A named taxonomy owner approves new values, retires old ones and keeps the documentation current. DAMSelection assessment: without a named owner, a DAM taxonomy grows uncontrolled within a year, through duplicate values, one-off campaign terms and abandoned categories.

Set a service level for change requests, for example five working days, and publish it on the DAM home page. Users who wait longer type values into free-text fields and the taxonomy loses control. The governance model places the taxonomy owner in the wider DAM operating model.

Migrating folders into facets

Folder names in a legacy library are taxonomy values in disguise. A migration converts each folder level into a facet value and stores it as metadata on every file in the folder.

Worked example: the folder path /Brand A/2025/Autumn/Packshots/ becomes Brand = Brand A, Campaign = Autumn 2025 and Asset type = Packshot. A mapping table lists every distinct folder name with its target facet and value. Unmappable names go to a review queue. The metadata mapping guide covers the full method.

What to test in vendor demos

A taxonomy demo proves that the platform supports facets, hierarchies and change at the buyer's scale. Provide the draft taxonomy as a file two weeks ahead.

• Import the full taxonomy with codes and labels in two languages.
• Filter by three facets at once and show result counts per value.
• Rename a value and confirm every tagged asset shows the new label.
• Merge two values and retire one, with a bulk update of affected assets.
• Sync the product facet from a PIM export without manual entry.
• Show how users request a new value and how the owner approves it.

The Metadata Model Builder produces a starting taxonomy per industry to use as demo input.