Native 1.2
- 对象
- 15
- 字段
- 79
本版本数据来自官方历史 PDF 的 OCR 识别稿，逐表人工审核后入库，为 draft 状态；审核修复与忠实保留的官方怪癖均登记于对象注记与溯源记录。
Bid Request 侧（§4）
| Native Markup Request§4.1 | 12 字段1 必填 | The Native Object defines the native advertising opportunity available for bid via this bid request. It will be included as a JSON-encoded string in the bid request’s imp.native field or as a direct JSON object, depending on the choice of the exchange. While OpenRTB 2.x officially supports only JSON-encoded strings, many exchanges have implemented a formal object. Check with your integration docs. The Default column dictates how optional parameters should be interpreted if explicit values are not provided. |
| Asset Request§4.2 | 7 字段1 必填 | The main container object for each asset requested or supported by Exchange on behalf of the rendering client. Any object that is required is to be flagged as such. Only one of the {title,img,video,data} objects should be present in each object. All others should be null/absent. The id is to be unique within the AssetObject array so that the response can be aligned. To be more explicit, it is the ID of each asset object that maps the response to the request. So if a request for a title object is sent with id 1, then the response containing the title should have an id of 1. Since version 1.1 of the spec, there are recommended sizes/lengths/etc with some of the asset types. The goal for asset requirements standardization is to facilitate adoption of native by DSPs by limiting the diverse types/sizes/requirements of assets they must have available to purchase a native ad impression. While great diversity may exist in publishers, advertisers/DSPs can not be expected to provide infinite headline lengths, thumbnail aspect ratios, etc. While we have not gone as far as creating a single standard, we've honed in on a few options that cover the most common cases. SSPs can deviate from these standards, but should understand they may limit applicable DSP demand by doing so. DSPs should feel confident that if they support these standards they'll be able to access most native inventory. |
| Title Request§4.3 | 2 字段1 必填 | The Title object is to be used for title element of the Native ad. |
| Image Request§4.4 | 7 字段 | The Image object to be used for all image elements of the Native ad such as Icons, Main Image, etc. Recommended sizes and aspect ratios are included in the Image Asset Types section. |
| Video Request§4.5 | 5 字段4 必填 | The video object to be used for all video elements supported in the Native Ad. This corresponds to the Video object of OpenRTB. Exchange implementers can impose their own specific restrictions. Here are the required attributes of the Video Object. For optional attributes please refer to OpenRTB. |
| Data Request§4.6 | 3 字段1 必填 | The Data Object is to be used for all non-core elements of the native unit such as Brand Name, Ratings, Review Count, Stars, Download count, descriptions etc. It is also generic for future native elements not contemplated at the time of the writing of this document. In some cases, additional recommendations are also included in the Data Asset Types table. |
| Event Trackers Request§4.7 | 3 字段2 必填 | The event trackers object specifies the types of events the bidder can request to be tracked in the bid response, and which types of tracking are available for each event type, and is included as an array in the request. |
Bid Response 侧（§5）
| Native Markup Response§5.1 | 10 字段1 必填 | The native object is the top level JSON object which identifies a native response. The native object has following attributes: |
| Asset Response§5.2 | 8 字段 | Corresponds to the Asset Object in the request. The main container object for each asset requested or supported by Exchange on behalf of the rendering client. Any object that is required is to be flagged as such. Only one of the {title,img,video,data} objects should be present in each object. All others should be null/absent. The id is to be unique within the AssetObject array so that the response can be aligned. |
| Title Response§5.3 | 3 字段1 必填 | Corresponds to the Title Object in the request, with the value filled in. If using assetsurl or dcourl response rather than embedded asset response, it is recommended that three title objects be provided, the length of each of which is less than or equal to the three recommended maximum title lengths (25,90,140). |
| Image Response§5.4 | 5 字段1 必填 | Corresponds to the Image Object in the request. The Image object to be used for all image elements of the Native ad such as Icons, Main Image, etc. It is recommended that if assetsurl/dcourl is being used rather than embedded assets, that an image of each recommended aspect ratio (per the Image Types table) be provided for image type 3. |
| Data Response§5.5 | 4 字段1 必填 | Corresponds to the Data Object in the request, with the value filled in. The Data Object is to be used for all miscellaneous elements of the native unit such as Brand Name, Ratings, Review Count, Stars, Downloads, Price count etc. It is also generic for future native elements not contemplated at the time of the writing of this document. |
| Video Response§5.6 | 1 字段1 必填 | Corresponds to the Video Object in the request, yet containing a value of a conforming VAST tag as a value. |
| Link Response§5.7 | 4 字段1 必填 | Used for ‘call to action’ assets, or other links from the Native ad. This Object should be associated to its peer object in the parent Asset Object or as the master link in the top level Native Ad response object. When that peer object is activated (clicked) the action should take the user to the location of the link. |
| Event Tracker Response§5.8 | 5 字段2 必填 | The event trackers response is an array of objects and specifies the types of events the bidder wishes to track and the URLs/information to track them. Bidder must only respond with methods indicated as available in the request. Note that most javascript trackers expect to be loaded at impression time, so it’s not generally recommended for the buyer to respond with javascript trackers on other events, but the appropriateness of this is up to each buyer. |