rainzq / openrtb Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/openrtb
License: BSD 3-Clause "New" or "Revised" License
Automatically exported from code.google.com/p/openrtb
License: BSD 3-Clause "New" or "Revised" License
-------------------------------------------------------------------------------- Implementation Purpose -------------------------------------------------------------------------------- This project is focused on supplying a reference implementation, both for supply-side and demand-side platforms, of the offline synchronization services specified in the OpenRTB Specification. The goal and design of this work is to minimize the effort required by any DSP or SSP wishing to leverage the capabilities described in the spec. To aid in this effort, the work has been licensed under the New BSD License. Please refer to the LICENSE file in the root of this project for more information, or to the following website for more information: http://www.opensource.org/licenses/bsd-license.php -------------------------------------------------------------------------------- Project Structure -------------------------------------------------------------------------------- You should be able to build the project by running 'mvn clean install' from the top-level directory. The project is structured in the following manner: + common This directory is a maven project that produces a single jar file. This jar file contains all code that is shared between the demand-side and supply-side implementations (i.e. authentication/validation work, object models, etc.) + demand-side This directory contains a series of maven projects responsible for the DSP behavior of this specification. The sub-project artifact responsibilities include: * dsp-web This project packages up a web archive (war) file, capable of being deployed in any standard JEE web container based upon the reference 'dsp-client' artifact provided with this implementation. The contents of this package are purposefully minimized to the deployment artifacts necessary to deploy the war file. * dsp-core This project produces a jar file containing the necessary logic for sending requests and receiving responses, including all message handling that is pertinent to the DSP. This jar file represents standard logic that would be implemented by any DSP wishing to leverage this implementation. All DSP specific logic (i.e. persisting the response data, retrieving advertiser information, etc.) is delegated to the 'dsp-client' via the 'dsp-intf'. * dsp-intf This package is the contract and set of interfaces between the message handling code located in the 'dsp-core' and a DSP's specific internal representation of that data. * dsp-client This package is an example implementation of the 'dsp-intf' to satisfy the following: 1) Integration testing between the 'dsp-web' and 'ssp-web' projects. 2) Provide a framework for other DSPs to leverage this specification more quickly by allowing the DSP to focus on the integration aspects of the specification with their own specific platform. As a result of requirement (1) above, this package must be capable of working in concert with the 'ssp-client' described below. + supply-side Similar to the 'demand-side' module, this directory contains a series of maven projects responsible for the SSP behavior described in the specification. The sub-module artifact responsibilities include: * ssp-web This project packages up a web archive (war) file capable of being deployed in any standard JEE web container. It is based upon the reference 'ssp-client' artifact provided with this implementation. The contents of this package are purposefully minimized to the deployment configurations necessary to deploy the war file. * ssp-core This project produces a jar file containing the necessary logic for sending and receiving both requests and responses, including all message handling that is pertinent to the SSP. This jar file represents standard logic that would be implemented by any SSP wishing to leverage this implementation.. All SSP specific logic (i.e. persisting the advertiser data, retrieving publisher information, etc.) is delegated to the 'ssp-client' via the 'ssp-intf'. * ssp-intf This package is the contract and set of interfaces between the message handling code located in the 'ssp-core' and an SSP's specific internal representation of that data. * ssp-client This package is an example implementation of the 'ssp-intf' to satisfy the following: 1) Integration testing between the 'ssp-web' and 'dsp-web' projects. 2) Provide a framework for other SSPs to leverage this specification more quickly by allowing the SSP to focus on the integration aspects of the specification with their own specific platform. As a result of requirement (1) above, this package must be capable of working in concert with the 'dsp-client' described above.
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 [email protected]
on 4 Jul 2011 at 9:44
Referring to the reference data for Content Categories (Section 6.1), the
tier-1 IAB values have been changed from the OpenRTB Mobile specification
unnecessarily. The 2.0 draft adds tier-2 codes which is great. However, in
the OpenRTB Mobile specification, IAB-24 was “Uncategorized” which is noted
in the IAB reference in sequence as the 24th tier-1 category and it has IAB-25
and IAB-26 as “Non-Standard Content” and “Illegal Content”,
respectively. The 2.0 draft not only eliminates “Uncategorized”, but
renumbers the latter two as IAB-24 and IAB-25.
The tier-2 codes under IAB-1 through IAB-23 are fine, but the aforementioned
OpenRTB Mobile definitions of IAB-24, IAB-25, and IAB-26 should be restored to
avoid a needless point of backward incompatibility.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:30
Background/Problem Description:
Publishers might not pass along lat/lng, and DSP wants to target at
hyperlocal(true lat/lng) instead of reversed lookup by zip, or city.
Proposed Solution:
optional field "type" that specify what type of location geo object truly comes
from
Original issue reported on code.google.com by [email protected]
on 2 Aug 2011 at 2:39
Currently there is no easy way to determine what the audience's local time is.
A GMT Offset or Local Time field could be a great enhancement to the OpenRTB
spec. GMT offset would be preferred, since it could be an integer field that
give the difference in minutes between GMT and the audience's local time.
Minutes is preferable to hours, since some time zones differ from GMT by not
whole numbers of hours.
Original issue reported on code.google.com by [email protected]
on 20 Apr 2012 at 1:51
The OpenRTB Mobile specification included an optional “restrictions” object
that carried two optional blocklists (i.e., string arrays): “bcat” for
blocked content categories for which values would be from Section 6.1 of the
2.0 draft, and “badv” for blocked advertiser domains. I understanding that
the OpenRTB preferred means of communicating such restrictions is a non-RT API
and this it is in our near term roadmap to support this in our exchange.
However, not all exchanges and not all bidders will prioritize building support
for those APIs. Our experience and that of several bidders who are buying from
us is that it is easier to get started with the restrictions in the bid request
albeit less efficient from a bandwidth perspective.
We have built into our exchange the ability to include/exclude these
restrictions on a bidder by bidder basis. This way, when we complete our
non-RT sync APIs, bidders will have the choice of how to receive restrictions.
Furthermore, we want to reserve the right to suppress restrictions from the bid
request only after we’re satisfied that a given bidder is properly using the
non-RT sync. We can’t necessarily force a bidder to act on restrictions
however they are sent, but we need to represent to our publishers that we as
their SSP are doing what we can.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:06
Hello,
I've posted openrtb 2.0RC1 in the downloads area. please download and give
feedback by July 11th, 2011
http://code.google.com/p/openrtb/downloads/detail?name=Open%20RTB%202.0RC1.pdf&c
an=2&q=
Original issue reported on code.google.com by [email protected]
on 30 Jun 2011 at 11:16
>> 3. Do you have plans to add user matching in the spec? If so, when
>> could we expect to see a draft of it?
>>
>> 4. Have you considered custom data? By that I mean if the buyer wants
>> to add cookie-like data to be added in the user matching step or in
>> the response of a bid, and then expect it to be available in the next
>> bid request originating from the same user.
Original issue reported on code.google.com by [email protected]
on 21 Mar 2011 at 4:21
In the 1.9c draft spec there is the IP address attribute in the device object.
But it is only specified as 15 chars long, which is fine for IPv4, but it
should be extended to utilize IPv6 as well, which is 39 characters. Perhaps it
make sense to have two different fields?
Patrik
Original issue reported on code.google.com by [email protected]
on 17 May 2011 at 10:34
[deleted issue]
Background/Problem Description:
On line no. 70 and 98 in Class Signable , we are Hex encoding shared secret
like:
Hex.encodeHex(sharedSecret)
I want to propose a change that would change this call to :
Hex.encodeHex(sharedSecret, true)
Please refer Java docs for this method :
http://commons.apache.org/codec/apidocs/org/apache/commons/codec/binary/Hex.html
#encodeHex(byte[])
The change is suggested to use all lower case letters (or may be upper case)
while encoding in hex to make encoding consistent.We are generating token using
the same hex encoded shared secret. As the algorithm used to generate token is
MD5, case sensitivity of source string matters.
This would be a breaking change for those who use opposite kind of letter case.
Please let me know your suggestions about this change.
Thanks,
Vaibhav Kamble
Original issue reported on code.google.com by [email protected]
on 17 May 2011 at 12:20
Don't really know how to report this so i'm doing it here as well as by email...
I was going through the new OpenRTB 2.1 RC1 with PMP API an i found something
that seems problematic.
On page 30, table 3.3.13 (PMP Object) one field is called "private". This won't
be compatible with most object oriented development languages as "private" is
often a reserved word. For instance, java doesn't accept this as an object
attribute name.
Maybe should it be changed to "priv" or "isprivate".
Original issue reported on code.google.com by [email protected]
on 4 Apr 2013 at 1:09
On page 19 of OpenRTB 2 RELEASE, the wording, "If blank or 0, extension is not
allowed," suggests that the JSON could be formatted something like
{"maxextended":}, which is invalid. Instead, it should probably read, "If null
or 0..."
Jeff
Original issue reported on code.google.com by [email protected]
on 20 Apr 2012 at 1:45
I downloaded to run a sample with ssp web in openrtb sources. I am trying to
config but it is not working. Someone help me give some sample project to begin
it or guide how to start web project with tomcat or jetty.
p/s: This here is not clearly .
http://code.google.com/p/openrtb/wiki/SspGettingStarted
Original issue reported on code.google.com by [email protected]
on 6 May 2014 at 3:58
What steps will reproduce the problem?
1. Do something
2. See result
3. Still broken
What is the expected output? What do you see instead?
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 15 Feb 2011 at 9:34
Background/Problem Description:
Proposed Solution:
Implementation Notes:
Original issue reported on code.google.com by [email protected]
on 3 May 2014 at 8:08
I don’t have a serious object to this, but how is the “privacypolicy” in
“site” and “app” objects actionable? I would venture a guess that most
sites have privacy policies of one kind or another and that they vary broadly.
What will a bidder do with this boolean? If "not much", it should be removed.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:15
In the OpenRTB Mobile specification, the site and app objects had attribute
“keywords”. In this spec, that attribute has been removed and added to the
“content” object of which there is 1 per site or app object. It was also
renamed to “keyword” unless that’s a typo (a similar attribute in the
“user” object is correctly still called “keywords”). This creates an
unnecessary point of backward incompatibility. Please restore the
“keywords” attribute to the “site” and “app” objects. If someone
feels strongly about also having it in “content”, I would not object
although it seems redundant.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:18
The word "contains" should be removed in the following section of the Open RTB
2.0RC1.pdf document.
Before you get started
Not all objects are required, and each object may contain contains a number of
optional parameters.
Original issue reported on code.google.com by [email protected]
on 6 Jul 2011 at 3:46
In the OpenRTB Mobile specification, the site and app objects define 3
publisher attributes: “pid” (pub ID on the exchange), “pub” (pub name),
and “pdomain” (the pub’s domain). This spec pushed these into a
“publisher” object and since a “site” or “app” object has only one
“publisher” object, this create an unnecessary point of backward
incompatibility. Please restore these attributes as “pid”, “pub”, and
“pdomain” to the “site” and “app” objects.
This leaves only the “cat” attribute in the “publisher” object, which
means we should decide what to do about “cat” and drop “publisher”. My
recommendation on “cat” is to drop it. I don’t really understand how an
ad serve/bid decision would use this since the publisher is analogous to a
parent company of sites; how are content categories about them meaningful to
such a decision versus the site/app categories? If there is a meaningful way
to use it, then my alternate recommendation is to rename it “pubcat” and
move it to “site” and “app” with the other attributes.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:19
The FIPS 10-4 region codes were withdrawn by NIST as a FIPS (Federal Info
Processing Standard) in September 2008. Thus the geo.regionfips104 attribute
should be dropped. If it’s still in use by some exchanges, it should be sent
within bidextensions. Also, what is the standard behind the geo.metro
attribute? The sources “Metro Marketing Area” and “MetroCode” are
referenced, but I couldn’t find official references to these. If these are
vendor specific codes, I don’t think they should be explicitly called out in
the standard. If that is the case, they too could be passed within
“bidextensions”.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:27
Hi guys,
i'm referring to Open RTB 2.0RC1.pdf, from June 30, 2011, Pages 38+39 (5.1.4
Example 4 - Video)
imp->video->companionad is an array of banner objects, but it contains two
hashes with the same index.
I think the "banner: " should be removed from the example.
Regards,
Torben Brodt
Original issue reported on code.google.com by [email protected]
on 8 Jul 2011 at 2:31
Currently we have different floor prices for different banner types as those
defined in 6.2 Banner Ad Types.
As the floor price is at the impression level and there is no imp.banner.type,
but there is a block types array. Would the best way to set different floor
prices be to have 2 imp.
E.g. for HTML (we block 3)
imp[0].floor = 1.0
imp[0].banner.btype = [1, 4, 3]
E.g. for Rich Media (we block 2)
imp[1].floor = 2.0
imp[1].banner.btype = [1, 4, 2]
The issue currently is that we are debating the intent of the spec when it
comes to the wording around the impression object 'action for a specific
position'.
What we are trying to do is action a position but differ the floor price based
on the attributes of banner, thus 2 actions for the same position.
Thanks
Original issue reported on code.google.com by [email protected]
on 3 Sep 2013 at 8:35
As the impression.banner has a btype which might allow the inclusion of
multiple valid types in the response. The response object does not have a key
for the banner type of the delivered ad.
Currently we have addressed this with an extension.
Original issue reported on code.google.com by [email protected]
on 3 Sep 2013 at 8:38
The latitude in the geo object indicates -180 to 180. It should be -90 to 90.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:57
Field in Device object: "didsmd5" should be named "didmd5", since other field
names are: "didsha1, dpidsha1, dpidmd5"
Device object: "language" should be List of strings and not string, since
browser in many countrys sends more than 1 language. As we proposed in one of
previous examples (switzerland normaly has 3 official languages, and many users
use 2 as their defaults in browsers)
Table 6.15 location type: - we propose to add new value 4: IP adress
anonymized. Reason: In europe many countries have decided that IP adress is
personal data. Therefore exchange must use and send data based on partial IP
adress (normally in IPv4 last 2 bytes are replaced with zero eg.:
123.123.123.123 to 123.123.0.0. Same policy is also applied in one of the
biggest adexchanges.
Original issue reported on code.google.com by [email protected]
on 8 Nov 2011 at 11:42
The bid array (Section 4.3.2) is specified as required as is its parent. This
makes sense, since a no bid can be expressed as a completely empty bid
response. Our experience in integrating bidders to our OpenRTB Mobile
compliant exchange, however, is that some send empty responses, some send an
empty seatbid array or no seatbid array, some send seatbid objects without bid
objects. We found that it is acceptable simply to interpret the absence of any
of these essentials as a valid no-bid. There’s really nothing else for the
exchange to do; if it doesn’t have the essentials for a bid, then it’s a no
bid.
Based on this, the bid and seatbid arrays are not technically required since
the bidder is not required to make a bid. I would update the spec to reflect
this, but I would also recommend adding a “Best Practice” statement
indicating that the preferred means of expressing a no-bid is the bandwidth
friendly empty response.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:29
There have been recent developments in how device IDs are produced and consumed
with respect to how they are hashed. In the OpenRTB Mobile specification, we
considered SHA1 and MD5 had a strong consensus for SHA1. Over recent months,
however, there seems to be broad interest in both. Google for example
announced that they are going with MD5, but neither seems to be fading.
Therefore, I suggest we support passing both for each of the two flavors of
device IDs currently supported (i.e., true device equipment ID such as IMEI;
platform ID such as UDID for iOS or Android ID). My proposed names are:
“didmd5” (device ID using MD5), “didsha1” (device ID using SHA1),
“dpidmd5” (device platform ID using MD5), and “dpidsha1” (device
platform ID using SHA1).
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:25
Background/Problem Description:
There are issues with different JSON implementations
ordering elements differently
Proposed Solution:
Drop md5 signature; authentication should be done at HTTP level
Original issue reported on code.google.com by [email protected]
on 19 May 2011 at 10:05
What steps will reproduce the problem?
1.mvn install on the root folder shows up this warning.
2.
3.
What is the expected output? What do you see instead?
[INFO] Surefire report directory: C:\openrtb\common\target\surefire-reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.openrtb.common.json.AdvertiserBlocklistRequestTranslatorTest
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
What version of the product are you using? On what operating system?
Windows Vista
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 14 Jul 2011 at 7:37
The “geo” object should be removed and its attributes moved directly into
the “device” and “user” objects. I know it may seem better organized
this way, but it is just as easy to read and write these attributes to and from
the “device” and “user” objects directly. Any perceived organizational
improvement is hardly a reason to create an unnecessary point of backward
incompatibility with the OpenRTB Mobile specification.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:27
Background/Problem Description:
Certain browsers have 3rd party cookie support disabled by default. Namely
Safari 5.1. This can cause major issues for DSPs and affects things such as
frequency capping (as there is no way to fully single out the user). Typically,
we have witnessed that for each auction request generated by these browsers
that a brand new SSP userid is generated each time.
Proposed Solution:
Browser facing SSPs should be evaluating whether or not 3rd party cookies are
enabled and should be passed this through on the auction request. There are
many ways of determining whether 3rd party cookie support is supported - namely
by watching for cookie persistence or by a two-pass redirect mechanism when no
domain cookies are detected (on SSP ends).
Original issue reported on code.google.com by [email protected]
on 8 Feb 2012 at 3:44
In the OpenRTB Mobile specification, we followed an informal convention of
prepending “b” or “w” to attribute names to indicate that they are
block lists or white lists, respectively, (i.e., restrictions rather than just
informative data). For the most part, those names are carried over into this
spec. However, there are several new block or white list attributes in this
spec and I recommend that they follow the same convention.
The ones that jump out at me are as follows with the proposed names in
parentheses: banner.atype (wtype), banner.expandable (wexpandable or perhaps
just wexpand), banner.format (wformat), video.format (wformat),
video.playbackmethod (wplaybackmethod), and video.delivery (wdelivery).
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:08
We believe that bidresponse.brespextensions should be defined as object and not
as string, since this is data specified by exchange. Therefore both exchange
and dsp should be able to interpret/process/use it. Same applies to
bidresponse.bidset[x].bid.bidextensions.
bidresponse.customdata is ok as string, since this is used only by dsp and
exchange will not process/intrpret/use this data in any way. If DSP sends data
encoded as string, so can dsp also interpret this (his) string received back
from adexchange.
Original issue reported on code.google.com by [email protected]
on 24 Oct 2011 at 10:36
The “site” and “app” objects have content category attributes. Except
for their changed names (which I called out in a separate issue), this is
consistent with the OpenRTB Mobile specification. In this spec, there are
additional levels of content category arrays at the section, page, content,
publisher, and producer levels; that's 6 levels of content categories. I have
no objection to these additional levels, but are they really necessary? They
seem like overkill and also pretty unrealistic in terms of actually getting
them.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:17
Background/Problem Description:
Proposed Solution:
Implementation Notes:
Original issue reported on code.google.com by [email protected]
on 15 Feb 2011 at 9:32
What steps will reproduce the problem?
1. Clone code on Windows XP or Windows 7 (I've tested on both)
2. mvn package
What is the expected output? What do you see instead?
The error message is:
-------------------------------------------------------------------------------
Test set: org.openrtb.common.json.AbstractJsonTranslatorTest
-------------------------------------------------------------------------------
Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec <<<
FAILURE!
verifyPrettyPrinter(org.openrtb.common.json.AbstractJsonTranslatorTest) Time
elapsed: 0 sec <<< FAILURE!
org.junit.ComparisonFailure: pretty printer didn't return the expected results
expected:<{[
"object" : {
"value" : "subtype-value"
},
"long" : 1234,
"string" : "parent-value"]
}> but was:<{[
"object" : {
"value" : "subtype-value"
},
"long" : 1234,
"string" : "parent-value"
]
}>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.openrtb.common.json.AbstractJsonTranslatorTest.verifyPrettyPrinter(AbstractJsonTranslatorTest.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
What version of the product are you using? On what operating system?
I have the tip (version 110) checked out on Windows XP and Windows 7
Please provide any additional information below.
The reason I think this is a Windows issue is that it works fine on my CentOS
box (5.5). The other clue is that on my CentOS box the default encoding is UTF-8
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
...whereas on windows its Cp1252
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources,i.e. build is platform dependent!
The offending code:
public void verifyPrettyPrinter() throws IOException {
test.usePrettyPrinter();
assertEquals("pretty printer didn't return the expected results", PRETTY_VALUE, test.toJSON(PARENT));
I've attached the logs
Original issue reported on code.google.com by [email protected]
on 8 May 2011 at 1:20
Attachments:
Attribute Name References: Need to do a full review of text descriptions
especially where attribute names are referenced. Some of these refer to names
that subsequently have been changed.
Object Descriptions Unclear: Some of the object description paragraphs are
rather unclear. For example, it took me awhile to figure out if the video
object was implying that “I want a video ad and these parameters describe
what I want” versus “I am video content, these parameters describe me, and
I want a video ad to be stitched into me”. The Data object is another
example where a couple clarifying examples would help.
Segment Object Value Description: The description of segment.value should
probably be clarified. While this is data that may have originated by a third
party, it is still essentially data that the exchange is presenting to all
bidders on a given auction. Therefore when the description talks about a
negotiation, that would be between the third party and the exchange (i.e., and
not any one bidder). The exchange must then make clear to the bidders what
this data represents and how it will be represented. I suggest expressing the
latter point as a “Best Practice” point similar to the first such point
under Device object (i.e., that the exchange is highly encouraged to publish
lists of device makes, models, etc., since there are currently no standardized
reference lists).
Connection Type Description: The table description in section 6.11 was copied
from 6.10, but never edited for the 6.11 table.
Bid Response Description: The first paragraph of 4.3.1 describing the bid
response was copied from 3.3.1 the bid request, but never edited.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:58
We referred to the Wiki spec mentioned in the Carrier field and according to
the wiki article "A mobile network code (MNC) is used in combination with a
mobile country code (MCC) (also known as a "MCC / MNC tuple") to uniquely
identify a mobile phone operator/carrier"
Now the RTB spec 2.1 only mentions the use of MNC which is clearly insufficient
to determine the carrier.
So if you wish to determine the carrier using something other than the MCC, say
country from the GEO, the fact that some countries have multiple MCCs with
overlapping MNCs makes this impossible.
Example:
310 - 280 = ATT
311 - 280 = Verizon
So if the publisher only sends the MNC (280) and country USA we cannot
determine if the carrier is ATT or VERIZON.
Solution:
Pass the tuple MCC, MNC as the carrier code or join them as one string e.g.
310280.
In addition it would be nice to derive an open standards list from this wiki
article. It would make a great start.
Perhaps a nice web service for companies to fetch the latest revision.
Original issue reported on code.google.com by [email protected]
on 3 Sep 2013 at 8:24
Hi, looking at the new 2.0RC spec, I have a proposal to include the language
from the user's browser in the bid request. This could be different from the
user's location, and could be good to target ads in the user's own language,
and not the language of country the user happens to be in.
Patrik
Admeta
Original issue reported on code.google.com by [email protected]
on 20 Jul 2011 at 8:09
The version attribute should be removed from the bid request. As it is, by the
bidder has read that version attribute, the it will need to have already bound
or otherwise interpreted the top level bid request object. This makes its
usefulness problematic or at best limited, especially if considering binary
formats.
I suggest moving it to an HTTP header called “x-openrtb-version”. Together
with the “content-type” header, the bidder now has full information on
exactly what specification and format it needs to crack open from the POST body.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:05
are several attribute and object names that have been altered from the OpenRTB
Mobile specification for seemingly stylistic preferences. However, this
creates needless points of backward incompatibility for exchanges and bidders
that are presently operating. A couple instances of this have been referenced
in other issues where it seemed more appropriate to mention them there. Here
are the rest; please restore them:
- “site.sitecat” should be restored to “site.cat”.
- “app.appcat” should be restored to “app.cat”.
- “user.gen” should be restored to “user.gender”, and restore the
“O” value option.
- “bidset” object should be restored to “seatbid”.
- “bid.id” should be restored to “bid.impid”.
- “bid.campaignid” should be restored to “bid.cid”.
- “bid.creativeid” should be restored to “bid.crid”.
On the app and site category, I know there are other levels of category usage
proposed for site and app, but it is sufficiently clear that an unqualified
“cat” pertains to the scope of its object (e.g., site or app as opposed to
page, etc.). I noticed that object IDs have all been changed to a similar
unqualified style from the previous spec, which I do support (even though
it’s backward incompatible).
On the gender values, the allowed values were also changed in an unnecessary
way. Aside from “M” and “F”, the OpenRTB Mobile specification had
“O” for “other” which is a useful classification. The 2.0 spec dropped
it and added “U” for “unknown” which is redundant with respect to not
passing the attribute.
On the ID in the bid object, in all other objects that have an “id”
attribute, this ID pertains to the object itself. In this case, however, the
ID is referring to the ID of a different object; an “imp” object. It would
not only improve backward compatibility to restore it to “impid”, but it
would be a lot less confusing.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:12
I'd like to suggest the addition of a list of allowed currencies
in the offline synchonization. The list could be sorted so that the preferred
currency is at the top of the list.
Today the bidder can specify any currency in the bid, and it would help if the
exchange could specify which currencies it allows the bidder to use instead of
just rejecting the bid due to an unsupported currency.
Original issue reported on code.google.com by [email protected]
on 26 Apr 2011 at 5:17
The “imp” object has been reorganized from the OpenRTB Mobile specification
to require either a banner or a video object. There are a couple issues with
this. First, the either-or notion requires that the ad request limits itself
to one or the other a priori. We have some applications in the field that make
ad requests that are happy to receive either a banner or a video and do not
know until the ad is received. This would preclude that. The structure also
adds the complexity of an additional object to the incredible majority of
requests that are non-video and in the process takes us further away from
backward compatibility. Here are the points I strongly urge to address this:
- Restore “w”, “h”, “pos”, “battr”, and “atype” back into
the “imp” object and remove them from “banner” and “video”. Even
for VAST companion banners, I believe these would all have the same values. If
I’m wrong about that, then keep the ones that do vary in “banner” as well
as “imp”.
- Copy the remaining attributes from “banner” up to the “imp” object
except “id”, since that is only meaningful to VAST companion banners.
- The presence of a “video” object can be used to indicate that a video ad
is allowed.
- Change “atype” back to “btype” (i.e., a block list rather than a
white list as it is in the OpenRTB Mobile specification). If people also want
the flexibility of a white list, then keep them both but rename the white list
to be “wtype” to be consistent with the convention established in the
OpenRTB Mobile specification.
- If only a video ad is welcome, then the “video” object would be included
and “btype” would be used to block the banners.
- The “banner” object can still exist in the specification for reference by
the “video” object. But since it would only be used as video companion
ads, there may be the opportunity to further simplify it, but I’ll leave that
to a VAST champion. It would probably make sense to rename it to
“companion” at this point.
- The “h” and “w” attributes should be recommended rather than required
as their descriptions indicate. While we tend to include it all the time, it
is quite common in mobile to derive screen height and width from the UA and go
with the largest MMA ad unit that will fit.
Summary note: This may feel less object-oriented from a spec perspective, but
it makes requests for non-video ad units (i.e., the huge majority of global ad
requests) simpler and more backward compatible with the existing OpenRTB Mobile
specification.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:10
In the bid request object, the bidfloor value can be qualified by
bidfloorcurrency. First, to be consistent with the bid object which expresses
bid currency as “cur”, this long name could be shortened to bidfloorcur.
As an aside, I think the term floor in the context of RTB would be no less
clear as bidfloor. Thus, these could be called floor and floorcur.
But my real question with bidfloor is that unlike the bid price, bidfloor it
cannot be qualified by units; it seems to be CPM only. For consistency, we
should add bidfloorunits (or floorunits if we use the short names), which would
follow the values of Price Units (Section 6.5), which defaults to CPM.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:07
Referring to the reference data for Ad Position (Section 6.4) and No-Bid Reason
(Section 6.6), each has a value 0 that means “unknown”. However, a broad
concept throughout OpenRTB attributes, other than block or white lists, is that
an omitted optional attribute means “unknown”. For this reason, other
attributes do not have an explicit value to mean “unknown”. For
consistency, these should be removed as well.
The 0 = unknown value existed in the OpenRTB Mobile specification for No-Bid
reason, but since an exchange would likely also interpret an undefined value as
“unknown”, this should not cause a backward compatibility issue.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:31
When a DSP queries the SSP whether an advertiser is in any publisher's block
list, it would be convenient if a status code is returned if the advertiser is
blocked.
The main reason for this is:
* The publisher may want to manually verify the advertiser and thus respond
with a "pending verification" to indicate that the DSP should check again once
the verification has taken place (by polling as described in the documentation.)
A second reason may be to indicate that the advertiser is permanently blocked
by a publisher. A possible scenario when an advertiser is _not_ permanently
blocked might be if all premium advertising space is bought by some company and
competing brand advertisers may not be accepted on the site while this campaign
is running.
Original issue reported on code.google.com by [email protected]
on 21 Mar 2011 at 12:45
* standardize real-time bidding calls
* incorporate Mobile, Video, Display
* provide an extensible spec for wire-level messages
Original issue reported on code.google.com by [email protected]
on 18 May 2011 at 11:00
Attachments:
This issue is to serve as a reference point for the publisher-centric API
addition proposal.
Original issue reported on code.google.com by [email protected]
on 2 Mar 2011 at 6:09
There should not be a separate mechanism for retrieving VAST markup. The
auction conversation between exchange and bidder should not vary by ad unit.
I’m not sure if the intent is to call both the win notice and then the VAST
URL or just the VAST URL, but either way the VAST URL should be eliminated and
returned on the win notice URL; in the case of a VAST video, this is
essentially the served ad markup. The seller and/or SSP are quite capable of
detecting whether the response markup is XHTML or VAST XML and will be
expecting to make that determination based on the fact that it allowed VAST
video in the bid request.
To amplify the point, when serving the ad in the bid itself (Section 4.4.1),
the spec allows the VAST XML to be returned in the “adm” parameter just
like XHTML. The seller and/or SSP will have to make exactly the same
determination in that case. There is no reason for the win notice URL to be
any different.
Original issue reported on code.google.com by jim.butler%[email protected]
on 22 Jul 2011 at 9:28
This is for RTB version 2 for public comment.
Original issue reported on code.google.com by [email protected]
on 6 Feb 2012 at 9:36
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.