Comments on 2.0 spec

[GoogleCodeExporter]

Really great job done on the spec! It's looking really good, however I have a 
few comments.

There is no user matching process defined as proposed in Issue 6.

The idea of a version attribute in Bid Request is great, however what is the 
formatting of it? Is 2.0, 2.0RC1, 2.0.0, 2.0.1, etc all valid and will only be 
matched as a string or do we have a more strict form? I'd suggest only 
numerical two parts format: Major.Minor as described in the beginning of the 
spec.

Device Object, make clear it is used for browsers in computers as well. 
Currently the text states "...to the mobile device including..."

Admeta is currently in the process of adding Text Ads capabilities to our RTB 
offering. We will submit a proposal for addition to a future spec when we are 
finished with it.

There is no notion of Loss Notification. A detailed notification of every lost 
bid is probably overkill, but notifications when for example a bidder's 
advertiser is rejected or not yet approved by the publisher would be really 
good and will benefit both bidder and exchange. We are in the process of adding 
such notifications and will submit our solution as a proposal when it is 
finished.

There is no bid currency handling as proposed in Issue 7.

The inclusion of user data objects is really good. However the format of it is 
very verbose. The purpose for the bidder of such data is to be able to store 
cookie like data at the exchange, and will hence be sent every request and 
response, which leads to the fact that the user data is missing in Bid Response 
altogether.

We propose a more lightweight version of Custom User Data
"cud":
{
"string":"string",
...
}

for example:
"cud":
{
"age":"32",
"gender":"female"
}

Paragraph 4.3.1 has a Copy/Paste error from Bid Request

Paragraph 4.3.2 references a "seatbid" object, which is now renamed to bidset.

Patrik Oscarsson
Admeta

Original issue reported on code.google.com by patrik.o...@gmail.com on 4 Jul 2011 at 9:44

[GoogleCodeExporter]

Hi Patrik,

Thanks for the feedback -- I'll review the issues you referenced and get back 
to you.

Regards,
Pravin

Original comment by pravin%b...@gtempaccount.com on 5 Jul 2011 at 7:22

[GoogleCodeExporter]

Hi, I have two additional comments.

The bid price data type has changed, right? Now it is an integer, but before we 
interpreted is as a float. Why this change, and could it in that case be more 
explained how to handle the precision in different currencies. How do we 
multiply it? For example  0.10 SEK = $0.0159. What would that be in the bid? 10 
SEK = $1?
We prefer to keep it as a float.

Bid Request object now contains a bidfloor, although the explanation says "Bid 
Floor for this impression." Either the attribute should have been on the 
impression object or it should say: "bid floor for all impressions in this bid 
request". I hope it's the former and not the latter.

Patrik Oscarsson
Admeta

Original comment by patrik.o...@gmail.com on 6 Jul 2011 at 4:49

[GoogleCodeExporter]

Hi!

I believe it's the right way to move bidfloor to impression level in 
specification, since publishers that support "single call" - multitag request 
have requirement of different floor prices depending on above/below the fold 
and banner size.

Regarding the price and integer the same problem applies to bidfloor. Also if 
price is now defined as integer, it's probably correct to define bidfloor as 
integer too.

Regarding bidfloorcurrency it would be nice to shorten currency to same as in 
"bidresponse.cur", that would be bidfloorcur.

Also, since in 2.0RC1 "levels" have been removed it would be good to 
specificaly write in documentation that "custom" fields are now allowed only in 
"bidextensions and impextensions" field and not in "exchangename_customname" 
fields.

Regarding bidrequest.at it's probably good to describe "2" as modified second 
price auction, since price is normally second price+minimal increment. Another 
solution is to leave 2 as is and add "3" for auctiontype secondprice+minimal 
increment.

Damir Logar

Original comment by logar.da...@gmail.com on 6 Jul 2011 at 8:01

[GoogleCodeExporter]

Hi,

I'd like to say thank you for this great job! Though I have a few notes:

  * As it already mentioned earlier, the bidrequest.bidfloor is float, but bid.price is integer. I think a price object should be float, but at least the discrepancy has to be cleared.

  * The bidrequest.at is a string, though integer would be more reasonable, as the value can only be 0,1 (or 2 as per Damir)

  * The device.js is an integer. As it can be 0 (false) or 1 (true) it would be more reasonable to use it as a boolean

Akos Szalai

Original comment by akos.sza...@smobiad.com on 6 Jul 2011 at 10:04

[GoogleCodeExporter]

Hi again, 

I also see a need for Bid Extensions in the Bid Response. Especially to provide 
custom user data if the spec isn't updated to include that in a specific 
object. It could be used for other scenarios as well if the Exchange want more 
information in the bid response in order to decide if to consider the bid valid.

Another feature that would be good is to include the IAB category in the bid 
response, so that it would be possible to filter the ads against the 
publisher's black-/white list.

Patrik Oscarsson
Admeta

Original comment by patrik.o...@admeta.com on 7 Jul 2011 at 4:15

[GoogleCodeExporter]

The example bid response in section 5.2.1 should probably contain an "adm" 
field.

Original comment by s...@tingleff.com on 11 Jul 2011 at 10:50

[GoogleCodeExporter]

I know this is going to be difficult... but could we settle on a binary data 
format? This section is worrisome:
An exchange may offer additional representations to bidders who may prefer 
them.  These 
might include a compressed form of JSON, XML, Apache Avro, ProtoBuf, Thrift, 
and many 
others.

I propose that we either (1) put it to a vote between Avro, PB or Thrift; or 
(2) take this section out entirely.

Original comment by s...@tingleff.com on 11 Jul 2011 at 10:57

[GoogleCodeExporter]

I agree with you Sam, there should be a binary protocol.  My vote would be for 
ProtoBuf for several reasons:
1) Two other exchanges we integrate with already use that.
2) None of the other formats are used by any of the other exchanges, so this 
would help limit the amount of libraries we have to link in;
3) Protobuf has very good compaction characteristics compared to the others;

I've created a first draft protobuf (uncommented) file available here (and 
attached): http://openrtb.brandscreen.com/2.0rc1/OpenRtb.proto

Original comment by seth.ya...@gmail.com on 12 Jul 2011 at 1:06

Attachments:

• OpenRtb.proto

[GoogleCodeExporter]

I'd like to see the adomain field of the bid object as an array. We have a 
number of DSPs sending multiple advertisers per bid for things like rotating or 
split creatives.

Original comment by s...@tingleff.com on 18 Jul 2011 at 3:57

[GoogleCodeExporter]

Having used both Protobuf and Avro, I'd like to mention a few reasons why I 
prefer Avro:

1. Avro integrates much better with other Hadoop technologies than Protobuf
2. Avro's messages tend to be even more compact than Protobuf
3. Avro has a code generator implemented in Java with Maven/Ant plugins so that 
code generation can be easily integrated into builds.  No need to install an 
external compiler on your system like with Protobuf and/or check in generated 
code.
4. Avro does not require use of generated code
5. Avro can use separate reader and writer schemas so that the two sides of a 
protocol may evolve independently
6. Avro has built-in support for remote procedure calls, including asynchronous 
non-blocking calls, so that once you have defined a protocol you don't have to 
implement separate code to exchange messages using that protocol

Original comment by jbaldass...@gmail.com on 18 Jul 2011 at 4:00

[GoogleCodeExporter]

re: aodomain as an array

I have mixed feelings about having multiple landing pages - it makes 
verification harder, and encourages broader than necessary blocking. In many 
regards, I'd like to see the RTB space move towards tightening this so that we 
move in a more precise direction - since you can always return a "" landingpage 
if you're not sure.

This conversation is starting to get broad, can I suggest we start filing 
issues against 2.0 for specific change deltas or comments, so we make sure we 
don't miss any feedback?

Original comment by jays...@gmail.com on 18 Jul 2011 at 4:04