[Openrtb migration] alternative field for detected_content_label

26 views

Skip to first unread message

Tâm Ngô

unread,

Dec 23, 2024, 3:43:53 AM 12/23/24

to Authorized Buyers API Forum

Hello,

I'm working on migration from google rtb protocol to openrtb, we use this field " detected _ content _ label " for some filtering logic, but the document states it is not supported by openrtb protocol. I would like to know what is the alternative for it? or will it be abandoned completely?

https://developers.google.com/authorized-buyers/rtb/openrtb-migration/bid-request

Thanks,

Tam

Authorized Buyers API Forum Advisor

unread,

Dec 23, 2024, 1:10:44 PM 12/23/24

to tam...@knorex.com, google-doubleclick-a...@googlegroups.com

Hello Tam,

Although the detected_content_label field exists in the Google RTB protocol, it isn't actually populated currently. Generally speaking, when you read through the OpenRTB migration content, fields that are marked unsupported are either already effectively deprecated such as this one, or have low/no usage. In this case, the product and engineering team decided that the best course of action for detected_content_label was to not extend OpenRTB in order to support this field.

It's worth noting that some of these labels are found in other areas of the protocol, such as Content . For example, OpenRTB's contentrating field provides similar values for:

39 Digital Content Label for DL-G rating
40 Digital Content Label for DL-PG rating
41 Digital Content Label for DL-T rating
42 Digital Content Label for DL-MA rating
43 Digital Content Not Yet Rated

That said, for many of these, it seems like the intent is to categorize the content where the impression originates. Something similar could hypothetically be done in OpenRTB, such as via BidRequest.{app/site}. content.cat / BidRequest.{app/site}.content.cattax , but I see that these aren't supported currently either. I'd like to present this use-case to the product and engineering team, in order to verify whether I've overlooked some alternative that is supported, or if not, whether this is something we're interested in adding support for in a future update. I'll follow up with more details, but as an FYI, given the time of year we may see slower than usual response times.

This message is in relation to case "ref:!00D1U01174p.!5004Q02vGqCL:ref" (ADR-00279591)

Thanks,

Mark Saniscalchi

Authorized Buyers API Team

Feedback
How was our support today?

Reply all

Reply to author

Forward

0 new messages