Siden du har forespurt, er ikke tilgjengelig på språket ditt ennå. Du kan velge et annet språk nederst på siden. Eventuelt kan du bruke den innebygde oversettingsfunksjonen i Google Chrome til å oversette en hvilken som helst nettside til det språket du foretrekker.

Delivery basics

Ad selection white paper

Table of contents

House line items and the auction

House* line items only serve when no remnant line items (Network, Bulk, Price Priority), Ad Exchange or Open Bidding demand are available to serve. That is, House line items are treated as if they have a $0 rate and do not compete on price through dynamic allocation.

House line item CPM determines ranking of eligible House ads but doesn't need to meet any floor price set in unified pricing rules in order to be eligible to serve an ad, thereby effectively serving as a fall-back ad. Learn more about unified pricing rules.**

* Note that Price Priority, Bulk and Network line items that do not compete on price in the unified auction (such as line items with a zero rate and no Value CPM) are treated as House line items.
** For video optimized pods, House line items compete based on CPM.

Introduction

This white paper describes the tools and mechanics of the ad selection process in Google Ad Manager, as well as how a creative is chosen from within a selected line item. It is intended for network administrators, traffickers, and salespeople, and assumes a general understanding of the Ad Manager system and concepts of ad serving.

Help me troubleshoot delivery

Notes and definitions

  • HTTPS refer to the protocol used in ad serving in the context of this article. Ad Manager fully supports the "HTTPS Everywhere" model to protect user privacy. Learn more in the blog post Ads Take a Step Towards “HTTPS Everywhere”.
  • When using GPT's Single Request Architecture (SRA), all ad slots on a page are requested using a single HTTPS request.
  • When a page contains multiple ad slots, declare slot definitions in the header according to the order they should be filled. Slot order may inform Ad Manager ad selection and impact serving behaviors, such as roadblocking and creative rotation, discussed later in this document. Learn more about slot definition and sequentiality.
  • Tag syntax is outside the scope of this article and is covered in the article on generating Ad Manager ad tags.
  • Implementation details for demand side platforms (DSPs) are outside the scope of this article.

Overview of the ad selection process

Ad Manager's ad selection process is designed to deliver the right ad to the right customer at the right time. Below is the process that Ad Manager follows to select an ad to serve:A user's web browser or mobile device loads an Ad Manager ad tag (on a site) or Ad Manager ad code (in an app) and triggers an ad request, which passes information to the ad server.

  1. The ad server creates a list of all line items matching the targeting criteria.
  2. Ad Manager uses dynamic allocation to check if Ad Exchange, AdSense, Open Bidding, or a remnant line item can be served without affecting the delivery goals or pacing for guaranteed line items. This increases overall yield for the network without increasing the risk of underdelivery.
  3. The ad server selects the best creative from within the selected line item or RTB demand.
  4. The ad server serves the creative to the user.

The ad selection process

The sections that follow provide detailed information about each stage in this process.

1. An ad request passes information to the ad server

Ad requests are triggered by resources (for example, JavaScript libraries like GPT on web pages, or application code on a mobile app) rendered by a user's web browser or mobile device, and they initiate an HTTP request to an ad server.

Information about the user and the device is passed within the request to Ad Manager, allowing Ad Manager to match the right ad with the right user. Five crucial pieces of data are transmitted in the ad request:

  • The HTTP header
  • The IP address
  • A user identifier (containing no personally identifiable information), which could be one of the following:
    • Resettable mobile device advertising ID (for in-app ad requests; examples: AdID for Android; IDFA for iOS; other identifiers for devices such as Roku)
    • PPID (for publishers that have it set in their ad requests)
    • DoubleClick cookies (for desktop and mobile browsers)
  • The custom targeting criteria set by the publisher in the Ad Manager ad tags
  • A "correlator" value shared between ad requests on the same page

The table below details how this data is used in the ad selection process. The Ad Manager ad server only checks the user identifiers described above if they are allowed by the individual user; that is, if the user hasn't opted out or blocked them via browser settings or mobile tracking restrictions.

Summary of data types (table)
Data Provides information on
HTTP header Browser type
Operating system
Date and time
IP address Geographic location
Internet-related targeting information like user domain
User identifier Frequency capping
Creative rotation
Audience list membership
Ad Manager ad tags Ad unit and size
Which creative types the ad unit can receive
Custom targeting parameters (key-values)
Correlator value Which ad requests belong to the same page view (used for
advanced serving functionality like roadblocking)

2. A list of matching line items and yield groups is created

Once the ad server gathers the relevant information for the ad request, it generates a list of all line items and yield groups that match a subset of the targeting criteria of the request.

For example, if the request comes from a man in California using Linux:

  • A line item or yield group targeting Men in California is on the list.
  • A line item or yield group targeting Men in California on Windows is not on the list.
  • A line item or yield group targeting Men in Vermont is not on the list.
About inventory matching: The ad server considers all line items/yield groups targeting a piece of inventory anywhere between the ad unit and the network level (ad unit hierarchy is available in Google Ad Manager 360 only). This allows the creation of run-of-site and run-of-network ads without the need to explicitly target every ad unit in the tree. For example, a line item that’s run-of-network and targeted to Sports or to Baseball could serve to a tag with a first-level ad unit called Sports and a second-level ad unit called Baseball.

3. The best line item is selected

From the list of matching line items, the ad server then removes any line items that aren't eligible to serve for various reasons, such as:

  • Frequency capping
  • Day parting
  • Exclusions (competitive restrictions and similar line items)

The ad server also looks at the correlator value passed within the request to identify other ads that have already been chosen to serve in this page view. Ads previously chosen to serve on the page can affect eligibility of other line items to serve within the page view, in cases such as:

  • Roadblocking (showing two or more creatives together) or as-many-as-possible (AMAP). (Roadblocking is available in Google Ad Manager 360 only.)
  • Advertiser exclusions (preventing two advertisers with competing businesses from showing up on the same page)
In some instances, Ad Manager considers other factors such as CTR to select line items that optimize a publisher's yield.

Using dynamic allocation, Ad Manager optimizes the distribution of remnant inventory (including Ad Exchange, Open Bidding, mediation, and others) against goal-based line item delivery, without compromising reservation goals. Specifically, with dynamic allocation, Ad Manager considers standard line items and remnant line items that can serve to an eligible impression. It then makes its selection based on the higher of the CPM of eligible remnant line items or a calculated opportunity cost of line items with delivery goals.

When considering guaranteed and remnant line items with dynamic allocation, Ad Manager takes the following into consideration:

  • Remnant line items are those that are in the remnant space, defined as line items in a given auction that are equal to or a lower priority than the highest of:
    • Priority 12
    • 1 greater (numerically) than the highest priority (numerically lower) Ad Exchange, AdSense, or Price Priority line item
  • Guaranteed line items are those that are not in the remnant space.

4. The best creative is selected

Once the best line item is selected, the Ad Manager ad server chooses the best creative:

  1. Creatives that don’t match the size of the ad request are filtered out.
  2. Only creatives of a valid type for that slot based on format (image, video, and so on) are considered.
  3. If a creative from a line item has already shown in this page view, it’s excluded from serving to other slots on the page. This prevents "jackpotting," where the same creative serves to all the slots on the page.
  4. At the end of filtering:
    1. If the line item contains only one matching creative, it’s served.
    2. If the line item contains no matching creatives, the ad server moves to the next best line item and repeats this process.
    3. If the line item contains more than one matching creative, creative rotation rules come into play:
      • Evenly: Rotate creatives evenly
      • Optimized: Choose the creative with the highest historical click-through rate.
      • Weighted: Choose a creative at random, but according to the relative weights specified for each (such as 70/30).
      • Sequential: Rotate creatives in the order specified, with each creative being numbered between 1 and 80. When creatives rotate sequentially, each user sees creatives in the specified order any time the line item is served to them — even across multiple page views. Serving sequence wraps around from the last creative to the first.

5. The creative is served

This is the final step of the ad selection process. At this point, Ad Manager has selected the creatives to serve for all the ad slots that are part of the HTTP request. Ad Manager records information about the winning ads for delivery reporting purposes, then constructs an HTTP response containing the creative code, and replies to the original HTTP request.

The GPT tagging library (on web and mobile web) or ads SDK (on mobile apps) receives the response and processes it. In the case of a GPT SRA request, this involves matching the specific creatives to the appropriate ad slots on the page. When the creative is added to the slot, any additional resources (for example, external images or scripts) are also downloaded and rendered. Ad serving is complete.

Was this helpful?

How can we improve it?
Search
Clear search
Close search
Main menu
4964059219199102139
true
Search Help Center
true
true
true
true
true
148
false
false