Stay organized with collections
Save and categorize content based on your preferences.
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:
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.
Google sends buyers an RTB bid request containing a list of the
fields being requested.
Interested buyers respond with the requested fields.
Google runs an auction to select the winning bid and sends the
buyer's supplied creative assets to the publisher.
The publisher assembles the assets into a native ad and styles them
to fit the site's design.
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.
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
Required and recommended fields
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.
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.
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.
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.
Google RTB protocol required and recommended fields
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.
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.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-09-26 UTC."],[],[]]