If you’re reading this blog you already know how important metadata is in a Digital Asset Management system: for finding assets, for controlling asset usage, for coordinating production and approval processes, and to power integrations with other systems.
In a larger or higher-volume DAM deployment, manual entry of metadata quickly becomes either a bottleneck as creatives and librarians struggle to keep up with the load of high-quality tagging, or it becomes a weak point where in order to meet deadlines, corners are cut and assets no longer have consistent or quality metadata.
There are two common approaches to ensuring consistent quality metadata on all assets in the system: policy enforcement, or an army of tagging monkeys team of digital asset managers. Both are doomed to fail.
The Metadata Police
In the Policy Enforcement method, all creatives and marketers uploading assets to the DAM are required to manually enter certain metadata fields, using consistent taxonomy and vocabulary. Compliance with these standards can be enforced either by a manual review step in the workflow by a “gatekeeper”, or enforced by a DAM system by blocking uploads or edits of assets that lack certain metadata. I also refer to this as the “eat your vegetables” approach–everybody has to do the boring drudgery of typing or copy/pasting metadata into each and every file they work with. Metadata quickly becomes a four-letter word and creatives will resent the process, the system, and/or those responsible for ensuring compliance. Metadata is now a chore.

Dedicated metadata-entry staff
The other option is to farm out the grunt work to a team of manual taggers. There are two problems with this: first, quality will decline, as your (low-paid, high-turnover) taggers don’t have the full business context around the creation of the assets, and without this information they can’t fully or correctly tag all the assets; second, hiring humans doesn’t scale: the cost of manual tagging increases linearly with the volume of assets entering the system, and costs can quickly become an issue.
We’ve all been doing it wrong for the last 20 years of DAM.
The Context Is the Metadata
For marketing assets, what are the sources of useful metadata? For administrative data, like approval status, it comes from the workflow (which might be tracked in an excel sheet, or an online tool like basecamp). For business-contextual data, like season, or campaign, that information comes in the form of a creative brief or work assignment. For identity/categorization, that comes in the specifications section of the creative brief. For product information, that information may come from a shot list, or from a creative brief specifying which products to feature in a marketing asset.
Notice that none of the sources of metadata actually come from the people creating the assets! Yet they are the ones we often ask to be entering it.
Wouldn’t it be amazing if we could automatically extract this information from the sources and pass it along to the assets, rather than copy/pasting or guessing?
Much of this can be accomplished by encoding those data into the context/process of asset creation itself, and systematically extracting that metadata from the process and applying it to the assets.
FinalSelect: automated metadata from start to finish
This can take several different forms. For instance, for product images in FinalSelect, the product and season/campaign information is automatically propagated to the asset requests created from the product data and project request, and then onto the assets themselves when they are uploaded and auto-mapped to the existing business metadata. Due to our integration with product data sources and image capture systems like Capture One, this process is completely automatic.

You can do the same thing for other kinds of creative assets in FinalSelect, except starting with a Creative Request rather than a product–creating the metadata before the asset even exists.
DAM Metadata from Folder Structure
In a more traditional/old-fashioned folder/file-based workflow, you can use the configuration of folders and filenames to specify asset properties. You you may already organize your assets in folders based on project, asset type, and approval status, moving files from one folder to another as they make their way through the content creation process. This structure itself can be used to automatically apply metadata based on the names and hierarchy levels of folders and filenames.
In this typical example, folders are created based on information in the creative brief or project request:

If you have a DAM, and you’re willing to shell out for customizations, you can use folders and filenames within a DAM (or a synced WebDAV or FTP server) to automatically apply structured metadata by programmatically extracting the data from the filesystem:


These automations have a tendency to become brittle, though–any changes to your workflow will require costly code changes to adapt to your new processes or metadata schemas.
For a less-sophisticated and slightly more laborious version, you can use your DAM’s built-in functionality for folder-based metadata templates to apply project-level metadata based on placing and moving files from folder to folder:

Configuring these templates for each project will take some time, but at least you’re not having to do it on the assets themselves, right?
For large DAM implementations, it may be worth the money to implement these time-saving metadata automations, even with their drawbacks. Making the assignment of business metadata an implicit, rather than explicit action will reduce the workload of your creative users and increase the quality of the metadata in the system, enabling all the wonderfulness that complete and accurate metadata provide.
To find out more about FinalSelect’s end-to-end automatic metadata capabilities, please visit finalselect.io.
