Add: Handling of unrecognized categories (e.g. forwards compatibility)

[jayshao]

Ideally it would be nice to find a solution that allowed sellers and buyers to upgrade and update their support for OpenOOH categories independently, while not disrupting media trading. In general, this seems to amount to either expectations for forwards or backwards compatibility:

1. What should a buyer do if it sees a category it doesn't know about (e.g. from a more recent version of the spec)?
2. What kind of notice (if any) should a seller provide about what version of the spec they support?

Possible options seem to range from liberal to conservative:

• Unknown categories are ignored - requests are processed as if no venue provided (does this make sense?)
• Unknown categories are treated as errors - requests are ignored (ideally with a suitable error code)
• Sellers are expected to send permutation across all supported spec versions

[christiancollins11]

I'd lean towards "ignoring" unknown categories. There are two main use cases I can see -- a DSP targeting specific venue types and a DSP including venue types in reporting.

For targeting, there are a number of other valid targeting strategies beyond venue type, and if a DSP were to be targeting specific venue types, then presumably their bidder would just not bid on any venue types they did not recognize. If a media owner includes a screen with an unrecognized venue type in a PMP, I wouldn't want to block the DSP from transacting on that screen if they were targeting the PMP's deal ID.

For reporting, I'd need some insight from DSPs. I would guess that DSPs log the venue type ids from transactions and then host some mapping in whatever reporting tool they offer. If impressions serve on an unrecognized venue type, the DSP can show the ID, nothing, or whatever fits best with their conventions. Seems like overboard to error on requests for the risk of not being able to report on venue type, but again, I'll defer to the DSPs of the group here.

As far as communicating changes, I'd put the onus on the sellers. Sellers are responsible for communicating available inventory to buyers, and the supported venue types are relevant metadata to include.

[mowasfi7]

From a DSP perspective, I would also go with the first option, treating unrecognized venue types as unknown.

However, do you foresee this happening often? As long as we agree on a release cycle e.g. quarterly, and the changes are known in advance, then we should have enough time to introduce the relevant changes.

Or am I missing something?

[bruno8g]

I also prefer option 1. If no specific venue types are targeted in the DSP, meaning all venues are included in the strategy, the bid should go through.

[jayshao]

One of my overriding goals is to enable independent updates across parties (e.g. not have to get stuck with: "DSPs have to update first" for instance - so to see if there are any limits to forwards-compatibility. I see 2 possible cases that I can think of right now:

1. A parallel discussion we had in the early days of the IAB content taxonomy was around blocking. For instance: Add: Leisure -> Night Clubs #16 requests adding a category for Gentleman's Clubs. I'd be curious if people think there might be brand-safety concerns with that kind of venue. If yes, I think it's worth us talking about expectations if a new category like that showed up? In the original IAB Content Taxonomy, we solved this with a "Restricted" parent, which is where non-brandsafe items were supposed to go... which wasn't necessarily a great solution all around, but it's an approach that's been carried forward in the new taxonomy, I think under "Sensitive Topics" aligned with some of the work from GARM: https://wfanet.org/l/library/download/urn:uuid:7d484745-41cd-4cce-a1b9-a1b4e30928ea/garm+brand+safety+floor+suitability+framework+23+sept.pdf

2. The other question I'd have is what is the compatibility impact for hierarchy moves? A number of proposals for instance would involve either a) moving items in the hierarchy or b) splitting out sub-categories. If we do so - does that have any targeting/blocking implications? E.g. should a compliant implementation handle unknown children by reverting to the parent vs treating it as unknown? Moved items seem like you might get slightly different interpretations, but presumably that is in control of the targeting platform, and so internally consistent

[jayshao]

Notes from: #49

• lowest-friction convention seems to be "ignore categories you don't understand" but does that cause blocking challenges?
• blocking can be handled against other attributes (e.g. media-owner)
• DSP could take on responsibility to update their taxonomy based on their risk tolerance
• allow list could be recommended as an approach instead of relying on blocking categories
• so far most feedback/comments have been relatively minor
• we could specify how to handle unknown categories - block them into "other" perhaps?
• do we want to incorporate semantic versioning? what is the threshold of materiality of a "major" change that would prompt a 2.0?

Proposal: DSPs should ignore unknown (presumably more recent) categories (+7,-0)