PARAKEET via OpenRTB Protocol

[brodrigu]

OpenRTB is the common standard for interacting between parties at request time in an advertising transaction. Adoption of Parakeet would be much easier for both SSPs and DSPs if the Parakeet server used OpenRTB to communicate.

Microsoft has indicated they are working towards adding full support for OpenRTB in both the polyfill and native implementations of PARAKEET. However, agreement on location of key pieces values within the OpenRTB object is needed to move forward. Could Microsoft publish expected OpenRTB structure for comment and agreement?

Additionally, could any published structure clearly indicate where publisherAdUnit would be placed within the structure and include a flag indicating the given request is from a parakeet server in order to trigger parakeet specific logic.

[erik-anderson]

Can you give a little more context on what parts of the data flow you're hoping to use OpenRTB?

We've provided a summary of the OpenRTB-compatible request format that the PARAKEET service will support when passing a request to the ad server. The service we're providing for evaluation will be the same across the polyfill and the native implementation. Are you looking for more detail on aspects of that protocol?

Or are you looking to leverage OpenRTB on some of the client-side JavaScript calls? If so, can you provide a little more detail about how you're envisioning how that would look?

[brodrigu]

The summary is great, thanking for linking to that I had not yet seen it published publicly. I am looking for additional clarity on the OpenRTB format on the request between the PARAKEET server (or the polyfill when relevant) and the "Ad Server".

The questions I have are:

1. Where in the OpenRTB format would the equivalent of the value placed in publisherAdUnit within the PARAKEET format be found.
2. Will there be a flag somewhere in the OpenRTB format indicating the request is coming from a PARAKEET server? (I would expect given the controlled data that PARAKEET originating requests would be handled a bit differently).
3. What is the expected response format when a request is sent in OpenRTB format?
4. How do we indicate within the client-side configuration that our ad server prefers OpenRTB format?

[brodrigu]

Bumping this issue as it hasn't seen a response.

[jrmooring]

Hi Brad, we are iterating on this as we work with testing partners.

Currently,

1. We don't include publisherAdUnit in the OpenRTB request. publisherCode maps to site.publisher.id, and pecifying a slot in an adProperties object will be reflected in the tagid of an impression object.
2. There isn't currently an explicit flag, however this is a good suggestion, and we're open to recommendations as to where this should be specified.
3. The response format isn't currently enforced by the service or polyfill, but OpenRTB responses have to be handled at the client by opting out of the iframe rendering mechanism. This would have to change with the addition of client-side decision logic.
4. This is currently configured on a per-origin basis at the proxy layer. Given current feedback we are looking at moving to OpenRTB by default.

[brodrigu]

Thanks John, does this mean OpenRTB support is currently available in Parakeet? To utilize this we just need to reach out with the origin we want enabled?

[jrmooring]

Yep, that is correct

[bretg]

There isn't currently an explicit flag, however this is a good suggestion, and we're open to recommendations as to where this should be specified.

Prebid Server puts the AMP flag in site.ext.amp:1 -- perhaps site.ext.parakeet:1?

[KeldaAnders]

Thank you @bretg & @brodrigu for bringing this back to the queue, it's been added to tomorrow's agenda #3

[bretg]

Followup: Brad and I realized that the URL(/.well-known/ad-bundles) may be implicit signal indicating Parakeet as the source, but we'd like to have an explicit signal.

Can someone confirm that /.well-known/ad-bundles is the uri path the Parakeet server would hit on the back end, or whether that's going to be configurable?

[jrmooring]

We're removing the fixed path requirement.

Following up from today's meeting -- we can support site.ext.parakeet:1 as an explicit signal.

[brodrigu]

@jrmooring it looks like the OpenRTB request format supports imp.bidfloor but does not include an ability to provide the currency of the bid floor. Could we extend that to also provide imp.bidfloorcur?

[bretg]

FWIW - I second the need to support bidfloorcur. We regularly encounter discrepancy problems where someone forgets currency. It's no so bad when the difference is between EUR and USD, but it's quite bad when it's JPY-vs-EUR.