OpenOOH Health & Beauty taxonomy explorer

Beauty inventory is only addressable if it’s classified correctly — and the classification is a standard, not a guess. The OpenOOH Venue Taxonomy is the shared language SSPs and DSPs use to describe what a screen is, and it resolves beauty down to the exact ID a buyer targets. This reference lays out the Health & Beauty branch, the targeting rules that decide whether your inventory is found, and how the venue type travels in the bid request.

The Health & Beauty branch

The taxonomy has 11 parent categories; beauty is parent 4. The full branch, verified against the spec (OpenOOH — primary):

Tier	Name	enumeration_id	string value
Parent	Health & Beauty	4	`health_beauty`
Child	Gym	401	`health_beauty.gym`
Child	Salon	402	`health_beauty.salon`
→ Grandchild	Unisex Salon	40201	`health_beauty.salon.unisex`
→ Grandchild	Men’s Salon	40202	`health_beauty.salon.mens`
→ Grandchild	Women’s Salon	40203	`health_beauty.salon.womens`
→ Grandchild	Nail	40204	`health_beauty.salon.nail`
→ Grandchild	Tanning	40205	`health_beauty.salon.tanning`
Child	Spa	403	`health_beauty.spa`
Child	Tattoo	404	`health_beauty.tattoo`

Note the string is singular (health_beauty.salon, not salons); Spa (403) has no grandchildren, so it’s targeted at the child level. The taxonomy is governed by the OAAA and was last refreshed in early 2026 — use the current IDs.

The targeting rules that decide if you’re found

Two rules from the spec itself govern how the branch is targeted — and they’re the difference between addressable and invisible (OpenOOH — primary):

“No screens should be solely assigned to a parent venue type, unless that parent has no children.” → A salon should be tagged at Salon (402), not just Health & Beauty (4).
Grandchildren are “optional and at the purview of the publisher or supply-side platform.” → Women’s (40203) and Nail (40204) may or may not be populated for a given screen.

Translated into buying instructions:

Target Salon (402) and Spa (403), not the parent (4). The parent sweeps in gyms (401) and tattoo (404) — the wrong audience.
For a women’s-only or nail-bar buy, target 40203 / 40204 where publishers populate them — but don’t over-restrict, because if a nail-bar network only tagged at Salon level, narrowing to 40204 can zero out your fill. Check how each SSP populates the branch first.
For operators: classifying your screens correctly is the single most controllable step that makes them findable by the contextual demand most likely to buy — mis-tag, and the right advertiser never sees you.

How the venue type travels

The venue ID rides inside the bid request, and the mechanism depends on the OpenRTB version — sending the wrong one means no venue targeting (OpenOOH spec, Prebid — primary):

OpenRTB 2.6 (current): on the native DOOH object — dooh.venuetype (the numeric OpenOOH ID), with the taxonomy declared in dooh.venuetax (OpenOOH is assumed if omitted).
OpenRTB 2.5 (legacy): in the device extension — device.ext.dooh.venuetypeid (single ID), venuetypelist, or venuetypestring.

The current OpenOOH spec operates in a 2.6 context; confirm which your supply path speaks. (The full buying workflow is in Programmatic DOOH via DSPs.)

Why this is the whole beauty skill

Everything else about buying salon screens programmatically is generic DOOH — the same rails, the same deal types, the same DSPs. The only beauty-specific move is getting this classification right. It’s also why “Health & Beauty” being a standardised, top-level class matters strategically: it means a brand can deliberately choose to advertise in a salon or nail bar, your inventory is a clean line item rather than a bespoke ask, and the whole category is buyable the same way as any other DOOH.

Methodology & caveats

Verified (primary): the OpenOOH Health & Beauty branch — parent 4; children Gym 401, Salon 402, Spa 403, Tattoo 404; salon grandchildren 40201–40205 with their string values — and the targeting rules (“no screens solely on a parent with children”; grandchildren publisher-optional), verified against the OpenOOH Venue Taxonomy specification (governed by the OAAA). The bid-request transport — dooh.venuetype / dooh.venuetax (OpenRTB 2.6) vs device.ext.dooh.venuetypeid (2.5) — from the OpenOOH spec and Prebid DOOH docs. Note: the OpenOOH repo description still references “OpenRTB 2.5” while the spec body operates in 2.6 — cite the spec body. Confirm IDs and protocol fields against the current spec before building a buy, as the taxonomy is periodically updated.