Structures

Undocumented

Nimbus companion ad info (used with video ads)

Ad sent back by Nimbus

Custom extensions (includes info about SKAdNetwork)

Dimensions for the Nimbus ad

Undocumented

SKAdNetwork info

Trackers for the Nimbus ad

A mapping using a linear step function to generate the keywords By default, this class will map to a keyword of “nimbus{width}_{height}:{bucket}” i.e nimbus320_50:500 for a bid at 5 dollars.

A mapping composed of multiple LinearPriceGranularities in ascending order

This object should be included if the ad supported content is a non-browser application (typically in mobile) as opposed to a website. OpenRTB Section 3.2.14

This describes the publisher of the media in which the ad will be displayed. The publisher is typically the seller in an OpenRTB transaction. OpenRTB Section 3.2.15

This object encapsulates various methods for specifying a geographic location. When subordinate to a NimbusDevice object, it indicates the location of the device which can also be interpreted as the user’s current location. When subordinate to a NimbusUser object, it indicates the location of the user’s home base (i.e., not necessarily their current location). The NimbusGeo.latitude/NimbusGeo.longitude attributes should only be passed if they conform to the accuracy depicted in the NimbusGeo.type attribute. For example, the centroid of a geographic region such as postal code should not be passed. OpenRTB Section 3.2.19

This object provides information pertaining to the device through which the user is interacting. Device information includes its hardware, platform, location, and carrier data. The device can refer to a mobile handset, a desktop computer, set top box, or other digital device. OpenRTB Section 3.2.18

A type-erased Codable value. Supported types: Bool, Int, Float, String, Array and Dictionary

Compression level whose rawValue is based on the zlib’s constants.

Errors on gzipping/gunzipping based on the zlib error codes.

Supported ad format with a width and height

This object represents the most general type of impression. Although the term “banner” may have very specific meaning in other contexts, here it can be many things including a simple static image, an expandable ad unit, or even in-banner video (refer to NimbusImpressionVideo object for the more generalized and full featured video ad units). An array of NimbusImpressionBanner objects can also appear within the video to describe optional companion ads defined in the VAST specification. The presence of a NimbusImpressionBanner as a subordinate of the NimbusImpression object indicates that this impression is offered as a banner type impression. At the publisher’s discretion, that same impression may also be offered as video, audio, and/or native by also including as NimbusImpression subordinates objects of those types. However, any given bid for the impression must conform to one of the offered types. OpenRTB Section 3.2.6

Undocumented

This class represents a native type impression.

Native ad units are intended to blend seamlessly into the surrounding content (e.g., a sponsored Twitter or Facebook post). As such, the response must be well-structured to afford the publisher fine-grained control over rendering. The Native Subcommittee has developed a companion specification to OpenRTB called the Dynamic Native Ads API. It defines the request parameters and response markup structure of native ad units. This object provides the means of transporting request parameters as an opaque string so that the specific parameters can evolve separately under the auspices of the Dynamic Native Ads API. Similarly, the ad markup served will be structured according to that specification. The presence of a Native as a subordinate of the Imp object indicates that this impression is offered as a native type impression. At the publisher’s discretion, that same impression may also be offered as banner, video, and/or audio by also including as Imp subordinates objects of those types. However, any given bid for the impression must conform to one of the offered types.

OpenRTB Section 3.2.9

This object describes an ad placement or impression being auctioned. A single bid request can include multiple NimbusImpression objects, a use case for which might be an exchange that supports selling all ad positions on a given page. Each NimbusImpression object has a required ID so that bids can reference them individually. The presence of NimbusImpressionBanner or NimbusImpressionVideo objects subordinate to the NimbusImpression object indicates the type of impression being offered. The publisher can choose one such type which is the typical case or mix them at their discretion. However, any given bid for the impression must conform to one of the offered types. OpenRTB Section 3.2.4

This object represents an in-stream video impression. Many of the properties are non-essential for minimally viable transactions, but are included to offer fine control when needed. Video in OpenRTB generally assumes compliance with the VAST standard. As such, the notion of companion ads is supported by optionally including an array of NimbusImpressionBanner objects that define these companion ads. The presence of a NimbusImpressionVideo as a subordinate of the NimbusImpression object indicates that this impression is offered as a video type impression. At the publisher’s discretion, that same impression may also be offered as banner, audio, and/or native by also including as NimbusImpression subordinates objects of that type. However, any given bid for the impression must conform to one of the offered types. OpenRTB Section 3.2.7

Auction data to report to Nimbus

• auctionPrice: Price of the winning auction in CPMs converted to a String
• auctionMinToWin: The 2nd highest bid in the auction or the price floor if there was only 1 bid
• winningSource: The name of the buyer that won the auction

This object contains any legal, governmental, or industry regulations that apply to the request. The NimbusRegs.coppa flag signals whether or not the request falls under the United States Federal Trade Commission’s regulations for the United States Children’s Online Privacy Protection Act (“COPPA”). OpenRTB Section 3.2.3

This object describes the nature and behavior of the entity that is the source of the bid request upstream from the exchange. The primary purpose of this object is to define post-auction or upstream decisioning when the exchange itself does not control the final decision. A common example of this is header bidding, but it can also apply to upstream server entities such as another RTB exchange, a mediation platform, or an ad server combines direct campaigns with 3rd party demand in decisioning. OpenRTB Section 3.2.2

The data and segment objects together allow additional data about the related object (e.g., user, content) to be specified. This data may be from multiple sources whether from the exchange itself or third parties as specified by the NimbusUserData.id field. A bid request can mix data objects from multiple providers. The specific data providers in use should be published by the exchange a priori to its bidders. OpenRTB Section 3.2.21

Segment objects are essentially key-value pairs that convey specific units of data. The parent Data object is a collection of such values from a given data provider. The specific segment names and value options must be published by the exchange a priori to its bidders. OpenRTB Section 3.2.22

Undocumented

This object contains information known or derived about the human user of the device (i.e., the audience for advertising). The user id is an exchange artifact and may be subject to rotation or other privacy policies. However, this user ID must be stable long enough to serve reasonably as the basis for frequency capping and retargeting. OpenRTB Section 3.2.20