Native Ads

Native ads are ads formatted to fit the surrounding content and visual design, making them more likely to be viewed and clicked by users. Native ad inventory is available on mobile apps as well as desktop and mobile websites. For more information on native ads, see Overview of native ads.

Native ads are supported for both Authorized Buyers and Open Bidding.

Here's the workflow for native ads:

  1. A call for a native ad is made to Google. The call specifies one or both of the following native ad templates, each specifying the preferred native fields.
  2. Google sends buyers an RTB bid request containing a list of the fields being requested.
  3. Interested buyers respond with the requested fields.
  4. Google runs an auction to select the winning bid and sends the buyer's supplied creative assets to the publisher.
  5. The publisher assembles the assets into a native ad and styles them to fit the site's design.

Message formats

Google supports the OpenRTB specification in both JSON and Protobuf.

For OpenRTB Protobuf native ads, the following fields differ from the specification:

JSON JSON type Protobuf Protobuf type
BidRequest.imp[].native.request string BidRequest.imp[].native.request_native NativeRequest
BidResponse.seatbid[].bid[].adm string BidResponse.seatbid[].bid[].adm_native NativeResponse

The OpenRTB Protobuf fields are Protobuf messages rather than strings.

If you use the OpenRTB Protobuf implementation, your endpoint receives bid requests containing BidRequest.imp.native.request_native rather than BidRequest.imp.native.request. Additionally, your endpoint must return bid responses that populate BidResponse.seatbid.bid.adm_native rather than BidResponse.seatbid.bid.adm, otherwise it will be filtered from the auction.

If you use a buyer SDK to render native ads, you must include an image type in the declared_ad when you submit creatives for review.

Native ad templates

Native ad templates describe the components of a native ad, and determine the contents and structure of OpenRTB's NativeRequest or the deprecated Google RTB protocol's NativeAdTemplate in the bid request. Google supports the two most common native ad templates for non-video and video native ads:

Other templates exist, and may have a different set of requirements for fields, dimensions, and sizes.

App install ad template

The following tables show fields labeled Required or Recommended. The following rules apply:

  • Fields marked Required are required by the bidder.
  • Fields marked Recommended are not required by the bidder, and the publisher may or may not display them if supplied (for example, star rating).
  • Call to Action (CTA) is always marked as Recommended because a default is assigned if one is not sent by the bidder, but it will always be displayed if sent.

The following table lists the fields of an app install ad template. Mobile apps use these fields to create native app install ads.

Field Description Required or Recommended? Always displayed? Recommended image size/max number of chars Example
Headline The app title Required Yes 25 chars Flood-It!
Image A screenshot from the app, or another relevant image Required No 1,200px x 627px or 600px x 600px depending on the aspect ratio required by the publisher. <A screenshot from the game Flood-It!>
Body Main text of the app Required No 90 chars Deceptively simple + tantalizingly challenging = delightfully addictive!
App icon The app icon Required No 128 x 128 px <Flood-it! app icon>
Call to action Preferred user action Recommended Yes 15 chars Install
Star rating Number of stars (0 - 5) representing the app's rating in the app store Recommended No 0 - 5 4.5
Price The cost of the app Recommended No 15 chars Free

Notes about text length

If a buyer sends a text asset (body text, for example) longer than the suggested maximum number of characters, the text may be truncated and ellipsized by Google or the publisher. Note that the truncation limits are half the size in Chinese, Japanese, and Korean. For example, the headline limit is 90 for English and 45 for Chinese.

Notes about image size

Publishers are allowed to:

  • Crop the main image symmetrically by up to 20% in one dimension (height or width).
  • Scale the image without changing its aspect ratio.
  • Images that have aspect ratios substantially different than those implied by the height and width may be filtered.

Content ad template

The following table lists the fields of a content ad template. Publishers use these fields to create native content ads.

Field Description Required or Recommended? Always displayed? Recommended image size/max number of chars * Example
Headline The ad header Required Yes 25 chars Lowest mortgage rates
Image The ad's primary image Required No 1,200px x 627px or 600px x 600px depending on the aspect ratio required by the publisher. <Ad's main image>
Body The ad content Required No 90 chars Your home sweet Brooklyn home - cheaper and sooner than you think!
Logo Advertiser's logo or another relevant small image Recommended No 128 x 128 px <NY Mortgage Inc.'s logo>
Call to action User's preferred action Recommended No 15 chars Get a quote
Advertiser Text that identifies the advertiser or brand Required No 25 chars NY Mortgage Inc.

Video app install ad template

Field Description Required or Recommended? Always displayed? Recommended image size/max number of chars * Example
Video The video VAST response containing all necessary assets to play back a video ad. Required No - A URL to VAST XML containing a Flood-It! Video ad
Headline The app title Required Yes 25 chars Flood-It!
Image Image (thumbnail) shown in the player before the video ad is clicked or while it is loading. Required No Should match aspect ratio of video (for example: 1280x720 for 16x9 video, 4x3 for 640x480 video). A screenshot from the game Flood-It! Or from the video
Body Main text of the app Required No 90 chars Deceptively simple + tantalizingly challenging = delightfully addictive!
App icon The app icon Required No 128 x 128 px Flood-it! app icon
Call to action Preferred user action Required Yes 15 chars Install
Star rating Number of stars (0 - 5) representing the app's rating in the app store Recommended No 0 - 5 4.5
Price The cost of the app Recommended No 15 chars Free

Restrictions

  • Video: All video must be in the form of a VAST URL or a VAST Tag. A raw video file such as a WebM, MP4, etc cannot be specified.

  • Text length: If a buyer specifies a text asset such as the body in the response, it may be truncated and ellipsized by Google or the publisher. Note that truncation limits are half the size in Chinese, Japanese, and Korean. For example, the headline limit is 90 in English and 45 for Chinese.

  • Image size: Publishers are allowed to:

    • Crop the main image symmetrically by up to 20% in one dimension (height or width.
    • Scale the image without changing its aspect ratio.

App install ad example

native video

Video content ad template

Field Description Required or Recommended? Always displayed? Recommended image size/max number of chars * Example
Video The video VAST response containing all necessary assets to play back a video ad. Required Yes - A URL to VAST XML containing a Flood-It! Video ad
Headline The ad header Required Yes 25 chars Lowest mortgage rates
Image Image (thumbnail) shown in the player before the video ad is clicked or while it is loading. Required No Should match aspect ratio of video (for example: 1280x720 for 16x9 video, 4x3 for 640x480 video). A screenshot from the video
Body The ad content Required No 90 chars Your home sweet Brooklyn home - cheaper and sooner than you think!
Logo Advertiser's logo or another relevant small image Recommended No 128 x 128 px NY Mortgage Inc.'s logo
Call to action User's preferred action Required No 15 chars Get a quote
Advertiser Text that identifies the advertiser or brand Required No 25 chars NY Mortgage Inc.

Meta fields

The following meta fields are shared by all supported ad templates:

Google RTB protocol OpenRTB Equivalent Description
NativeAd.click_link_url Link.url The URL that will be called by the browser when the user clicks the ad. Can be the first step of a redirect chain that eventually leads to the landing page. For native ads, we recommend using click_link_url as the field to set the destination where the user will ultimately go. It is required to use this field in the case of dynamic landing pages.
Ad.click_through_url Bid.adomain

Must be set if the bidder intends to bid. This is the set of destination URLs for the snippet, including the URLs that the user will go to if they click the displayed ad, and any URLs that are visible in the rendered ad. Don't include intermediate calls to the adserver that are unrelated to the final landing page. A BidResponse that returns a snippet or video ad but declares no click_through_url will be discarded. Only set this field if html_snippet, video_url, or native_ad are set. This data is used as a destination URL declaration, for example for post-filtering of publisher-blocked URLs or ad categorization. Refer to NativeAd.click_link_url when using native ads.

For non-native ads, it is not used for click tracking or any other ad functionality; it is only used as a destination URL declaration.

For native ads, if NativeAd.click_link_url is not set, the first value of click_through_url is used to direct the user to the landing page. In addition, all values are used as destination URL declarations (similar to the non-native case).

NativeAd.click_tracking_urls Link.clicktrackers Optional. Additional URLs that allow advertisers to track user clicks on the ad.
Ad.ad_choices_destination_url BidExt.ad_choices_destination_url Link to an ad preferences or opt-out page. If present, a standard AdChoices icon is added to the native creative and linked to this URL. This is supported for native ads but is not part of the native message in the bid response.
Ad.impression_tracking_url NativeResponse.imptrackers The native impression should be tracked with impression_tracking_url in Authorized Buyers real-time bidding proto or Native imptrackers in OpenRTB.

required_fields and recommended_fields are specified by the publisher. We show how to translate these bit fields to determine if a field is required or recommended.

A bit field uses each bit of a binary value to store a true or false statement, equivalent to sending many boolean signals such as is_logo_required or is_header_required, but all packed together.

Example

For this example we'll use a required_fields value of 1085.

First, find the equivalent binary value: 10000111101

Once you have the binary value, you can check the bits to see if a field is required (1) or not required (0).

The following table maps the fields to their place in the binary value. Read the binary from right to left, with the 1-bit corresponding to the right-most place in the binary value.

Field Binary value placement (right to left)
HEADLINE 1
BODY 2
CALL_TO_ACTION 4
ADVERTISER 8
IMAGE 16
LOGO 32
APP_ICON 64
STAR_RATING 128
PRICE 256
STORE 512
VIDEO 1024

Looking at the example binary value 10000111101, the 1-bit (rightmost) is 1, signifying a required value. According to the table, the 1-bit corresponds to HEADLINE.

The 2-bit (second value from the right) is 0 signifying not required. The 2-bit corresponds to BODY.

Here are all the interpreted required fields in our example:

Value Description Required?
1 VIDEO Yes
0 STORE No
0 PRICE No
0 STAR_RATING No
0 APP_ICON No
1 LOGO Yes
1 IMAGE Yes
1 ADVERTISER Yes
1 CALL_TO_ACTION Yes
0 BODY No
1 HEADLINE Yes

Representation of the native ad template in the bid request

When receiving a bid request containing native inventory, it will contain the native ad template in different forms depending on the protocol used. We recommend using OpenRTB because the Google protocol is deprecated.

In OpenRTB, the native ad template is described with the NativeRequest message. In the Google RTB protocol, it is described with NativeAdTemplate. These messages provide the following details about the native ad inventory:

  • Fields that are required or recommended.
  • Dimensions for images, logos, and app icons.
  • Specifications for the style in which the ad is rendered.

OpenRTB asset IDs

OpenRTB passes an array of assets in the bid request that describe the structure of the native ad you should return in the response. Each asset in the request will have an ID that must specified for the corresponding asset in the response. For an example of how these IDs correspond between the request and response, see the native bid request sample and native bid response sample.

Representation of a native ad in the bid response

When bidding on native inventory, a buyer must populate required fields that were identified in the bid request. In OpenRTB, you can do this with BidResponse.seatbid.bid.adm_native when using Protobuf, or BidResponse.seatbid.bid.adm for JSON. For the deprecated Google protocol, this is done with the BidResponse.ad.native_ad field.

Example bid requests

Non-video bid requests

OpenRTB Protobuf

OpenRTB JSON

Google

Video bid requests

Example bid responses

Non-video bid responses

OpenRTB Protobuf

OpenRTB JSON

Google

Video bid responses