A team has hundreds of ads but cannot answer a simple question: which customer concerns have we tested? The files are organized by month and format, so the underlying ideas disappear inside folders named “video,” “static,” and “final.”
A creative taxonomy adds a shared vocabulary for the decisions behind each asset. It should make production and analysis easier without requiring every creator to complete a large administrative form.
Start with questions the team actually asks
List a few retrieval needs: find product demonstrations, compare proof approaches, identify tested objections, recover the original offer, or locate every variant derived from one concept.
Choose fields that answer those questions. A field that never helps anyone find, compare, approve, or interpret an asset may not belong in the first version.
Use the creative hypothesis template as a starting point. The taxonomy should preserve the hypothesis's meaningful parts rather than invent a separate classification system that the brief never uses.
Separate concept from execution
A concept is the central communication idea, such as demonstrating fit in a small space. An execution is a particular realization: a creator video, a product animation, or a static before-and-after layout.
Keep those fields separate so the team can see whether it has explored different ideas or only produced many versions of one idea. A large asset count can conceal a narrow set of customer messages.
Do not assume different formats are equivalent executions. A format may change how the idea is understood. The taxonomy makes that difference visible; it does not remove the need for interpretation.
Use a compact field set
| Field | Example meaning |
|---|---|
| Stable asset ID | The unique record for this produced version |
| Concept | Demonstrate fit in a narrow space |
| Customer concern | Uncertainty about dimensions |
| Hook | Open with a measured cabinet interior |
| Proof | Actual product demonstration |
| Offer | Current single-product offer |
| Format | Vertical creator video |
| Parent version | The source concept or asset this version changes |
| Hypothesis ID | Link to the decision the asset tests |
These are illustrative fields and values, not a mandatory industry standard. Adapt them to the team's real workflow and product vocabulary.
Keep performance out of stable identity
“Winner,” “loser,” and “fatigued” are observations or interpretations at a point in time. They should not replace the asset's permanent identity.
An ad can be useful in one campaign and weak in another. A filename such as “best-ever-final” hides that context and becomes misleading when reused.
Store performance records separately with the campaign, period, metric definition, and evidence. Link them to the stable asset ID. The learning repository guide explains how to preserve that context without flattening every result into a permanent label.
Define ambiguous terms with examples
Terms such as “UGC,” “testimonial,” “demo,” and “problem-solution” can mean different things to different teammates. Write a short definition and include two examples plus a near-example that belongs elsewhere.
For instance, a creator describing a product is not automatically a customer testimonial. If the person is acting from a script, the record should describe the actual production context rather than imply an authentic customer experience.
The FTC's advertising FAQ provides a reference for why the message's overall meaning matters. Internal labels should not encourage the team to treat unsupported proof as legitimate evidence.
Allow uncertainty without creating chaos
Some assets contain several hooks or address multiple concerns. Decide which fields require one primary value and which can accept a small number of tags.
Use an explicit “unclassified” state during migration rather than inventing a confident label. Review recurring unclassified cases to decide whether the taxonomy needs a new category or clearer definitions.
Avoid creating a new tag for every phrasing variation. The vocabulary should help compare related work, not reproduce the full script as metadata.
Test the taxonomy on a small real sample
Ask two teammates to classify the same representative assets independently. Compare disagreements. If they regularly choose different concepts or proof types, refine the definitions before applying the taxonomy across the library.
Also test retrieval. Can a buyer find all assets relevant to a customer concern? Can a creator locate the latest approved version? Can an analyst connect performance to the intended hypothesis?
These practical checks matter more than how elegant the category tree looks. A taxonomy that people cannot apply consistently will produce misleading analysis.
Keep filenames readable and records richer
Use a concise naming convention for everyday recognition, with a stable ID linking to the fuller record. The agency naming guide covers this distinction across client accounts.
Do not cram every field into the platform ad name. Long names are hard to scan, and mutable information becomes stale quickly. The underlying record can carry details that the visible name does not need.
Preserve parent-child relationships when resizing, translating, or editing an asset. A new version should reveal what changed rather than erase its lineage.
Maintain the vocabulary through production
Assign one owner for category changes and allow creators to propose improvements. Review the taxonomy when new products, formats, or customer concerns appear.
Version material definition changes so historical analysis remains understandable. If “demonstration” becomes narrower, old assets may need reclassification before their results can be compared under the new definition.
The best taxonomy is the smallest shared vocabulary that lets the team find useful work and interpret what it has learned. Its success is visible in better briefs, faster retrieval, and fewer repeated tests whose history was lost.