BidRequest Migration

The Google RTB ip is represented as a bytes binary in network byte order, while OpenRTB's ip and ipv6 are a string representation of the IP address.

For example, in Google protocol ip could be set to \x7f\x00\x00 , and the equivalent value of ip for OpenRTB would be "127.0.0.0" .

The mapped field is dependent on whether the IP is an IPv4 or IPv6 address.

This field isn't supported in Google's OpenRTB implementation.

The Google RTB hosted_match_data is represented as bytes , while OpenRTB's buyeruid is a string .

OpenRTB represents this value in websafe base64 encoding without padding.

The meaning of OpenRTB's field depends on the value of the BidRequest.user.eids.uid.ext.stype extension. When set to ppuid , it refers to a publisher provided ID.

Note that this data is subject to generalization in both protocols.

Mapping depends on whether the bid request originates from an app or website.

Mapping depends on whether the bid request originates from an app or website.

Mapping depends on whether the bid request originates from an app or website.

This field isn't supported in Google's OpenRTB implementation. Use Geo instead.

This field isn't supported in Google's OpenRTB implementation. Use Geo instead.

We recommend using BidRequest.device.geo.{lat/lon} for approximate device location.

This field isn't supported in Google's OpenRTB implementation. Use Geo instead.

We recommend using BidRequest.device.geo.{lat/lon} for approximate device location.

This field isn't populated in the Google RTB protocol, and won't be provided in Google's OpenRTB implementation.

Mapping depends on whether the bid request originates from an app or website.

This field isn't supported in Google's OpenRTB implementation.

This field isn't supported in Google's OpenRTB implementation.

Mapping depends on whether the bid request originates from an app or website.

Mapping depends on whether the bid request originates from an app or website.

This field isn't supported in Google's OpenRTB implementation.

This field isn't supported in Google's OpenRTB implementation.

Mapping depends on whether the bid request originates from an app or website.

Represented as a string rather than enum. Here is the mapping of possible values:

• GENERAL_AUDIENCES = DV-G
• PARENTAL_GUIDANCE = DV-PG
• TEEN = DV-T
• MATURE_AUDIENCES = DV-MA

Our OpenRTB implementation adds an unused FIXED_PRICE value (integer value of 3 for JSON format) that doesn't exist in the OpenRTB spec. This will always be set to FIRST_PRICE .

This field is deprecated and isn't supported in Google's OpenRTB implementation.

In OpenRTB, this single field contains the IDs found in both of Google RTB protocol's BidRequest.publisher_settings_list_id and BidRequest.adslot.publisher_settings_list_id fields.

This field isn't supported in Google's OpenRTB implementation.

This field isn't supported in Google's OpenRTB implementation.

This field isn't supported in Google's OpenRTB implementation.

The DeviceType enum differs between the protocols, but uses identical enum names to convey the same meaning in all but one case: Google RTB protocol's GAME_CONSOLE is mapped to OpenRTB's CONNECTED_DEVICE .

• HIGHEND_PHONE = 1 → HIGHEND_PHONE = 4
• TABLET = 2 → TABLET = 5
• PERSONAL_COMPUTER = 3 → PERSONAL_COMPUTER = 2
• CONNECTED_TV = 4 → CONNECTED_TV = 3
• GAME_CONSOLE = 5 → CONNECTED_DEVICE = 6
• SET_TOP_BOX = 6 → SET_TOP_BOX = 7

Devices that were set to " iphone " or " ipad " in Google RTB protocol will instead be set to " iOS " in OpenRTB. Otherwise, all other naming is identical.

OpenRTB uses a string for the carrier ID, while the Google RTB protocol uses an integer.

pxratio = screen_pixel_ratio_millis / 1,000

This field isn't supported in Google's OpenRTB implementation.

You may use OpenRTB's BidRequest.device.w and BidRequest.device.h fields to determine orientation.

The Google RTB field is an enum whereas the OpenRTB field is an integer. The integer specified in OpenRTB maps directly to Google RTB protocol's enum value.

• NOT_DETERMINED = 0
• RESTRICTED = 1
• DENIED = 2
• AUTHORIZED = 3

The Google RTB protocol and OpenRTB use different enum values, which have the following mapping:

• INSTREAM = 1 → IN_STREAM_PLACEMENT = 1
• INTERSTITIAL = 2 → FLOATING_PLACEMENT = 5
• IN_FEED = 3 → IN_FEED_PLACEMENT = 4
• IN_ARTICLE = 5 → IN_ARTICLE_PLACEMENT = 3

In cases where Google RTB protocol doesn't populate placement , OpenRTB will set it to IN_BANNER_PLACEMENT .

This is deprecated. We recommend that you use BidRequest.imp.video.plcmt instead.

OpenRTB only includes the domain, not the full URL.

The OpenRTB PlaybackMethod enum contains an additional (currently) unused CONTINUOUS enum name. Otherwise, the enum names and values are identical.

This field isn't supported in Google's OpenRTB implementation.

Google RTB protocol field indicates whether a device supports user clicks, which can be inferred based on BidRequest.device.devicetype.

The Google RTB protocol represents this in milliseconds, whereas OpenRTB uses seconds.

See native ad migration notes for more details on differences between JSON and Protobuf formats.

The Google RTB protocol uses a single field for both native and non-native video, and represents this in milliseconds, whereas OpenRTB differentiates between native and non-native video by using different field paths, and uses seconds.

See native ad migration notes for more details on differences between JSON and Protobuf formats.

The Google RTB protocol uses a single field for both native and non-native video, and represents this in milliseconds, whereas OpenRTB differentiates between native and non-native video, and uses seconds.

OpenRTB's field is less granular because it is represented as a boolean. Both of Google RTB protocol's ALLOW_SKIPPABLE and REQUIRE_SKIPPABLE enum names would result in the OpenRTB field being set to True .

We recommend contacting your TAM to enable skip correction.

The Google RTB protocol represents this in milliseconds, whereas the OpenRTB protocol uses seconds.

OpenRTB doesn't support display of both maximum duration for skippable and non-skippable ads simultaneously. Google uses bid flattening to represent both cases. For more details, see our documentation on maximum skippable video duration .

See native ad migration notes for more details on differences between JSON and Protobuf formats.

The Google RTB protocol uses a single field for both native and non-native video, whereas OpenRTB differentiates between native and non-native video.

Google RTB protocol enum names and values are equivalent in OpenRTB, but additional (currently unused) enum names exist in OpenRTB.

See native ad migration notes for more details on differences between JSON and Protobuf formats.

The Google RTB protocol represents these with an enum, whereas OpenRTB uses a string.

The Google RTB protocol represents this with an enum, whereas OpenRTB uses a boolean. However, only two values are in use for the Google RTB protocol, which map to OpenRTB as follows:

• END_CAP_NOT_ENABLED → False
• END_CAP_OPTIONAL → True

The Google RTB protocol uses separate repeated integer fields to represent width and height, where a given index in both describes a supported size.

We recommend using OpenRTB's companionad.format , which is a repeated field of type Format that can represent multiple sizes. Note that companionad.{h/w} can only represent one size.

The Google RTB protocol uses separate repeated integer fields to represent width and height, where a given index in both describes a supported size.

We recommend using OpenRTB's companionad.format , which is a repeated field of type Format that can represent multiple sizes. Note that companionad.{h/w} can only represent one size.

Google RTB protocol uses different enum names and values than OpenRTB.

• IMAGE_CREATIVE = 0 → STATIC = 1
• FLASH_CREATIVE = 1 → N/A (Flash is no longer supported.)
• HTML_CREATIVE = 2 → HTML = 2

These are also reflected in OpenRTB's mimes field for the companion ad.

Unlike Google RTB protocol, OpenRTB supports an additional type: COMPANION_IFRAME.

The Google RTB protocol represents this as an integer, whereas OpenRTB uses string.

The representation across the Google RTB protocol and OpenRTB are identical, however the OpenRTB field used differs based on the ad format.

When there are multiple eligible banner sizes, Google RTB protocol represents dimensions with width / height pairs at the same index, whereas OpenRTB uses the repeated format field.

Unlike the banner format, when there are multiple eligible video sizes, only the width of the first will be provided in BidRequest.imp.video.w .

The representation across the Google RTB protocol and OpenRTB are identical, however the OpenRTB field used differs based on the ad format.

When there are multiple eligible banner sizes, Google RTB protocol represents dimensions with width / height pairs at the same index, whereas OpenRTB uses the repeated format field.

Unlike the banner format, when there are multiple eligible video sizes, only the height of the first will be provided in BidRequest.imp.video.h .

See Excluded Attributes for more details.

The Google RTB protocol field is a repeated set of integer IDs defined here , whereas the OpenRTB field is a repeated set of GppSectionId enum.

The integer values in GppSectionId directly correspond to the IDs sent in the Google RTB protocol field.

See Ad Categories for more details.

Note that allowed restricted categories for deals and the open auction are identical.

Google RTB Protocol refers to languages differently than OpenRTB, which uses ISO 639-1.

See Ad Categories for more details.

In OpenRTB, this is the concatenation of Google protocol's BidRequest.publisher_settings_list_id and BidRequest.adslot.publisher_settings_list_id .

Unsupported.

The ExchangeBidding message and its contents have no equivalents in OpenRTB.

This field will only be populated for Open Bidding partners.

OpenRTB's pos field also maps to Google RTB protocol's StickySettings . Enum names relevant to slot_visibility are ABOVE_THE_FOLD and BELOW_THE_FOLD , which have different integer values in OpenRTB (1 and 3 respectively).

Note that visibility is not a factor for audio ads, which are represented separately from video ads in OpenRTB.

Unsupported for native ads.

The Google RTB protocol represents this as an integer percentage ranging from 0-100, whereas OpenRTB represents this as a double ranging from 0.0-1.0.

Note that this OpenRTB field has multiple mappings, and will only refer to viewability when OpenRTB's BidRequest.imp.metric.type is set to "viewability" and BidRequest.imp.metric.vendor is set to "EXCHANGE" .

The Google RTB protocol represents this as a float percentage, whereas OpenRTB represents this as a double.

Note that this OpenRTB field has multiple mappings, and will only refer to click through rate when OpenRTB's BidRequest.imp.metric.type is set to "click_through_rate" and BidRequest.imp.metric.vendor is set to "EXCHANGE" .

The Google RTB protocol represents this as a float percentage, whereas OpenRTB represents this as a double ranging from 0.0-1.0.

Note that this OpenRTB field has multiple mappings, and will only refer to video completion rate when OpenRTB's BidRequest.imp.metric.type is set to "completion_rate" and BidRequest.imp.metric.vendor is set to "EXCHANGE" .

The Google RTB protocol represents this as an enum, whereas OpenRTB represents this less-granularly as a bool.

Google renders all banners in a cross-domain iframe. In OpenRTB, topframe will always be set to False .

This field isn't supported in Google's OpenRTB implementation.

The Google RTB Protocol and OpenRTB use identical integer values, however the Protobuf OpenRTB format uses shortened enum names.

This field has been deprecated and is no longer populated. It won't be supported in Google's OpenRTB implementation.

This field isn't supported in Google's OpenRTB implementation.

The Google RTB Protocol field is an enum that supports the following values:

• GOOGLE = 1
• PUBLISHER = 2

The OpenRTB field is a string with a more granular set of values.

This field isn't supported in Google's OpenRTB implementation.

OpenRTB uses a similar enum with identical enum names, but the integer values are different.

• DIALECT_HTML = 1 → DIALECT_HTML = 0
• DIALECT_HTML_AMP = 2 → DIALECT_HTML_AMP = 1

OpenRTB uses a similar enum with identical enum names, but the integer values are different.

• AMP_AD_NOT_ALLOWED = 1 → AMP_AD_NOT_ALLOWED = 2
• AMP_AD_ALLOWED_AND_NOT_EARLY_RENDERED = 2 → AMP_AD_ALLOWED_AND_NOT_EARLY_RENDERED = 3
• AMP_AD_ALLOWED_AND_EARLY_RENDERED = 3 → AMP_AD_ALLOWED_AND_EARLY_RENDERED = 4
• AMP_AD_REQUIRED = 4 → AMP_AD_REQUIRED = 5

In OpenRTB, there isn't a dedicated field to list allowed ad types. However, they can be determined based on the presence of relevant ad format fields in the bid request such as:

• BidRequest.imp.banner
• BidRequest.imp.video
• BidRequest.imp.audio
• BidRequest.imp.native

The Google RTB protocol represents this with an integer data type, whereas OpenRTB uses double.

Note that the OpenRTB field can represent multiple metrics, and only represents session depth when Metric.type is set to "session_depth" .

OpenRTB uses a similar enum, but it includes additional frameworks such as VPAID.

• MRAID_1 = 3 → MRAID_1 = 3
• MRAID_2 = 5 → MRAID_2 = 5
• MRAID_3 = 6 → MRAID_3 = 6
• OMID_1 = 7 → OMID_1 = 7

This is specified separately for each of the included ad formats in OpenRTB.

Both the Google RTB protocol and OpenRTB fields are deprecated in favor of repeated fields. Use BidRequest.imp.ext.billable_event_rate_bid_adjustment.bid_adjustment instead.

Both the Google RTB protocol and OpenRTB fields are deprecated. Use BidRequest.imp.ext.ae instead.

In cases where Google RTB protocol sets excluded_attribute to 30, OpenRTB wouldn't populate BidRequest.imp.video.api or BidRequest.imp.native.{request/request_native}.assets.video.api with VPAID_1 or VPAID_2

In cases where Google RTB protocol sets excluded_attribute to 32, OpenRTB wouldn't populate any of the following fields with MRAID_1 :

• BidRequest.imp.banner.api
• BidRequest.imp.native.api
• BidRequest.imp.video.api

Flash is not a supported creative format.

In cases where Google RTB protocol sets excluded_attribute to 48, OpenRTB would populate BidRequest.imp.secure with True .

In practice, BidRequest.imp.secure will always be set to True because SSL support is required for all creatives.

In cases where Google RTB protocol sets excluded_attribute to 95, OpenRTB would populate BidRequest.imp.banner.battr with VIDEO_IN_BANNER_AUTO_PLAY and VIDEO_IN_BANNER_USER_INITIATED .

In cases where Google RTB protocol sets excluded_attribute to 114, OpenRTB wouldn't populate the following fields with OMID_1 :

• BidRequest.imp.banner.api
• BidRequest.imp.video.api
• BidRequest.imp.native.api

The Google RTB protocol and OpenRTB use different enums. They represent the same set of ad formats, but use different names and integer values.

• ALLOWED_AD_TYPE_BANNER = 0 → CREATIVE_MARKUP_BANNER = 1
• ALLOWED_AD_TYPE_NATIVE = 1 → CREATIVE_MARKUP_NATIVE = 4
• ALLOWED_AD_TYPE_VIDEO = 2 → CREATIVE_MARKUP_VIDEO = 2
• ALLOWED_AD_TYPE_AUDIO = 3 → CREATIVE_MARKUP_AUDIO = 3

The Google RTB protocol represents the duration in milliseconds, whereas OpenRTB uses seconds.

The Google RTB field is an enum whereas the OpenRTB field is an integer. The integer specified in OpenRTB maps directly to Google RTB protocol's enum value.

• UNKNOWN_AUTO_REFRESH_TYPE = 0
• USER_ACTION = 1
• EVENT = 2
• TIME = 3