DAM KPIs, ROI & user adoption: what to measure and how to drive use

Why it matters

A DAM costs money every year: licences, storage, staff time, training and integrations. Sponsors will ask what they get for it, and the DAM team needs to know where the system fails users. Measurement answers both questions, but only if it is planned.

Without a plan, three things usually happen:

• The team reports whatever the dashboard shows. Total logins and downloads rise as the user base grows, so they almost always go up. The Google researchers who proposed the HEART user-experience metrics framework warn that such counts are indirect and ambiguous: more page views can mean that a feature is popular, or that a confusing interface makes people click around R10 Unverified (2010 paper; the reasoning still holds).
• Nobody can prove improvement. The baseline was never measured, so the "time saved" claimed after launch is a guess. Nielsen Norman Group puts it simply: "Without a baseline, a post-task measurement can mean anything" R13.
• Adoption stalls after go-live. DAM News observes that adoption is hard because it requires staff and stakeholders to change how they think and work R21 Unverified (2023). AVP, a DAM consultancy, puts it bluntly: DAM systems "rarely fail because of the platform", but because nobody does the governance and change-management work once the system is live, and it adds that a DAM nobody reports on tends to drift R26.

The DAM Maturity Model, published under a Creative Commons licence by Real Story Group and the DAM Foundation, places "measurable performance indicators" and "an established means to measure and motivate employees to adopt standards" at its highest level of maturity R18 Unverified (model first published in 2012 R19; no more recent open DAM-specific model was found).

On ROI figures. No independent, freely accessible study measuring DAM return on investment, time-to-find or adoption rates across organisations was found. Vendor-commissioned economic studies exist. One example, produced by Forrester Consulting for a DAM vendor in 2024, interviewed four customers chosen with the vendor's help, built a composite organisation, modelled three years and applied risk adjustments to benefits and costs R23. Such studies are useful to see which benefit categories get modelled (production efficiency, reuse instead of re-creation, faster finding, storage, maintenance). Their figures are not independent and do not describe your organisation, so none are repeated here.

Core concepts

Related glossary terms: metadata schema, usage rights, faceted search and auto-tagging.

Recommended practices

1. Start from goals and user needs

Write down why the organisation has a DAM, in three to six goals. Typical goals: people find approved assets themselves; assets are reused instead of recreated or repurchased; only licensed assets are published; brand consistency across regions; less time spent by the DAM team answering requests.

For each goal, use the goals – signals – metrics sequence R10:

The HEART authors give two useful tips: choose signals that move only when the experience gets better or worse, and remember that failure (abandonment, undo, frustration) is often easier to detect than success R10. GDS follows the same logic for public services: start from the service's purpose and user needs, define two or three benefits, write hypotheses on how the service will deliver them, then keep three or four KPIs that answer whether the service is working R27. It also asks teams to plan measurement from the start of a project and to combine analytics with user research R2.

2. Build a small, balanced scorecard

Pick six to ten indicators. More than that and nobody acts on them. The families below combine the GDS service KPIs R1, the HEART categories R10 and the five measurement areas in AVP's DAM operational model (system capacity and health, content organisation, asset performance, user engagement, support requests) R20.

Report most values as ratios, percentages or averages per user. Raw counts rise as the user base grows, so they need normalising R10.

The HEART paper also notes that engagement may mean little in an enterprise tool that people must use for their work. In that case, task success and satisfaction matter more R10. This often applies to an internal DAM.

3. Define how things are counted before you count

Dashboards differ between platforms and even between reports of the same platform. Write a one-page metric dictionary: name, definition, formula, data source, exclusions, owner, update frequency. Borrow from library practice, where the COUNTER Code of Practice exists to make usage comparable across platforms:

• Separate previews from downloads. COUNTER counts every interaction as an investigation and only full access as a request R9. In a DAM, "views" and "downloads" answer different questions; do not add them up.
• De-duplicate. COUNTER counts repeated actions on the same item in the same user session only once as a unique item metric, so the interface design does not inflate figures R8 R9. Apply the same rule, or at least know whether your platform's numbers are totals or unique counts.
• Exclude automated traffic. Log-based metrics have to filter out crawlers and other automated sources, and check that every important action is actually logged R10.
• Keep integration traffic apart. Downloads by a CMS, PIM or AI agent through the API, and public deliveries through a CDN, are real use but behave differently from people. Report them as separate lines. Some public delivery may not reach the DAM's own reports at all (see "How DAM platforms support this").
• Define "active user" (logged in? searched? downloaded?) and the period (7, 30 or 90 days). The HEART authors note that what counts as "using" depends on the product's goals R10.

4. Measure the baseline, then set targets

Before launch, migration or any big change, capture the current state:

• From existing data. GDS asks teams to establish baselines in discovery from legacy systems, offline records, contact-centre data and existing analytics R3 R4. For a DAM: request tickets to the DAM or brand team, shared-drive volumes, agency invoices for re-shoots or re-purchases, current licence costs.
• From users. AVP recommends surveying users before implementing a DAM to understand typical baseline measurements R20.
• From task tests. Give 8–15 representative users the same five to eight "find this asset" tasks in the current tools, and record success and time. Reuse the same tasks after launch. Nielsen Norman Group recommends documenting the method, user segment and date of the baseline so later rounds stay comparable R13, and reporting full, partial and failed task success as separate percentages rather than averaging them R12 Unverified (2001 article, reviewed 2021).

Nielsen Norman Group's benchmarking method follows the same order: choose the metrics and methods, measure a baseline, make the change, measure again, and only then, optionally, calculate a return on investment R14.

Then set targets relative to the baseline, per team where possible, with a date. Avoid targets on raw counts ("10,000 downloads"), which reward growth in headcount rather than improvement. Expect a dip after major changes: Google's iGoogle team saw satisfaction drop after a redesign and recover as users got used to it, which they attributed to change aversion R10. Wait for the curve to settle before judging a change.

5. Measure findability with logs and with tests

Search is where users succeed or give up, and the DAM's search log is the cheapest research data you have. Nielsen Norman Group recommends reviewing the most frequent queries, queries with no results, very long queries, misspellings and poorly performing queries, every six months, using three to six months of data R11 Unverified (2017).

Turn this into a routine:

Logs cannot tell you what a user was trying to find, which is why the HEART paper suggests remote usability or benchmark studies with assigned tasks to measure task success and time R10. Measure time-to-find that way, with the baseline tasks from practice 4. The taxonomy guide describes complementary findability tests.

6. Measure reuse and the value of the collection

Downloads show use; they do not prove value. D-CRAFT recommends gathering a broad range of data points, because reuse happens largely outside the repository and is harder to observe than use R15.

Useful DAM measures:

• Share of assets never used in the last 12 months, by type and by source. High values point to over-ingest, poor metadata or assets nobody needs, and feed archive or deletion decisions.
• Breadth of use: assets downloaded by several teams, regions or channels. This is closer to the idea of reuse than total downloads.
• Where assets are used: usage records, delivery links and placements (see rights & usage management, practice 10). Public delivery URLs often say more about real use than internal downloads.
• Requests for assets that do not exist (zero-result queries plus tickets), which show content gaps.

Be careful with cause and effect. A study of about 550,000 used and 550,000 unused items in the Digital Public Library of America found that used items had slightly richer metadata, but the author noted the usage data undercounted real use and did not establish which caused which R16 Unverified (2016). Use such links as hypotheses to test, not as proof that more metadata produces more reuse.

7. Measure metadata quality and rights compliance

These are the indicators that protect the organisation. Most can be calculated from a metadata export.

• Completeness, validity, consistency, timeliness, uniqueness, accuracy. The UK framework defines these six dimensions and recommends assessing quality regularly, focusing on the dimensions that matter to users, and accepting documented trade-offs R6. The metadata schema & governance guide turns them into DAM checks; report completeness by contributor team so that training can be targeted.
• Rights coverage: share of published or shareable assets with a known rights status, expiry date where relevant, and linked releases.
• Rights incidents: downloads or shares of expired, embargoed or restricted assets without approval; expired assets still live on channels; time between expiry and removal. Target zero, and investigate each one.
• AI metadata: share of AI suggestions accepted or rejected per label, and audit precision. The AI auto-tagging guide covers how to test and monitor them.

COUNTER also counts access denials (turnaways) because they show unmet demand for content users cannot access R9. The DAM equivalent, requests for access to restricted assets, can show where permissions are too tight or where licensed alternatives are missing.

8. Estimate cost and value honestly

Cost per use. GDS defines cost per transaction as the full cost of delivering a service across channels divided by the number of completed transactions. It includes staff and training, technology, facilities, promotion, support, depreciation and subcontractors. It is measured every three months from public beta, moving to a rolling 12-month figure after the first year R4. Library practice is similar: COUNTER recommends dividing annual spend by unique item requests to get cost per use R9. For a DAM, a defensible version is:

annual cost of the DAM service (licences, hosting and delivery, DAM staff, training, integration maintenance) ÷ unique downloads and deliveries by people and integrations in the same 12 months

Track it over time rather than comparing it with other organisations, whose cost bases and counting rules differ. Add cost per asset under management if storage and curation dominate your costs. The choosing a DAM guide lists the cost lines.

Value and ROI. Benefits usually fall into a few categories: staff time saved finding and preparing assets, re-creation or re-purchase avoided through reuse, fewer requests handled by central teams, rights incidents avoided, storage and tools retired. Each needs a baseline (practice 4) and an assumption you can explain. To keep the model credible:

• Use your own baseline data, never generic figures from vendor marketing.
• Give low, medium and high estimates, and apply a discount for uncertainty, as commissioned economic studies themselves do R23.
• Count only time that is actually redeployed, and say so.
• Show qualitative value separately: brand consistency, legal risk, speed to market.
• Recalculate yearly with real data, and publish the method with the numbers.

9. Run adoption as a programme, not a launch

Adoption is a change in working habits. DAM News lists ten levers, among them user-centred configuration, comprehensive training, documentation, a help desk, pilots with user champions, integration into existing workflows, incentives designed with users, a feedback loop, executive support, and measuring and communicating success R21. A practical sequence:

1. Pilot with one or two teams that feel the most pain today. The DAM Maturity Model advises identifying internal champions across the organisation, not only technical staff, among the people "in the most pain" under current practices or with the most to gain R18.
2. Bring the DAM into the tools people already use: CMS, design tools, office suites, chat, project tools. Every integration removes a reason to keep a private copy on a shared drive.
3. Retire the alternatives on a published date: read-only shared drives, then archive. Parallel systems keep old habits alive.
4. Give visible support: a named contact, office hours, short how-to videos, a request form for missing assets.
5. Watch adoption per team, not only overall: active users against expected users, retention after 90 days, and the ratio of searches to requests sent to the DAM team. Uneven adoption tells you where to send champions or training.
6. Close the loop: tell users what changed because of their feedback and zero-result queries.

Executive sponsorship matters most for step 3. Without it, old shared drives rarely close.

10. Train by role, and check that training worked

Train each role on what it actually does: searchers on search, filters, collections and sharing; contributors on upload, the five to ten fields that matter, rights fields and naming; approvers on workflow; administrators on schema, permissions and reports. Keep sessions short, record them, and repeat them for new joiners.

Evaluate training on the four levels of the Kirkpatrick model: reaction, learning, behaviour on the job and organisational results R22. For a DAM:

Behaviour is the level that matters. If uploads from a trained team are still incomplete, the problem may be the form, the vocabulary or the workload rather than the training (see practice 12 of the metadata schema guide).

11. Give measurement and adoption clear owners

The DAM Maturity Model lists roles such as asset owners, DAM managers, rights managers, reporting analysts, channel managers, metadata managers or librarians, archivists and asset creators R18. AVP distinguishes a DAM product manager, who configures and runs the application, from an asset manager, who handles assets, metadata and taxonomy, and notes that one person may hold both in smaller programmes R20. For measurement and adoption specifically:

The UK Data Quality Framework similarly gives distinct responsibilities to leaders and practitioners and asks for quality to be built into everyday work R6. The metadata schema guide has the full governance-role table.

12. Report on a cadence matched to each audience

Each report should end with decisions or actions, not only charts. GDS's guidance is to use the data to find and prioritise improvements, segmenting results to see which groups struggle and then researching why R2. Collect satisfaction feedback continuously, including from users who give up, and combine it with help-desk data and usability testing R5. Satisfaction is not impact, though: NHS England's library value-and-impact toolkit points out that satisfaction does not show whether a service made a difference or how its information was used R17.

Keep your own history. Platforms retain analytics for limited periods and change report definitions between releases. Export the raw data monthly to a store you control, so that baselines and year-on-year comparisons survive upgrades and a future migration.

13. Measure people lawfully and fairly

Per-user download, login or productivity reports are a form of worker monitoring. The UK Information Commissioner's Office says monitoring must be lawful and fair, have an identified lawful basis, be transparent to workers, be necessary and proportionate, and serve a documented purpose; it must not be done "just in case", and a data protection impact assessment is expected for high-risk monitoring R7. The guidance was under review after the Data (Use and Access) Act at the access date. Other jurisdictions have similar rules; check with your data-protection officer.

In practice: report adoption and quality by team, not by named individual; use individual data only for support (for example a contributor's incomplete uploads, shared with that person) or for security and audit; publish a short note to users explaining what the DAM logs and why; and set a retention period for detailed event data.

Common pitfalls

• Vanity totals. Cumulative logins, downloads and asset counts only go up. Report ratios against expected users and baselines R10.
• No baseline. "Time-to-find fell by half" without a measured "before" is not credible R13.
• Adding up views and downloads, or mixing human and integration traffic, which inflates and blurs the figures R9.
• Measuring only logs. Logs cannot show intent or time-to-find; add task tests and surveys R10.
• Quoting vendor ROI figures as if they applied to you. They come from a handful of selected customers and a composite model R23.
• Targets that punish honesty. If champions are judged on download counts, they will encourage downloads, not good use.
• Treating adoption as a launch event. Training once at go-live and never again leaves new joiners and new features uncovered R21.
• Leaving shared drives open "for now", so the DAM is always the second place people look.
• Individual league tables of users. They raise legal and trust issues and rarely change behaviour R7.
• Losing history when the platform's analytics window ends or when you migrate.

How DAM platforms support this

Each solution in the wiki has an Analytics & reporting section on its features page, and an API page that shows whether analytics data can be extracted. The examples below show the kind of difference that matters for measurement. They are illustrations, not a ranking or a complete list; each fact is cited on the linked page.

Other details to check before you rely on a report: whether figures are totals or unique counts, whether API and integration activity is included, whether SSO users appear in login reports (the Canto page notes they do not), and how long event data is retained. The comparison table summarises API availability across platforms; where an Analytics & reporting section says Not public, ask the vendor before you build a scorecard on it.