search

google / openrtb-doubleclick

Utilities for DoubleClick Ad Exchange, including OpenRTB mapping, DoubleClick cryptography, metadata and validation
Apache License 2.0
198 stars 82 forks source link

Latest 1.3.1 release doesn't have DoubleClickOpenRtbMapper and other related mappers #107

Closed amit-c1x closed 6 years ago

amit-c1x commented 7 years ago

Hey guys,

I am using this library to convert protobuf bid request to openrtb request. However, switching to the latest version, I do not see DoubleClickOpenRtbMapper and other related mappers.

Can someone clarify why that is the case, and how to use the library without it.

opinali commented 7 years ago

The mapping support was removed because it's not really necessary anymore, since AdX now supports this natively, i.e. when you register a bidder you can choose the OpenRTB protocol on-wire. You can even make a choice between OpenRTB/JSON, which is standard-compliant requiring no special code for AdX, and the OpenRTB/Protobuf option which is more convenient if you use the protobuf-generated model classes (and also more efficient, since protobuf's serialization is much faster than JSON's).

To be more precise we still have a mapper, but now it's server-side, the AdX callout server still uses its own proprietary RTB model internally, but if the bidder wants we automatically map that to OpenRTB. But it's a completely different implementation of the mapper so we couldn't justify the effort of duplicating the effort of maintaining and improving the mapping code here, considering also that this library is only good for Java while the native protocol works for bidders using any language.

Please check with your account manager how to consume OpenRTB natively, they can change this setting for your account but you can also control that via the AdX Buyer REST API.

amit-c1x commented 7 years ago

Thanks for the details. Few things:

  1. ADX OpenRTB is limited to 5K QPS for an account. That clearly is no good for us. So we have no choice but to use protobuf with ADX format.
  2. For user-case (1), it still makes sense to have the mapper here.
  3. Most importantly, the mapper does more than just converting protobuf network-bid to openrtb. It uses the DoubleClickMetadata to convert id's to their string counterpart using the Ad Exchange dictionaries. This functionality is something every bidder would wish was provided out-of-the-box.
  4. Again, DoubleClickCrypto is something required by the bidder irrespective of the wire format or request format.

Please weigh your thoughts on above, and suggest any alternate.

opinali commented 7 years ago

The 5K limit is only for the OpenRTB/JSON variant, not for OpenRTB/Protobuf. /we have this limit specifically for JSON because it's significantly more expensive ion serving resources and bandwidth (since AdX doesn't support compression for the RTB protocol). You need to specifically choose the proto variant, let me know if that works.

Good point on 3 though, the automatic translation of metadata was a singular advantage of client-side mapping. Doing that for the on-wire format (either AdX or OpenRTB) would be a hard call, we care about every byte in the messages, which have a hard limit of 16Kb. Maybe we could provide a simple utility that post-processes the BidRequest, using the DoubleClickMetadata?

On point 4, DoubleClickCrypto is still available, but you shouldn't need it now for the BidRequest because the encrypted fields are not used anymore since the entire message is now encrypted with SSL. You still need this utility class to decrypt the winning price from impressions so it's still available.

amit-c1x commented 7 years ago

Yup a utility like DoubleClickMetadata would be very useful and save a lot of integration errors. Can u provide that here? How long with that take?

opinali commented 6 years ago

Closing this bug, it seems mostly obsolete since the 5Kqps limit was removed for AdX's OpenRTB/JSON.