Short answerA good DAM metadata schema starts from the questions users ask, defines a small set of required fields per asset type, uses controlled vocabularies for every filterable field and stores product identifiers such as SKU and GTIN as structured, multi-value links. Clear governance roles keep the schema consistent as the library grows.
Key takeaways
- Most organisations need 8 to 15 required fields per asset type, and schemas with more than 25 required fields usually see upload quality decline.
- Product identifiers such as SKU and GTIN belong in a multi-value structured field, because one lifestyle image often shows several products.
- Four governance roles, namely metadata owner, taxonomy steward, librarian and contributor, keep a schema consistent after go-live.
Start from the questions users ask
The best schemas are designed backwards from search behaviour. Before defining a single field, teams should collect 30 to 50 real requests from marketing, e-commerce, studio and partner users, such as "all front packshots for spring range in white background" or "approved lifestyle images for Germany with valid licence". Each recurring filter in those requests becomes a candidate field.
This approach keeps the schema lean. It also gives the project a test set: once the schema is configured, the same requests can be replayed as searches to confirm that each one returns the expected assets. Fields that nobody filters or reports on add upload effort without adding findability. A schema that answers 90% of real requests with 10 to 15 well-governed fields outperforms one with 60 optional fields that contributors skip.
Separate required, conditional and optional fields
Required fields should vary by asset type. A packshot needs different metadata from a campaign video or a safety data sheet. A practical model uses three tiers.
| Tier | Example fields | Rule |
|---|---|---|
| Required for all | Asset type, status, owner, rights status, language | Blocks upload when empty |
| Required per type | Packshot: SKU, view angle, background. Video: duration, aspect ratio, subtitles | Blocks approval when empty |
| Optional | Mood, season, photographer notes | Encouraged, never blocking |
In practice, most organisations need 8 to 15 required fields per asset type. Embedded XMP and IPTC metadata from cameras and creative tools can prefill several of them, such as creator, copyright and capture date.
Use controlled vocabularies for anything filterable
Every field used as a filter needs a controlled vocabulary. Free text produces "Front", "front view", "FRONT" and "frnt" as four separate values, which breaks facets and downstream rules.
- Flat picklists suit short, stable lists such as view angle or background type.
- Hierarchical taxonomies suit product categories, regions and brands, where a search on a parent should return children.
- Synonyms and translations let German, French and Dutch users search in their own language against one canonical value.
- Linked lists from PIM keep product categories identical in both systems instead of maintaining two copies.
AI auto-tagging can suggest values, but suggestions should map to the controlled vocabulary before they are saved. AI auto-tagging in DAM covers how to measure tag accuracy.
Store product identifiers as structured links
Product identifiers are the bridge between DAM and the product record. SKU, article number and GTIN should sit in dedicated structured fields, never in the file name alone or a free-text description. The field must accept multiple values, because a lifestyle image often shows several products and a packshot may apply to several colour variants.
Two design decisions matter most. First, decide whether the link is held at style, variant or SKU level, and keep that rule consistent. Second, decide which system masters the link, which DAM and PIM integration patterns discusses in detail. Validating GTINs against the GS1 check digit at upload prevents most identifier errors. Discontinued SKUs should stay on the asset for history, flagged by a status from PIM, so archived images remain traceable.
Naming conventions support, never replace, metadata
File names remain useful for creative teams, external partners and retailers that still request files by name. A consistent convention also helps automated ingest, where the DAM parses the name to prefill fields. A common pattern is GTIN_viewcode_sequence.ext, for example 08712345678906_01_001.jpg.
The file name should never be the only place information lives. Names get truncated, renamed by partners or exported without context. The structured metadata is the source of truth, and the name is a convenience derived from it.
Assign governance roles before go-live
Schemas degrade without owners. Four roles cover most organisations:
- Metadata owner approves schema changes and arbitrates between departments.
- Taxonomy steward maintains vocabularies, synonyms and translations, often a part-time role.
- DAM librarian monitors quality, fixes incomplete assets and trains contributors.
- Contributors upload and tag assets within the rules.
A quarterly review of field usage, empty-field rates and failed searches keeps the schema aligned with real needs. These practices mirror product data quality governance in PIM, and aligning both reduces duplicate effort.
Frequently asked questions
How many metadata fields should a DAM have?
There is no fixed number, but most organisations work well with 8 to 15 required fields per asset type plus a set of optional fields. Each field should answer a real search, rule or report. Fields nobody filters on add upload effort and reduce tagging quality.
Should the DAM taxonomy match the PIM category tree?
For product assets, yes. Using the same category structure, ideally synchronised from PIM, keeps filters consistent and lets rules route assets correctly. Brand and campaign assets can follow a separate taxonomy, because they are organised around campaigns and audiences.
Can AI replace manual metadata tagging in a DAM?
AI can fill descriptive fields such as objects, colours and scenes with good accuracy, and reduces manual effort. Business fields such as SKU, rights status, campaign and approval status still need rules, integrations or human input, because they cannot be inferred from pixels.