How do you build a custom content taxonomy and map it to IAB IDs?
Part of Contextual targeting
The short answer
A custom content taxonomy is a client's own list of topics, each with a written definition, a stable ID and a recorded link to IAB Content Taxonomy IDs. Build it from the briefs the client repeats, map each topic with a stated match type, pin the IAB version, and give one person the job of releasing changes.
Key takeaways
- A client needs its own taxonomy when its briefs keep asking for subjects narrower or differently cut than any IAB category.
- Each custom topic should record its IAB ID, the IAB version and whether the match is exact, close, broader or missing.
- Depth should stop where a reviewer can no longer tell two sibling topics apart from a sample article.
- One named owner, a release number and a change log keep the taxonomy usable when agencies and staff change.
- Agencies stay consistent when they share the same IDs and preferred labels, not just similar topic names.
When does a client need its own content taxonomy?
The IAB Tech Lab Content Taxonomy (opens in a new tab) is the shared vocabulary of the trade, and Tech Lab names contextual targeting and brand safety as its typical uses. It is built to describe the whole web, so it cuts subjects the way publishers and exchanges need them cut. A brand's briefs cut them the way its products and campaigns need them cut.
Definition
- Custom content taxonomy
- A client owned, versioned list of content topics in the client's campaign language, each with a definition, a stable ID and a recorded mapping to standard category IDs.
A custom taxonomy costs time to build and maintain, so it should solve a problem the client already has. IAB Tech Lab's implementation guidance (opens in a new tab) says "Neither taxonomy can be changed, though customization for your implementation is an option."
| Situation | Points toward a custom taxonomy | Points toward IAB IDs alone |
|---|---|---|
| Brief language | Briefs keep naming subjects like weekend bread baking that sit below or across IAB categories | Briefs name broad subjects such as cooking or home improvement |
| Number of agencies | Two or more agencies, or an in-house team plus an agency, plan for the same brand | One team plans and buys for the brand |
| Reuse | The same topics come back in brief after brief, season after season | Each campaign is a one-off with its own subjects |
| Reporting | The client wants results by its own topic names across years | Results by platform category are acceptable |
| Languages | Topics need English and French labels with one meaning | One language and one market |
How do you map custom topics to IAB category IDs?
The mapping is a crosswalk: a table that records, for each custom topic, which standard ID it points to and how good the fit is. The ID comes from the "Unique ID" column of the official Content Taxonomy 3.1 file (opens in a new tab), never from a label that looks similar. The quality of fit borrows from the W3C's SKOS vocabulary (opens in a new tab), which separates an exact match, where two concepts "have equivalent meaning", from a close match, where they are "sufficiently similar that they can be used interchangeably."
Six steps to map one custom topic
- Write the topic definition first. Two sentences on what an article about this topic covers, and one on what it does not cover.
- Search the official file, not a summary. Open the 3.1 TSV and look up candidate rows by name and by parent, so a nearby sibling is not missed.
- Record the Unique ID and its parent ID. Labels can be renamed between versions; IDs are what partners read. Tech Lab's guidance says "The IDs within the Taxonomy specs should be used when tagging content."
- Choose a match type. Exact, close, broader (the IAB row is wider than the topic) or none. A broader match is honest and still useful for reach; it is not the same claim as exact.
- Allow one topic to point to two IDs when the content really spans both. Note which ID is primary so reports do not count the topic twice.
- Stamp the row with the taxonomy version and the date. A crosswalk without a version cannot be checked later.
How deep should a custom taxonomy go?
Depth is a cost, not a goal. The W3C's Data on the Web Best Practices (opens in a new tab) say "Choose the right formalization level", so the likely uses "will be supported with no more complexity than necessary." For a content taxonomy those uses are briefs, sample reviews and reports.
A new level earns its place when
- A reviewer reading one sample article can tell which of the new sibling topics it belongs to.
- At least two recent or planned briefs would use the narrower topics separately.
- Each narrower topic still has enough publishers writing about it to fill a site list.
- The narrower topics need different creative, different avoid rules or different reporting.
A workable shape for a single brand is two levels: a few themes that match the client's business lines, and topics beneath them that match how briefs are written. Add a third level only where sample reviews show reviewers can split a theme consistently. Topics too narrow to find publishers belong in the brief as an example article, not in the taxonomy.
Who maintains a custom taxonomy over time?
IAB Tech Lab runs its own taxonomies through a working group and a written versioning policy (opens in a new tab): major version numbers "represent breaking changes" and minor ones "represent improvements such as new rows that do not change the taxonomy's hierarchical structure." A client taxonomy needs a smaller version of the same discipline.
| Role | Held by | What the role does |
|---|---|---|
| Owner | A person on the client side, such as a media or brand operations lead | Approves new topics, retires old ones and signs off each release |
| Editor | The lead planner at the agency of record | Drafts definitions, updates the crosswalk and keeps the change log |
| Reviewers | Planners at each agency that uses the taxonomy | Test new topics against sample articles and flag topics that overlap |
| Partners | Publishers, exchanges and verification teams receiving IDs | Receive the current release and the IAB version it maps to |
Give the taxonomy a release number and a change log, following the W3C advice to "Provide a version indicator" and "Provide version history." Treat a renamed or merged topic as a breaking change: keep the old ID in the log with a pointer to its replacement, and never reuse a retired ID. Review the crosswalk whenever IAB publishes a new version, since Tech Lab notes that Content Taxonomy 3.0 "may not be used alongside earlier versions."
How do you keep custom labels consistent across agencies?
Agencies drift apart when they share topic names but not IDs: one team writes "baking", another "home baking", and a year of reports no longer adds up. The SKOS model gives each concept one preferred label per language, since a concept "can only have one such label per language tag", plus alternative labels. The ID is the join key.
Consistency checks before a taxonomy release goes to agencies
- Each topic has one stable ID that no other topic has ever used.
- Each topic has one preferred label in English and, for Canadian work, one in French.
- Alternative labels and known misspellings are listed, so search and reporting catch them.
- Each topic's crosswalk row names the IAB version, the Unique ID and the match type.
- Briefs and reports from each agency cite topic IDs, not free text names.
When topics leave the client's systems, send standard IDs, not custom labels. IAB Tech Lab's OpenRTB implementation guidance (opens in a new tab) says the gtax attribute "allows buyers and sellers to align on a taxonomy that both parties are able to read." A custom label means nothing to a partner without the crosswalk. The OpenRTB Content object guide covers the fields.
What does a custom taxonomy look like on a real brief?
Fictional example
A kitchen appliance maker with two agencies in New Jersey and Connecticut
A fictional stand mixer and countertop appliance maker plans display campaigns in New Jersey and Connecticut through a digital agency, while its in-house team buys a smaller holiday program. The two teams wrote briefs in different words, so year end reports did not match. The client's brand operations lead becomes the owner, and the agency's lead planner the editor.
The editor reads twelve months of briefs and finds five topics that keep returning. Each gets a definition, an ID and a crosswalk row. Gluten free baking maps only closely to the IAB Food Allergies row, since it also covers diet preference. Kitchen remodel planning is marked broader, because the IAB row covers all remodeling.
Both teams now cite topic IDs in briefs and reports. Release 1.0 ships with the date and the IAB version on the file, and a request for a mixer repair topic waits for the next release because no brief has used it yet.
| Client topic (ID) | IAB 3.1 Unique ID and name | Match type | Note |
|---|---|---|---|
| Weekend bread baking (KA-01) | 217, Desserts and Baking (parent 210, Food & Drink) | Broader | IAB row also covers cakes and sweets |
| Holiday cookie baking (KA-02) | 217, Desserts and Baking | Broader | Seasonal topic, reviewed before each fall |
| Gluten free baking (KA-03) | 219, Food Allergies; 217 secondary | Close | Covers diet preference as well as allergy |
| Countertop appliance care (KA-04) | 278, Home Appliances (parent 274, Home & Garden) | Broader | Excludes large appliance repair |
| Kitchen remodel planning (KA-05) | 276, Remodeling & Construction | Broader | Kitchen pages only, judged from samples |
How does PlacementGraph work with a client's own topics?
How do you roll a custom taxonomy out without breaking current campaigns?
Introduce the taxonomy at the brief, not in live campaigns. New briefs cite topic IDs from release 1.0, while campaigns in flight keep their settings until their next review. Reports gain a topic ID column filled from the brief behind each line, so nobody reclassifies old placements by hand.
Before release, give two reviewers from different teams the same sample articles and definitions. Topics they sort differently need a sharper definition or a merge, as the relevance check guide describes.
Frequently asked questions
Should brand suitability categories live inside the custom taxonomy?
Keep them separate. Content topics describe what the client wants to appear beside; suitability settings describe what it will tolerate. Mixing them makes a topic like crime news look like a targeting choice. Instead, list for each topic the suitability categories that need extra review, and keep tolerances in the client's suitability profile.
Can a custom taxonomy be shared with publishers?
Yes, the definitions and IAB crosswalk can be shared when a publisher builds a package or a private deal for the client. Send the release number with them, so the publisher knows which version its package matches. Internal notes, such as spend by topic, stay in a separate file.
What happens to the crosswalk when IAB releases a new taxonomy version?
Review it as a separate task. Check that each mapped Unique ID still exists with the same meaning and parent, update rows that moved, and record the new IAB version on the next client release. Client topic IDs stay the same; only the crosswalk rows change.
Is a spreadsheet good enough for a custom taxonomy?
For one brand with a few dozen topics, a shared spreadsheet works if it has fixed columns for topic ID, labels, definition, IAB ID, IAB version, match type and status. What matters is that one file is the master copy, its release number is visible, and edits go through the owner.
Sources
- Content Taxonomy (opens in a new tab)IAB Tech Lab
- Content Taxonomy 3.1 (TSV file) (opens in a new tab)IAB Tech Lab, Taxonomies repository on GitHub
- Taxonomies implementation guidance (opens in a new tab)IAB Tech Lab, GitHub
- IAB Tech Lab Taxonomies repository and versioning policy (opens in a new tab)IAB Tech Lab, GitHub
- SKOS Simple Knowledge Organization System Primer (opens in a new tab)W3C Working Group Note, August 18, 2009
- Data on the Web Best Practices (opens in a new tab)W3C Recommendation, January 31, 2017
- OpenRTB 2.x implementation guidance (opens in a new tab)IAB Tech Lab, GitHub
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.