OpenRTB 2.2 badv & bcat fields - Best practices

[Kevin Hunt]

Hi ORTB user group,

I'm curious about the optional badv and bcat fields in section 3.3.1 Bid Request Object in the OpenRTB 2.2 specification. Sometimes this list of advertisers can be extremely long. It is causing errors with some DSPs because of the length when we submit bid requests. I thought I'd check in with the team here to see if anyone has comments or strategies to deal with large list of advertisers or categories.

• Do you use these fields?
• How do you deal with large block list content?
• Do you have other online or offline strategies to deal with this?

badv

optional

Array of strings of blocked top-level domains of advertisers. For example, {“company1.com”, “company2.com”}. 

Thanks,

Kevin

[Ian Trider]

Hi Kevin,

Just to share some thoughts from the DSP perspective:

• Please absolutely do cap the number of domains you send in badv.  bcat should never end up being a problem assuming the standard strings are being used (i.e. "IAB1-1").
• You could use the original OpenRTB Blocklist Sync protocol (i.e. OpenRTB 1.2) to transmit offline blocklists -- if any DSPs still support this.  We sunset support since its utility was outlived and superceded by better options (namely sending multiple bids)
• Allowing multiple bids in response mitigates the need to send bcat at all, since "wasted bids" are no longer a concern

[Kevin Hunt]

Hi Ian,

Thanks for the contribution. Regarding bcat how might I decide which advertisers to include and what to exclude to stay under a defined threshold?

Kevin

[james....@blis.com]

I'm not sure how a long badv list can lead to errors for a DSP.
In our case we read and enforce them all (as long as the format is correct), but we have the option of enforcing a length restriction if a publisher goes crazy, in that case we'll just immediately no-bid.

[Ian Trider]

That's essentially what we do too -- so I guess it depends on how you define "error". 

Should the bid request be sufficiently large (which can happen assuming a crazy list of badv -- I've seen individual bid requests that are pushing 100KB+!), we just abandon the attempt to process it thus opting out of the opportunity, but it has some knock-on effects impacts to the bidders due to the overhead.

[Ian Trider]

You could get fancy and send the top X based on the DSPs bidding pattern (i.e. no point to send badv that the DSP never bids with).  Or you could just cut off the list hard.  Again, with support for multiple bids it really doesn't matter to have DSPs bidding with blocked advertisers, as long as they're sending enough bids for each bid response so that the best non-blocked bid is included.

[Alex Merwin]

Does anyone store blocklists in a discrete service to the bidding protocol? The list doesn't change on individual bid requests. Only when publishers update their configuration in the system. Seems like a lot of wasted transfer bandwidth for duplicate data..

~ Alex

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
----------------------------------

Alex Merwin | VP, International
SpotX
M: +44 7490 132754

Sent from a mobile device, please excuse brevity.

[Jim Butler]

Interestingly, this was the inaugural effort when OpenRTB was formed in 4Q2010 (before working on the actual bid request/response protocol).  The specification was completed, but it was not widely adopted.

:JB

James M. Butler, Ph.D.

VP Engineering, Publisher Platforms | AOL Platforms

155 Seaport Blvd, 8th Floor, Boston MA 02210

+1.617.834.2125 | Mobile

jim.b...@teamaol.com

 

[james....@blis.com]

This is going off topic a bit but it surprises me, after having conversations with them, how much some SSPs seem to allow DSPs get away with.
Isn't bidding with a blocked advertiser a waste of everyone's time? For the DSPs in terms of traffic costs and for SSPs in terms of processing time and probably data costs too?
We don't do multi-bid, we'd prefer to have full control over what is considered 'best' rather than letting an SSP decide that for us.

[Alex Merwin]

JB - I recall that too. Do you or anyone else on the dev group have access to that protocol and can share details? If we could agree on the protocol I could see that API service solving a lot of problems for both SSPs and DSPs. We could detail that protocol as an addendum to the spec since it's not really part of the bidding process per say. I'd imagine SSPs would host their blocklists and DSPs would ping a REST API to update their hosted versions on a daily basis (or hourly, if they wanted more recency). 

Alex Merwin | VP, International

M: +44 (0) 7490 132 754 | Skype: amerwin_7 | LinkedIn  

[Ian Trider]

One reason some SSPs have stated to me that they WANT those bids is that it allows them to produce "lost opportunity" reporting for publishers (to reconsider blacklist).

Interestingly, the reason why we stopped using the OpenRTB blacklist API on our DSP is because it was causing us nuisance with PMP deals, where the deal might supercede the normal blocklist.  I suppose this could be addressed by having bidders ignore the blacklist for deals, but just raising this as one nuance that came up.