AMP Ads over RTB

This page describes how to get started using AMP Ads with RTB. Check out the Resources below for additional info about AMP Ads and tools to help you get started.

High-level approach

RTB bid response

Owner: Bidder

  • The new BidResponse.Ad.amp_ad_url field to be added to Ad Exchange bid responses that accept a URL pointing to AMP Ad content.
    // The URL to fetch an AMP Ad. Only one of the following should be set:
    html_snippet, video_url, amp_ad_url.
    
    optional string amp_ad_url = 23
    
  • In OpenRTB, Google proposed a new field to the Bid object.
    Bid object additional field: ampadurl
    Field Type Description
    ampadurl string Optional means of conveying AMP Ad markup in case the bid wins; only one of ampadurl or adm should be set. Substitution macros (Section 4.4) may be included. URL should point to a creative server containing valid amp4ads HTML.

Verification of valid AMP

Owner: Exchange

  • For AMP Ads to be early rendered, the exchange is required to verify and sign in at the time that the ad is written in amp4ads <html amp4ads> creative format.
  • Ads that are valid amp4ads will be allowed to render early by AMP pages. Ads that are not verified as valid amp4ads will render at the same speed as non-AMP Ads.

    Only amp4ads should be returned in the amp_ad_url.

  • In the future, if a publisher requires amp4ads only, ads not signed as amp4ads will not be rendered.

    On Ad Exchange, bidders will still be charged if they return a non-AMP Ad to an amp4ads-required adslot.

Server-side fetch

Owner: Exchange and Bidder

  • For amp4ads to be early rendered, AMP Ad content must be fetched with 0 additional hops from the client. This is designed to avoid poor user experiences due to ad latency and extra client-side calls.
  • The exchange's servers (not the client browser) will request the AMP Ad content located at the URL provided in amp_ad_url after a bidder wins the auction. Creative servers must respond and return content within 150 ms.
  • Ad Exchange passes the HTTP header and IP from the user's browser to the creative server during retrieval of the AMP Ad specified in amp_ad_url. This ensures the creative server receives information similar to that sent from a standard client-side fetch. In some cases, the IP address may be truncated to only the first 3 bytes (IPv4) or first 6 bytes (IPv6). Here is a sample HTTP header:
  • The amp4ad will be injected into the adslot and subsequently rendered. Note that since a valid amp4ads cannot contain an iframe or another ad tag, the server-side fetch must retrieve the actual HTML of the creative.

Impression tracking URLs

Owner: Exchange and Bidder

  • RTB buyers often include impression trackers as a structured field in the bid response (this is Bid.burl, the "billing notice URL" in OpenRTB 2.5).
  • On Ad Exchange, these will be fired client-side; amp-pixel fires tracking URLs when the creative is rendered. amp-analytics can handle more advanced tracking use cases beyond rendering.

Cookie matching

Owner: Bidder

Creatives often include cookie matching pixels within the creative code. AMP Ads can use the amp-pixel and amp-analytics components for this use case. If your use case cannot be accommodated by using amp-analytics or amp-pixel, open a GitHub issue to discuss alternate options. We welcome new extensions that can be broadly used by a number of different companies. See detailed guidelines or a technical guide to building a new extension.

Sample AMP Ad URLs for testing

Here are some example AMP Ad URLs with valid AMP Ad content that can be used for testing.

Resources

The AMP Project and Google have released a number of resources to help you get started:

Building ads in AMP
RTB-specific proposals to IAB / OpenRTB Group

Send feedback about...

Real-Time Bidding Protocol
Real-Time Bidding Protocol