Re: OpenRTB 2.3 - the recommended method of specifying “no bid”

[Christopher Gu]

http://www.iab.net/media/file/OpenRTB-API-Specification-Version-2-3.pdf

"All calls should return HTTP code 200 except for an empty bid response (i.e., the recommended method of specifying “no bid”), which should return HTTP code 204."

Why?

How can you send the nbr or No Bid Reason if the response is 204?

"To express a “no-bid”, the options are to return an empty response with HTTP 204. Alternately if the bidder wishes to convey to the exchange a reason for not bidding, just a BidResponse object is returned with a reason code in the nbr attribute."

I had a little trouble integrating Rubicon, and Smaato and a few other OpenRTB with NginAd OpenRTB Open Source Ad Server because of this.

https://github.com/cdnpal/nginad/blob/master/upload/module/BuyGenericRTB/src/BuyGenericRTB/common/workflows/OpenRTBWorkflow.php

The DSP sending the OpenRTB bids needs to know the no bid reason.

I had Forensiq flag a DSP for 100M+ RTB Ad Fruad real time API requests that were billed to us.

https://www.linkedin.com/pulse/when-nuke-dsp-rtb-end-point-christopher-gu

The DSP did not know that the no bid reason was ad fraud, so they kept sending requests

Sending a 204 back tells the DSP nothing about why you are not bidding so why is that the default?

[Jim Butler]

The spec does not say to send a response with the "nbr" attribute AND code 204.  It says that one method of expressing a no bid is to return an empty response with HTTP code 204.  It also says as you pointed out that all calls except for this empty response should be HTTP 200.  Therefore, if you opt for the alternative method for expressing no-bid (i.e., sending a response so that you can report a reason in the "nbr" attribute), the response would not be empty and thus you would send code 200 in accordance with HTTP norms.

As for choosing the empty response for what we call the default, bear in mind that not all previous versions of the spec included the "nbr" attribute.  In those versions, there was no value-added alternative for expressing no-bid.  The alternative (and some bidders actually do this still believe it or not) was to pass a response with a valid JSON structure that has no bid objects.  This has no value and actually just sucks up bandwidth and processing.  Now that the "nbr" attribute has come along, there is a very good reason for sending a non-empty response, but we didn't feel there was a compelling reason to change the language.  I think it still makes sense that the simpler method is the default especially since calling one or the other a default has no material impact on the spec.  And "default" doesn't imply "recommended".  It simply recognizes that an exchange and a bidder have to do basically nothing to implement that method; the very peak of default-ness.

Now, to all DSPs reading this...  By all means, please convey the reason you're not bidding by responding with a minimal JSON structure that includes a valid "nbr" value and use HTTP code 200.  If you can't send "nbr" or just don't want to, then please send an empty response with HTTP 204.  Much appreciated on behalf of at least one exchange.

:JB

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James M. Butler, Ph.D. | SVP Technology
millennial media
Mobile: 617.834.2125 
Email: jbu...@millennialmedia.com
Web: www.millennialmedia.com
Twitter: @millennialmedia
Facebook: Facebook/millennialmedia

[Christopher Gu]

"The spec does not say to send a response with the "nbr" attribute AND code 204."

I'm aware. The NginAd PHP server sends 200 and the nbr by default. The problem is that because of the spec's recommendations, exchanges are ignoring the no bid reason completely. The latest I saw do this was Smaato.

If my bidder has sent back the OpenRTB nbr reason "4 Suspected Non-Human Traffic" 20 million times for the same publisher(s), and has charged the NginAd server user 20 million API calls on Forensiq to determine that over and over again(caching is not allowed), I expect the DSP to stop sending bid requests for that publisher automatically.

The DSP can send badv for publishers, but the OpenRTB media buyer must email the DSP to remove publishers.

I hope that in future versions, nbr/200 can become the recommended method.

Chris - NginAd Open Source PHP Ad Server

[Christopher Gu]

Correction: The DSP can send badv for blocked advertisers, but the OpenRTB media buyer must email the DSP to remove publishers.

[Wesley Biggs]

Hi Chris,

I'm finding your message hard to parse. It's the SSP (supply side) that sends bid requests -- the DSP (demand side) represents is the media buyer.

There is nothing in the spec that suggests that a SSP should stop sending bid requests to a DSP based on no-bid reasons. As you say, this is an out-of-band operation which often involves emailing the SSP. I note that some SSPs/Exchanges provide integration APIs that can be used to programmatically control or filter which bids get sent, but this is outside the scope of OpenRTB currently.

I'm not very familiar with NginAd, but it seems to me that it should keep some state on whether a particular publisher (publication?) exhibits a high level of suspected non-human traffic, and use this information to ensure that further calls to Forensiq aren't needlessly made.

Regards,

Wes

Wes Biggs

Co-Founder and Chief Architect 

t:   +44 203 021 1262

m: +44 7910 837 436 

e:  wes....@byyd-tech.com

w: byyd-tech.com 

[Christopher Gu]

Hi Wesley,

I think shut off due to no-bid reasons should be automated, and I wasn't going to reply, but the DSP/SSP is debatable.

"I'm finding your message hard to parse. It's the SSP (supply side) that sends bid requests -- the DSP (demand side) represents is the media buyer."

WIKIPEDIA:

https://en.wikipedia.org/wiki/Demand-side_platform

A demand-side platform (DSP) is a system that allows buyers of digital advertising inventory to manage multiple ad exchange and data exchange accounts through one interface

DSPs supply demand to publishers or ad networks either programmatically by sending out RTB requests, or via a demand dashboard like this one:

http://apps.pubmatic.com/mediaconsole/

In the programmatic scenario, the peer acts as an agent to the media buyer

WIKIPEDIA:

https://en.wikipedia.org/wiki/Supply-side_platform

A supply-side platform or sell-side platform (SSP) is a technology platform with the single mission of enabling publishers to manage their advertising impression inventory and maximize revenue from digital media.

SSPs supply inventory programmatically by consuming RTB request programmatically, or directly via a publisher dashboard such as this one:

https://apps.pubmatic.com/publisher/

In the programmatic scenario, the peer acts as an agent to the publishers.

I've seen both DSPs and SSPs interchanged by different ad exchanges out there while doing integrations.

For Example, Smaato appears to agree with it being backwards here: http://dspportal.smaato.net/documentation

While Avazu got it right: http://mdsp.avazutracking.net/home/ (they BOTH send RTB bid requests), Avazu claiming to be a DSP while Smaato claims to be a SSP ( http://dspportal.smaato.net/documentation )

Chris

[Neal Richter]

Chris,

The way this generally works is that when a DSP sends back nbr codes instead of HTTP 204, it's up to the SSP to parse, log and take action.    These actions are out of the scope of the spec.  As Jim notes we added back the NBR codes in OpenRTB 2.1 and reset the codes.

We take action on any suspected non-human traffic by incorporating into our traffic quality scoring analysis and will take action as needed based on what we detect with many data signals.  All other SSPs/Exchanges will have their own policy on consuming nbr codes.

Note also that the OpenRTB spec is not definitive in this situation (ambiguity on best no-bid methodology) and you need to look at the SSP/Exchange integration docs to see what they support or ask for.  Of course they probably all handle either 204 or empty response just fine.

I agree with Wesley that your statements are confusing as DSPs send not receive the responses.

Thanks -Neal

[Christopher Gu]

Hi Neal,

"We take action on any suspected non-human traffic by incorporating into our traffic quality scoring analysis and will take action as needed based on what we detect with many data signals"

I assume you mean Rubicon Project by "we".

I see you moved the documentation off of WordPress to Mashery, so I had to re-register. I found that though you are accepting 200 codes now, you are still recommending not sending a no-bid reason:

The NBR response is only listed as the third and final option.

But now look at Smaato's OpenRTB docs: http://dspportal.smaato.net/documentation

They are saying ONLY a 204 empty response can be returned, BASED ON the OpenRTB spec.

HERE IS MY CONCERN

Forensiq, Moat, DoubleVerify, and these other ad fraud solutions charge on a PRICEY CPM BASIS with a high minimum monthly fee.

So if one exchange uses the Ad Fraud API for one of these services and already flags it as suspect traffic, why the heck would you PAY AGAIN if you got the NBR response for Ad Fraud, or why would you keep sending that exchange RTB traffic which has a high rate of being flagged as ad fraud?

It seems to be mindlessly running up expensive SaaS fees.

Most of these services have stipulations that you can't cache the response for an IP or URL or combination, and that you have to call it every single time you get an RTB request you want to verify.

I thought the no-bid reason was there to give the peer exchange an indicator as to whether or not to continue to stream traffic from that publisher or as an indicator of the quality of the traffic from that publisher.

As far as the DSP/SSP and which one sends the request, I think that if there is a definitive answer somebody should update Wikipedia and make some public source stating as such, because I have seen DSP and SSP used both ways by multiple exchanges worldwide.

- Chris Gu - NginAd.com PHP Open Source RTB Ad Server

[Neal Richter]

You are pointing out inconsistencies in spec wording.  All valid feedback.

Re the concern on flagged impressions; this is a deep subject that is better done in person or via voice.  There are a many of reasons why that might be happening. There is no contract (in the protocol sense, not legal) of OpenRTB that an exchange/ssp stop sending impressions to a bidder that it flags as unwanted.  That is generally handled by people driven conversations in email.  It's a good process to standardize.

-Neal

[Etai Raz]

+1 for what Neal just said.

There's only so much you can add to a standard protocol before it becomes too complicated (and then abandoned). In fact, this is the reason most attempts to standardize an industry wide protocol fails.

There are many reasons for which a DSP responds with a no-bid. It could be related to suspected fraud, but even suspected fraud has many sub-reasons to it. It could be traffic that's coming from a suspicious IP, or an app that has a lot of fraudulent traffic in it, or some specific behavior related to the advertising id, and much more. Even if the protocol did have a way for the DSP to respond with "suspected fraud", it would still be a long way from enabling the SSP from not sending similar traffic to the DSP, because it wouldn't what the basis of the fraud detection was.

We have many similar scenarios in which a DSP does not want to receive specific traffic from an SSP. This could be based on Geo, or specific apps, or types of devices, etc. I agree with Neal that these kind of business requests should be discussed on between the parties, and that the protocol is not the place to cover issues like "do not send me more traffic".

I would say the exception is what I posted to the group yesterday - http code for malformed requests.

My $0.02

[Christopher Gu]

Hi Etai,

"Even if the protocol did have a way for the DSP to respond with "suspected fraud", it would still be a long way from enabling the SSP from not sending similar traffic to the DSP"

You mean like this?

http://www.iab.net/media/file/OpenRTBAPISpecificationVersion2_2.pdf

4 Suspected Non-Human Traffic 

Now say 1 single exchange gets some business savvy, and unlike Rubicon Project they say, hey, we will use PMP for custom exchanges internally and let 100+ different ad networks use our exchange as a white label platform, optionally with a vanity domain? Say like Zedo, ePOM, or AppNexus, LiveRail or even Smart Ad Server?

Then they charge people to use the platform on a monthly basis with AdFraud built in?

Lets use AppNexus as an example. Say AppNexus has 100+ customers that all buy from an exchange-wide auction and re-sell as a SSP. Say they take all inventory that fails to fill internally amongst AppNexus users and resell that through a passback ad tag which triggers their own SSP OpenRTB request to their DSPs.

Now you have 1000s of Publisher Website channels: eg: MediaShakers News Vertical ROW, that are resold as OpenRTB from AppNexus over 100s of different RTB exchanges.

ALL UNFILLED ON APPNEXUS ITSELF.

Perhaps the AppNexus white label sub-exchanges think that though it failed AppNexus/Double Verify, they can still monetize it after getting it for $0.0001 CPM at a exponentially higher rate.

They, and lets be honest here, Pubmatic as well, send it to thousands of DSPs world-wide via RTB, and OpenRTB, hoping to exponentially sell the 0.0001 CPM traffic that failed the AppNexus fill.

And 99% of the time they do.

BUT, our exchange has Forensiq, so like AppNexus's ad fraud detection, it catches the traffic and rejects 80%+ of it. That costs A LOT OF MONEY to use the Forensiq RTB API.

Ad Fraud is usually on a PUBLISHER BASIS. If you remember a couple years ago there were some auto-refresh sites like ChinaFlix that were auto-refreshing ad tags and using hidden frames, ect... 

On Amazon Alexa, these sites had next to no reported visitor traffic, but on RTB SSPs you could see they had millions of impressions per day.

Ad Fraud is almost always on a publisher RTB channel(a row in the SSP's excel spreadsheet) basis, with RTB publisher channels that rank very low on Alexa, and have very high impression counts on RTB excel spreadsheets.

You CAN stop these in an automated way, by explicitly returning the 4 Suspected Non-Human Traffic , assuming that the SSP did not take the 204 as default.

Once the SSP considers the 200 + the NBR code as the default, they then have to do something about that NBR code, and in my opinion, that would include a human review of the publisher tags, which right now NEVER HAPPENS.

How prolific is this problem with Exchanges reselling white label instances under vanity domains? Here is AppNexus alone, and only a sub-set.

Consider that soon NginAd will allow tens of thousands of Ad Networks to do the very same thing for free in countries like India and China where nobody wants to pay AppNexus or ePOM.

That's a lot of duplication of Publisher channels that need de-duplicating not only on ad fraud, but a number of data points.

http://console.microsoftadvertisingexchange.com/ 

http://console.fidelity-media.com/

http://console.neustar.biz/

http://console.mediashakers.com/

http://beta.cpmonly.com/

http://ui.beanstock.co/

http://p.cpxinteractive.com/

http://console.matomymedia.com/

http://console.brealtime.com/

http://portal.mediafem.com/

http://console.mainadv.com/

http://preview.test.console.appnexus.com/

http://appnexus.adnanny.com/

http://console.mangomediaads.com/

http://beta.morningfalls.com/

http://console.datapointmedia.com/

http://console.adsiduous.com/

http://my.reduxmediagroup.com/

http://console.nowspots.com/

http://console.batangamedia.com/

http://console.darchermedia.com/

http://www.gayadnetwork.net/

http://console.webads.nl/

http://console.admetricsmedia.com/

http://portal.pickmeup-ltd.com/

http://my.aim4media.com/

http://console.clickdealer.com/

http://console.xaxis.com/

http://console.meteora.co/

http://wardog.clickhype.com/

http://console.webads.it/

http://ui.pubventuresmedia.com/

http://console.adnomia.com/

http://console.sonital.com/

http://console.adextent.com/

http://a2x.tritondigital.com/

http://dashboard.adtaxinetworks.com/

http://console.ad2one.com/

http://your.orbyd.com/

http://adexchange.brucelead.com/

http://console.networkhm.com/

http://console.mozoo.com/

http://report.pubsqrd.com/

http://console.d2ex.com/

http://console.captifymedia.com/

http://beta.exactdrive.com/

http://portal.collective.com/

http://console.3xchange.com/

http://hub.travelspike.com/

http://beta.redvlog.com/

http://hub.revinet.com/

http://rtb.adgorithms.com/

http://login.medianexus.com/

http://console.deliads.com/

http://beta.olivebrandresponse.com/

http://ssp.interactivemedia.net/

http://console.ad-maven.com/

http://console.ib5knetwork.com/

http://console.audienceamplify.com/

http://beta.accordantmedia.com/

http://portal.aquamediadirect.com/

http://console.advance.uk.com/

http://amconsole.admarket.orange.com/

http://console.serranetga.com/

http://console.progmechs.com/

http://console.jemmgroup.com/

http://console.web3.us.com/

http://console.e-viral.com/

http://trader.themig.com/

http://trader.themig.com/

http://stats.unite.me/

http://beta.sponsoredads.com/

http://console.adsolve.com/

http://console.matchflowmedia.com/

http://console.tyroo.com/

http://console.southernadx.com/

http://console.ideonmedia.com/

http://desk.gamned.com/

http://console.collectiveroll.com/

http://portal.yieldivision.com/

http://stats.bttbgroup.com/

http://console.dtravelconnection.com/

http://login.nextclickads.com/

http://p.acsencion.com/

http://desk.makazi.com/

http://adexchange.hi-media.com/

http://console.adnubo.com/

http://display.nextperience.net/

http://login.q1media.com/

http://console.stailamedia.com/

http://dashboard.yoptima.com/

http://dashboard.yoptima.com/

http://console.888media.net/

http://console.magnetic.is/

http://portal.dedicatedmedia.com/

http://portal.bannerconnect.net/

http://console.vidascomedia.com/

http://console.digitalthrottle.com/

http://beta.impressiondesk.com/

http://portal.vntsm.com/

...

[Etai Raz]

"4 Suspected Non-Human Traffic " 

Yes, this is what I'm talking about.

Now let's say that the SSP would like to take action.

How do you propose an SSP acts upon receiving this nbr? I presume you want it to stop sending similar traffic? Based on what -  the advertising id? The IP? The entire app? tor how long would you like it to stop sending traffic? a minute? an hour? a day? forever?

I'm saying 2 things:

1) Developing the protocol to a point where the partners will be fighting fraud programatically is a difficult task. There's no one-size-fit-all solution, and it will be hard to come up with a process that everyone can agree to.

2) Developing your own DSP to ignore traffic that you don't want to see again is quite feasible, and hence makes more sense to me in the scenario you're describing. It's very similar to how retargeting systems are implemented.

But this is just one man's opinion. We can probably just agree to disagree.

...

[Christopher Gu]

Etai,

It would be in conjunction with emailing the SSP based on a NBR response threshold.

So you can tell an SSP that if you return 50%+ NBR for a single RTB channel or Site ID, then automatically discontinue bid requests for that Site ID or even the entire publisher if they have multiple verticals

That's why I gave the example from ChinaFlix.com and the auto-refresh from a couple years ago. It was an example of it happening on a single publisher or Site ID. It's also an example that many in the RTB world remember well.

The reason this is not possible even by email today is because many SSPs are taking the recommendation of a 204 response literally from the spec. 
When the SSP has no feedback on the QoS of their publisher site ids, they have no data to take action.

I found that the NBR response as opposed to a 204 does not add significant load on the client/server connection unless most of your responses are 204 in which case you have a problem anyway.

Having some type of ad fraud stop-loss automation as part of the OpenRTB spec would be great, but right now I am just requesting that the NBR recommendation be changed as a start.

- Chris

...

[Neal Richter]

Chris,

  Let's take this offline.  

#0 we put the NBR code back into the protocol for general use.  A few of the companies on this list are working together on use cases with it.  You have assumed that the spec intends to dictate what the SSP should do with a code 4 response.  The what to do is very much up to the exchange and DSP to decide how to handle the data.

#1 there are many approaches to reducing costs of querying pre-bid services, such as sampling (when you get a blood test the doctor doesn't take ALL of your blood).

#2 you are proposing business solutions outside the boundaries of the current protocol. If we want to design a standardized API to allow DSPs to remotely change their 'feeds'  by shaping the traffic with targeting and black/white lists then you have some interesting ideas.  We don't have a standard for that (yet).

#3 this group exists to discuss the protocol, use cases, and how we evolve it.  It's a public forum.  For most of its existence the unofficial rule is that we don't get accusatory and start slinging company names around.  

#5 For the topics you bring up the better forum is the inventory quality working group which has evolved quickly in the last year.

I will forward my phone number to discuss and can make some introductions.

Thanks -Neal

[Neal Richter]

Ok please propose some wording and the drafters will look at it.  You are right to provide feedback about the ambiguity of recommended response mode of a DSP.

-Neal

--

[Christopher Gu]

Hi Neal,

Sounds good, as you probably know I am in the same greater Los Angeles area as Rubicon Project.

I want to say in my defense, that Ben Edelman, who is a well known Harvard professor, slung AppNexus around when giving a speech on Ad Fraud this past year which is publicly available on YouTube.

http://digitaladsecuritysummit.com/speech/

I was in the audience at this conference. While I am mentioning these notorious ad exchanges for a very good reason, I will refrain from doing so in the future.

- Chris

...

[Etai Raz]

Neal, we further demand to know what happened to #4 on your list ;)

[Christopher Gu]

Clearly, he started with integers and went into prime numbers. Not sure if it was intentional, but clearly that's what happened.

Normally, people start ordered lists with the natural numbers set, but I am guessing he wanted to put a CS spin on his list, then it slid into primes.

Lets take it offline!

- Chris

[Neal Richter]

#4 Reserved for future use

-Neal