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.

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 Google RTB protocol's id_type field only has a SITE_SCOPED_COOKIE value. OpenRTB's stype field is equivalent when set to "fpc".

The meaning of OpenRTB's field depends on the value of the stype extension. When set to "fpc", it refers to a publisher first-party (site-scoped) cookie.

BidRequest.user.data.ext.segtax
BidRequest.site.content.data.ext.segtax
BidRequest.app.content.data.ext.segtax

BidRequest.user.data.segment.id
BidRequest.site.content.data.segment.id
BidRequest.app.content.data.segment.id

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

OpenRTB concatenates the major, minor, and micro version numbers into a single string. For example, if the string were "1.0.2", major would be set to 1.

OpenRTB concatenates the major, minor, and micro version numbers into a single string. For example, if the string were "1.0.2", minor would be set to 0.

OpenRTB concatenates the major, minor, and micro version numbers into a single string. For example, if the string were "1.0.2", micro would be set to 2.

OpenRTB's BidRequest.app field is an object providing information about the publisher's app. Its presence is equivalent to is_app being set to True.

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

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

Use BidRequest.device.ifa instead.

The Google RTB protocol represents this as bytes, while for OpenRTB this is represented as a string containing either a 16 byte UUID, or a 32 byte alphanumeric ID (for Samsung IDs).

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

Use BidRequest.device.dpimd5 instead.

The Google RTB protocol represents this as bytes, whereas OpenRTB represents this as a string containing a hexadecimal value.

The Google RTB protocol represents this as a float, whereas OpenRTB represents this as a string containing a decimal value.

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.

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

Note that this can still be determined if the domain in BidRequest.{app/site}.content.producer.domain differs from the domain in BidRequest.{app/site}.content.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 OpenRTB field is supported, but considered deprecated. We recommend using BidRequest.imp.banner.format instead.

The OpenRTB field is supported, but considered deprecated. We recommend using BidRequest.imp.banner.format instead.

The OpenRTB field is supported, but considered deprecated. We recommend using BidRequest.imp.banner.format instead.

The OpenRTB field is supported, but considered deprecated. We recommend using BidRequest.imp.banner.format instead.

In OpenRTB, billing IDs are stored in a flat list that has no particular grouping or ordering. See Eligible Buyers and Deals for more information.

The Google RTB protocol uses an integer to represent the floor of the auction in micros of the buyer's configured currency. If there are multiple buyers with differing currencies, this value might differ across buyers while having the same monetary value. See Eligible Buyers and Deals for more details.

OpenRTB uses a single double to represent the floor of the auction in the bidder's configured currency that is provided in BidRequest.imp.bidfloorcur, which is applied to all buyers.

bidfloor = minimum_cpm_micros / 1,000,000

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

The Google RTB protocol represents this in micros of the given currency as an integer, whereas OpenRTB represents the value in CPM currency units, as a double.

bidfloor = fixed_cpm_micros / 1,000,000

Note that the value sent in OpenRTB bid request may differ because Google RTB protocol uses the deal buyer's currency, whereas OpenRTB uses the bidder's currency.

The Google RTB protocol and OpenRTB fields are represented with an identical enum.

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.

Google protocol uses a single bitfield to determine whether several components of the native ad are required, whereas OpenRTB defines all components as a list of assets, which are required if its required field is set to True.

Google protocol uses a single bitfield to determine whether several components of the native ad are recommended, whereas OpenRTB defines all components in a list of assets, which are recommended if its required field is set to False.

The Google RTB protocol's HEADLINE component is equivalent to OpenRTB's Title asset.

The Google RTB protocol's BODY component is equivalent to OpenRTB's Data asset with its type set to DESC.

The Google RTB protocol's CALL_TO_ACTION component is equivalent to OpenRTB's Data asset with its type set to CTATEXT.

The Google RTB protocol's ADVERTISER component is equivalent to OpenRTB's Data asset with its type set to SPONSORED.

The Google RTB protocol's PRICE component is equivalent to OpenRTB's Data asset with its type set to PRICE.

The Google RTB protocol's IMAGE component is equivalent to OpenRTB's Image asset with its type set to MAIN.

The Google RTB protocol's IMAGE component is equivalent to OpenRTB's Image asset with its type set to MAIN.

The Google RTB protocol's LOGO component is equivalent to OpenRTB's Image asset with its type set to LOGO.

The Google RTB protocol's LOGO component is equivalent to OpenRTB's Image asset with its type set to LOGO.

The Google RTB protocol's APP_ICON component is equivalent to OpenRTB's Image asset with its type set to APP_ICON.

The Google RTB protocol's APP_ICON component is equivalent to OpenRTB's Image asset with its type set to APP_ICON.

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 OpenRTB field is an enum that represents several possible ad positions. When set to SIDEBAR it is equivalent to when vertical_stickiness is True.

OpenRTB's pos field also maps to Google RTB protocol's BidRequest.adslot.slot_visibility.

The OpenRTB field is an enum that represents several possible ad positions. When set to HEADER it is equivalent to when top_horizontal_stickiness is True.

OpenRTB's pos field also maps to Google RTB protocol's BidRequest.adslot.slot_visibility.

The OpenRTB field is an enum that represents several possible ad positions. When set to FOOTER it is equivalent to when bottom_horizontal_stickiness is True.

OpenRTB's pos field also maps to Google RTB protocol's BidRequest.adslot.slot_visibility.

The Google RTB protocol represents this with bytes, whereas OpenRTB uses a base64-escaped string.

These fields are deprecated and are not populated in the bid request.

The Google RTB protocol uses an integer to represent the price in micros using the bidder's configured currency. OpenRTB uses a double to represent the price in the bidder's currency units.

OpenRTB value = Google RTB value / 1,000,000

The Google RTB protocol uses an integer to represent the price in micros using the bidder's configured currency. OpenRTB uses a double to represent the price in the bidder's currency units.

OpenRTB value = Google RTB value / 1,000,000

The Google RTB protocol uses an integer to represent the price in micros using the bidder's configured currency. OpenRTB uses a double to represent the price in the bidder's currency units.

OpenRTB value = Google RTB value / 1,000,000

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

The OpenRTB dsa extension more closely matches the IAB spec, so it doesn't include the DSA_SUPPORT_UNKNOWN enum value. As a result, integer mappings for the remaining enum names are different.

The OpenRTB dsa extension more closely matches the IAB spec, so it doesn't include the PUBLISHER_RENDERING_SUPPORT_UNKNOWN enum value. As a result, integer mappings for the remaining enum names are different.

The OpenRTB dsa extension more closely matches the IAB spec, so it doesn't include the DATA_TO_PUBLISHER_UNKNOWN enum value. As a result, integer mappings for the remaining enum names are different.