PROPOSAL: Addition of click tracking URL to Bid object

[Seth Yates]

Current State:

Some exchanges serve the creative using "crid" rather than "nurl" or "adm".  The objects in a Bid Response do not provide any method of providing a click tracker in these cases.

Proposed Change:

Add the following field to the 4.3.3 Bid object defined in OpenRTB v2.1:

curl optional string The bidder's click tracking URL of the ad.

Rationale:

In cases where ad markup is not returned by the Bidder (either via "adm" or "nurl") and the Exchange serves the creative (that has been uploaded before bidding), we need a way of dynamically declaring the click tracking URL to use in the bid response.  The click tracker cannot be uploaded at the same time as the creative as we need to be able to track impression-level detail in the click tracker.  Hence, we need the capability to return the click tracker in the Bid object. "adomain" cannot be used for this purpose as this field declares the landing pages, not the click trackers.

We see this case very often in non-US exchanges.  We are live with exchanges using extensions like this.

This proposed change is backward compatible.

Cheers,

Seth

--

Seth Yates

Founder | CTO, Brandscreen

SG +65 9723 1576 | AU +61 408 518 330 | sya...@brandscreen.com

Singapore: 3 Church Street, #24-05 Samsung Hub, Singapore 049483

Australia: Level 2, 30 Alfred Street, Milsons Point NSW 2061 Australia

China: 9/F, Eco City 1788 Nanjing West Road, Jing'an District, Shanghai, 200040, China

NOTICE

This e-mail and any attachments are confidential and may contain copyright material of Brandscreen or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Brandscreen does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Brandscreen.

[Jim Butler]

So to ensure I understand the current state use case.  With this type of exchange, you have to upload both the markup and creative a priori and then your bids just reference them.  Out of curiosity, I assume this is for creative approval by the exchange prior to serving?

 

Part of the OpenRTB standard is that the exchange must honor the substitution macros (refer to Table 4.6 in the v2.1 document).  These are the same macros that were in the 1.0 Mobile version and haven’t changed, so they’ve been around for over 2 years.  Per the spec, these macros can appear anywhere in the “nurl” OR the markup itself and in the case of the latter, must be honored however the markup is delivered.  The very point of these macros is to communicate dynamic impression information back to the bidder, most famously the clearing price.

 

But perhaps most relevant to this use case would be to include the bid ID in the click tracking URL within the markup via the macro ${AUCTION_BID_ID}.  This would allow the bidder to tie each click back to the unique originating bid and thus all the information it ever knew about it.  Although the spec anticipates only two markup delivery methods (i.e., “adm” or to the “nurl” response), it would seem to me that an exchange that requires a priori markup delivery should still honor the substitution macros if it calls itself OpenRTB compliant.

 

I would propose that the language of Section 4.6 “Substitution Macros” be augmented to include any markup delivery method (i.e., the two currently defined in the spec AND others like this a priori case) to make this more explicit.

 

: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/groups/opt_out.
 
 

[Seth Yates]

Hi Jim,

The case is actually quite a bit more stringent than that.  Yes, the creative is uploaded for review a priori.  However, these particular exchanges do not take the markup - they take the actual asset files and serve them from their CDN directly.  So there is nothing to do replacement macros into.  They provide the auction price and impression-level detail via server side win notice (using nurl with macros).  We're live with this extension in several exchanges, so it is becoming prevalent in several of the particular countries we operate in.

Regards,

Seth

[Seth Yates]

Reflecting on this further based on Jim's questions, I believe this represents a new "Ad Serving Option" not originally documented in the specification.  Currently envisaged are:

1) adm - ad markup in the response; or

2) nurl - win notice (presumably) on the client side to return actual markup

I believe this case extends this to:

1) adm - ad markup in the response; or

2) nurl - win notice (presumably) on the client side to return actual markup

3) crid + nurl - id of creative hosted and delivered by the exchange plus a server side win notice url

As such, I'd like to extend the change to include the following (all references are to OpenRTB v2.1 FINAL):

Replace the intro text of section 4.5 "Ad Serving Options" to read:

"There are three methods by which the winning bidder can return ads to the exchange."

Renumber section 4.5.3 "Comparison of Ad Serving Approached" to 4.5.4 and add the following bullet point:

• Ad Served by Exchange

• Reduced Bandwidth Costs: Since the exchange delivers the actual creative or ad markup, large amounts of bandwidth can be saved in the bidding protocol.  This also saves bandwidth for the bidder, on actual ad delivery.

• Greater Creative Control: Since creatives are uploaded and hosted by exchanges, there is more control over quality and safety for the exchange.

Insert a new section 4.5.3 "Ad Served by Exchange", to read:

"In this method, creatives are uploaded by the bidder to the exchange prior to auctions.  Creatives are hosted by the exchange and are referenced in the bid response using the 'crid' field in the 'bid' object.  If the creatives are XHTML or VAST XML, the exchange must expand all supported macros.  Bidders should specify a server-side win notice using the 'nurl' field that exchanges must call with all supported macros expanded on impression and a client-side click tracker using the 'curl' field that exchanges must call with all supported macros expanded on click."

In section 4.6 "Substitution Macros", add the following macros:

${AUCTION_CRID} ID of the creative; from crid attribute of 'bid'

${AUCTION_CURL} Click tracker specified in the curl attribute of 'bid'

One of the areas of contention this could raise revolves around the use of 'nurl' on the server side as a notification URL rather than ad markup url, although I note that the spec defines nurl as "Win notice URL. Note that ad markup is also typically, but not necessarily, returned via this URL."  We could tighten up the language around nurl and creative delivery to outline two options chosen by the exchange: (1) nurl is client side and if supplied, called to return ad markup; (2) nurl is server side and should return an empty (preferrably 204 No Content) response.

Apart from the macros, this should still be backwards compatible.

Thoughts?

Regards,

Seth

--

Seth Yates

Founder and CTO, Brandscreen

AU +61 408 518 330

SG +65 9723 1576

sya...@brandscreen.com