Clarify BidRequest limiting requests to a single venue category (parent, child, or grandchild)

[ericlucit]

It would be nice if the spec provided recommended examples for how the types are placed in the bid request.

It currently has a general description, but concrete examples would be beneficial - For instance, I am not sure if it is clear whether or not a single device object can be assigned to multiple venue types that are not parent/child related to each other

It appears that this is true, but, this description is a bit fuzzy to me

The enumerated list can be passed in the bid request. It is a comma-separated array of category IDs from the preceding and dependent tiers. Should only a parent-child category be associated with the screen’s venue, the array will be composed of two enumerated IDs. Refer to the summary chart for further details.

So would these examples be valid?? :

device.ext.dooh.venuetypelist : [101,102]

device.ext.dooh.venuetypelist : [101,201,301]

If examples were provided that made this concrete, that may help resolve issues such as

• How to categorize venues that are both a bar and restaurant? #23 (comment)

Or any other issues where a single category does not apply to a device.

[christiancollins11]

Agree we should update the spec explicitly call out that a screen can have at most one parent, child, and grandchild venue type, and that including some examples would help reduce confusion. Providing an array of venue types is intended to allow buys to easily identify the requesting screen's parent, child, and grandchild venue type (e.g. device.ext.dooh.venuetypelist : [1,101,10101]), so they can apply venue type targeting for each level. The array is not intended to allow screens communicate multiple parent, child, or grandchild venue types. If there are concerns that the taxonomy is not accurately describing a specific venue type, I would suggest proposing an amendment to the taxonomy with the desired venue type + description.

[jayshao]

Notes from #49

• counter-proposal to discard hierarchy, and allow multiple, flat tags
• concerns about fragmenting based on different interpretations, or how to interpret
• there may be some benefits to constraining the number of categories - and forcing smaller sub-divisions
• adjacent POI or other metadata could represent multiple categories if we force a single assignment?
• would that be the same spec? or would it be orthogonal?
• one merit of tagging is allowing cross-cutting categories
• how complicated should the taxonomy be? When should we rely on other targeting (e.g. PMPs)

Proposal: Clarify spec that the expectation is a given request is only classified against 1 venue (+7, -1)