You can now access RTB Breakout metrics programmatically with new RTB troubleshooting resources added to the DoubleClick Ad Exchange Buyer REST API. These include the following:

• filterSets
• filterSets.bidMetrics
• filterSets.bidResponseErrors
• filterSets.bidResponsesWithoutBids
• filterSets.filteredBidRequests
• filterSets.filteredBids
• filterSets.filteredBids.creatives
• filterSets.filteredBids.details
• filterSets.impressionMetrics
• filterSets.losingBids
• filterSets.nonBillableWinningBids

RTB troubleshooting resources are placed hierarchically under both bidders and bidders.accounts. For more information about these resources and how they differ when used at the bidder or account level see the RTB troubleshooting guide.

If you have any feedback or questions about the RTB troubleshooting resources, feel free to reach out to us via the DoubleClick Ad Exchange Buyer API support forum.

 - Mark Saniscalchi, Ad Exchange Team

The DoubleClick Ad Exchange (AdX) Buyer SOAP API and legacy AdX UI will be sunset in January, 2016. After the API is sunset, all static bidding campaigns will be terminated, and requests against any version of the API from AdX accounts will result in an error response. In addition, the legacy AdX UI will no longer be accessible.

As an alternative to the SOAP API, we recommend using the DoubleClick Ad Exchange Hosted Bidding solution. Similar to the static bidding functionality offered by the SOAP API and legacy UI, Hosted Bidding allows you to bid on Ad Exchange inventory without an external real-time bidding platform. At this time, Hosted Bidding is only accessible as a UI that can be found by signing in to your Ad Exchange Account and clicking the Hosted Bidding tab. To learn more, read the Hosted Bidding guide.

These sunsets will not affect real-time bidding applications. All features required to configure real-time bidding campaigns were migrated to the DoubleClick Ad Exchange Buyer REST API when we updated our pretargeting capabilities in July 2014.

If you have any comments or questions about the upcoming sunset, feel free to contact us via the forum or our Ads Developer G+ page.

 - Mark Saniscalchi, DoubleClick Ad Exchange Team

We’ve just released the Budget resource for the DoubleClick Ad Exchange Buyer REST API, which can be used to set a daily budget for your real-time bidding campaigns. Each PretargetingConfig will have an associated Budget that it is mapped to via the billingId. Once a PretargetingConfig meets or exceeds the budgetAmount set by its Budget, it will no longer receive bid requests for the remainder of the day. Additional information about this resource can be found in the guide.

The Budget resource in the REST API and the BudgetService in the SOAP API can be used interchangeably; however, we recommend that you use the REST API for managing the budgets of your real-time bidding campaigns.

If you have any questions or comments about the Budget resource, please contact us via the forum or our Ads Developer G+ page.

 - Mark Saniscalchi, Ad Exchange Team

Working with multiple exchanges is a key pain point for those developing real-time bidders. To-date, individual exchanges have used their own distinct protocols requiring the time-consuming development of a separate model for each exchange. In response, the OpenRTB consortium introduced standards for communication in real-time bidding that greatly simplifies the process of adding support for new exchanges. That’s why we are pleased to announce two new open source libraries that implement the OpenRTB specification and are now available on GitHub—google/openrtb and google/openrtb-doubleclick.

The openrtb library provides support for the core OpenRTB model and was designed with extensibility in mind to support the development of libraries for other exchanges. The openrtb-doubleclick library is an extension of openrtb for DoubleClick Ad Exchange that provides interoperability between the OpenRTB model and DoubleClick's Real-Time Bidding protocol. The library also includes DoubleClick-specific utilities. In summary, these libraries provide the following:

• The model - The RTB model, as seen in the OpenRTB specification.
• The mapper - Translates DoubleClick’s native model to/from OpenRTB.
• The serializer - Translates JSON to/from the OpenRTB model.
• DoubleClick Ad Exchange utilities - Utilities to handle bid validation, DoubleClick crypto and metadata.

For more information about the OpenRTB specification, check out the documentation on their Github page.

 - Mark Saniscalchi, Ad Exchange Team

Two years ago, we introduced the Ad Exchange Real-Time Bidding Optimization Series on the developer's blog with our first post on post-filtered bids. Since then we’ve added tons of new formats and options for buying. Today, we’ll direct you to our Developers site for more information about how the video review process works, how throttling and filtering occur and highlight best practices to ensure smooth delivery.

The first step is to know your video-specific terms. Check out the in-stream video glossary to find definitions for terms with which you’re not familiar. Once you've created your in-stream video ad, you will need to monitor your video ads. The Video Best Practices Guide provides a list of ways to confirm your video ads are serving:

• Creative review process
• Key performance metrics
• Understanding throttling
• Filtering Reasons
• Ensuring delivery
• Resources

Have questions or feedback? Reach out to your Ad Exchange account team.

Posted by the Ad Exchange Team

DoubleClick Ad Exchange is improving its pretargeting system by creating a new user interface and API resource to configure the inventory your bidder sees. These changes will only impact your RTB campaigns; non-RTB campaigns will continue to be managed as they were before.

Upgrades will begin in mid-July 2014 and all accounts will be upgraded by the end of September 2014. The new functionality has been added to the v1.3 REST API but will be read-only until your account has been upgraded. For additional information, please review the new resource reference and pretargeting guide.

Note that once your account has been upgraded you will still have access to the SOAP API for reporting, budgeting and non-RTB campaigns, but you will no longer be able to use it for pretargeting. If you need the ability to manage your pretargeting settings via the API, then you must use the latest AdX REST API.

If you have questions about these upcoming changes please contact your account manager. For questions about the Ad Exchange Buyer API, check out the Ad Exchange Buyer API forum. Follow our Google+ page for other announcements and updates.

Dean Lukies, DoubleClick Ad Exchange Buyer API Team

The end of the year is always the busiest time for advertisers, and competition for inventory in Ad Exchange is at it’s peak. Are you doing everything you can to ensure your campaigns are delivering on time and on budget?

To lighten the load this holiday season, optimize your ad serving with these simple steps:

Plan ahead for the busiest time of the year
Make a resolution to start planning your seasonal campaigns earlier. Submit your creatives for approval two days before going live and make sure you’re using only certified vendors and declaring them when necessary. The set of allowed vendors and whether they are declarable can be determined using the vendor declaration tool found in the help centre article Declaring 3rd- and 4th-party vendors in the Ad Exchange. Any vendor not on the list in the tool is prohibited As a proactive measure, buyers can use the creative REST API to submit an ad creative for review, to check its status and retrieve a list of all active ad creatives. Be sure your ads are approved before bidding to ensure your campaigns deliver.

This year, the REST API has been updated with a new method allowing creatives to be sent for re-review. Should any creatives get disapproved before the start of your seasonal campaign, it is not a requirement that the buyer creative ID change to get the creative re-reviewed. To make use of this feature, use version 1.3 of the REST API.

Make sure your ad creatives are eligible to serve
The last thing you want this time of the year is for your ad creatives to be disapproved. To make sure your campaigns aren’t delayed, make sure to avoid these common policy mistakes:

• Declare the Correct URL/Multiple URLs: please make sure you have declared the URL that the ad leads to. If you have several URLs for the same ad, they all must be declared.
• Creative Borders: On all .gif and .swf ads with partially black or white backgrounds, you must add a visible border of a contrasting color to the majority background color of the ad.
• Content Violations: Remember that Ad Exchange is “family-safe” content only. Therefore, ads that are classified as “limited family safe”, “non-family safe”, and “adult” are not allowed (unless you are participating in the Restricted Category Beta for Alcohol).
• Fourth Party Calls: if you use fourth-party vendors, please make sure they are certified by Google. You can check which vendors are certified and which need to be declared here.
• Over-animation: Please make sure your total animation time does not exceed 30 seconds. For looping or repeating animations, the total combined interval time can not exceed 30 seconds. After an animation has stopped, it cannot restart. Read the full policy here.

Review the AdX Buyer Program Guidelines and Ad Exchange Policies and Enforcement Help Center page for additional details.

Ensure your bids make it to the auction (RTB buyers only)
Each bid response submitted to Ad Exchange undergoes a screening process before it can enter the live auction. During this process, your bid may be filtered out by Google, the publisher, or during the actual auction for many different reasons.

To ensure your bid is not filtered, remember to always review the following:

1. Disapproved ads in the snippet status report
2. Excluded dimensions in the publisher settings report
3. Publisher’s min CPM requirement in the bid request

You can read more about post-filtered bids in our developer blog.

As part of your preparation for a smooth running seasonal campaign, make use of the new RTB Dashboard - a tool designed to bring greater transparency to you, as a buyer, and help you refine your bidder to produce more efficient bidding and better results for your campaigns. With RTB Dashboard, you have the ability to review the “RTB insights” section which helps you understand which bids are being filtered out and why.

Plan ahead to make the end of year a success
Nobody wants to start the new year with an unexpected surprise. So, after checking that your ad creatives are approved, make sure your campaigns continue into the new year by reviewing the items below:

• Campaign End Date: Make sure you’ve set correct campaign end date set. You don’t want to come back from the holidays to find your campaigns switched off by mistake because the end date was set to the default date, 12/31/12.
• Budgets: Take some time to review campaign budgets before heading out to that holiday party. CTRs remain high throughout these festive times and into the new year and it’s a good idea to plan ahead to ensure budgets don't run out early.

Need help over the holidays?
Hopefully everything goes as planned this holiday season, but if any emergencies like UI outages or major drops in RTB traffic come up, our U.S. support teams will be on hand to make sure you’re back up and running. Please note the U.S. Google offices will be closed on the following days:

• Tuesday December 24th
• Wednesday December 25th
• Tuesday December 31st
• Wednesday January 1st

If you follow these best practices, you can focus on other initiatives on your wishlist (e.g. mobile, video).

Posted by the Ad Exchange Team

Last year, we introduced the Ad Exchange Real-Time Bidding Optimization Series on the developer's blog with our first post on post-filtered bids.

Today, we’ll drill down into one of the filtering reasons: Auction filtered.

We’ll revisit the definition of auction filtered bids, review the main reasons for being filtered from the auction, and the steps you can take to ensure your ads will not be filtered.

Auction Filtered: After the bid response passes the Google and publisher checks, it makes its way to the auction. However, the bid may not win the auction due to one of the following:

1. Outbid in auction
2. Bid was below the minimum threshold
3. Not allowed in private auction

1. Outbid in auction means that your bid was lower than a competitor’s bid and since AdX uses a second-price auction model, the highest bid wins the auction and pays the price of the second highest bid. One way to make sure you are bidding at a competitive price is to implement the new RTB feature for AdX, Real-time Feedback. The feature will give you feedback on auction results in near real-time, including (1) why your bid was filtered (e.g. disapproved ads, product/sensitive category exclusion, outbid in auction, etc.) and (2) what the winning bid price was (if you lost in the previous auction). We include this information in subsequent bid requests sent to your bidder. You can use this information to improve the efficacy of your own bidding by reducing the number of times you are outbid. The creative_status_code field in the proto buffer will reveal the filtering reason. For example, the creative_status_code field may be 79, meaning you were ‘outbid in auction’, whereas 80 and 81 mean your ‘bid was below the minimum threshold’ and ‘not allowed in private auction’ respectively. You can review a complete list of filtering reasons in the creative-status-codes.txt dictionary file.

2. Bid was below the minimum threshold means that your Max CPM (max_cpm_micros in your BidResponse) was lower than the publisher’s min CPM. Specifically, the bid response contained a max_cpm_micros value that was less than the publisher’s minimum_cpm_micros value. Ensure that your bidder understands the minimum_cpm_micros required by the publisher per bid request and bid at or higher than this price if you are interested in the impression, or submit an empty bid if you are not interested in the impression. The minimum_cpm_micros value is listed in the AdSlot section of the bid request. You can review more details in the realtime-bidding-proto.txt file.

3. Not allowed in private auction means that your bid is being filtered for a preferred deal or private auction impression that you were not allowed in. Using the Preferred Deals UI, view Open Offers and consider negotiating your own deal or private auction with publishers of interest.

New! RTB Dashboard is a tool designed to bring greater transparency to you, as a buyer, and help you refine your bidder to produce more efficient bidding and better results for your campaigns. With RTB Dashboard, you have the ability to review the “RTB insights” section which helps you understand which bids are being filtered out and why:

So, what can you do with the information available in ‘Insights’? Two of the most common auction loss reasons and solutions are:

• Outplaced - use real time feedback to analyze which impressions you get outbid on and increase your bid intelligently. The bid request contains the second price cpm in micros of your account currency if your bid won the auction, or the winning bid that must be exceeded to win the auction if your ad did not win. This is only set if your bid participated in the auction.
• Below CPM - Inspect the minimum_cpm_micros field in the bid request and ensure you’re bidding at or above this amount.

For both auction loss reasons you may want to find out more. Under the ‘Action’ column a ‘Details’ link allows you to view the auction loss count aggregated by either publisher domain or your creative ID for the specific auction loss reason.

Have questions or feedback? Reach out to your Ad Exchange account team.

Posted by the Ad Exchange Team

In our previous blog posts, we discussed post-filtered bids and disapproved ads. In those posts we recommended integrating tools such as the Creative REST API, Snippet Status Reports, and Publisher Settings File into your bidder as best practices to improve the efficiency of your application.

Today, we'd like to share how to integrate these tools into your setup.

Why implement these tools into your bidder?

As a recap, here are our suggested best practices and why we feel they are beneficial for your bidder:

The Creative REST API is a proactive measure that provides methods for submitting a creative for verification, for checking the status of a creative that you have submitted, and for retrieving a list of all your active creatives before bidding on the creative ad. By using the Creative REST API to submit and manage your campaign creatives, you’re able to ensure that your bidder is better prepared to bid with an approved creative.

If you are unable to implement the Creative REST API, the Snippet Status Report can also help you review and determine the exact reason for which your ad was disapproved. The snippet-status-report-proto.txt file lists all the issues described in the section of the report. The snippet status report will also show ads that are approved or have not yet been checked by our verification system.

Publisher Settings File is a list of exclusions set by AdX publishers that will block bids from winning the auction for their inventory. Buyers should take note of and adhere to these publisher requirements. By leveraging the Publisher Settings File, your bidder can ensure it does not bid on an ad that will be filtered out of the AdX auction due to an exclusion. By only bidding on eligible impressions, you can avoid wasting bids.

How to incorporate these tools into your bidder?

Below is a sample visual representation of how you can integrate the Creative Rest API, Snippet Status Report and Publisher Settings File into your bidder’s logic to maximize the efficiency of your bidder:

1. Upload creatives from your ad repository/server using the Creative REST API.

2. Use the Snippet Status Reports or Creative REST API to periodically find the creative status (APPROVED, DISAPPROVED, NOT_CHECKED). Update the creative status in your ad repository/server. To avoid wasted bid opportunities, ensure that your bidder only returns BidResponses with APPROVED creatives. Creatives with DISAPPROVED or NOT_CHECKED status will not be eligible to compete in auction. Read more about post-filtered bids.

3. Use categorization data from the Snippet Status Reports or Creative REST API to help match creatives during targeting and avoid getting post-filtered. We use two types of categories, product and sensitive.

Product categories (ex. Banking, Real Estate, or Sports) will be identified by a detected_product_category.
Sensitive categories (ex. Dating, Politics, or Religion) will be identified by a detected_sensitive_category.

If a publisher has category exclusions, they will appear in BidRequests within the excluded_product_category and excluded_sensitive_category fields. Your bidder should honor these category exclusions by ensuring that it only returns BidResponses with creatives that are not categorized in an excluded_product_category or an excluded_sensitive_category.

4. Periodically pull the Publisher Settings Files to incorporate publisher exclusions into your targeting engine to minimize the chance of returning creatives that will be blocked by publishers. It might not be feasible to load all publisher data, but you may consider concentrating on the top N publishers on which your creatives run or publishers that you explicitly target. Publisher Settings Files contain valuable information such as excluded_attribute, excluded_product_category, excluded_sensitive_category and excluded_url. See the complete proto file.

Note: In order to reduce the size of the bid request, BidRequests do not contain excluded_url. Therefore, the only way your bidder will know what advertiser URLs the publisher is excluding is through the Publisher Settings Files. Your bidder should honor URL exclusions by ensuring that it only returns BidResponses with creatives that declare click_through_url’s that are not excluded by the publisher.

Have questions or want to enable any of the tools mentioned? Reach out to your Ad Exchange account team.

Posted by the Ad Exchange Team

In December, we introduced the Ad Exchange Real-Time Bidding Optimization Series on the developer's blog with our first post on post-filtered bids.

Today, we’ll address one of the common causes: Disapproved ads.

We’ll revisit the definition of disapproved ads, review the main reasons for disapproval, and the steps you can take to ensure your ads will not be disapproved.

What is a disapproved ad?
A disapproved ad is an ad in which the bid response is filtered out due to one or more reasons. To determine the reason for which your ad was disapproved, review your snippet status report. The snippet-status-report-proto.txt file lists all the issues described in the <DisapprovalReason> section of the report.

Note: As a proactive measure, the creative REST API provides methods for submitting a creative for verification, checking the status of a creative that you have submitted, seeing disapproval reasons for your submitted creatives, and retrieving a list of all your approved creatives before bidding on the creative ad.

What are the main reasons for an ad being disapproved?
Most disapprovals occur when ads fail to comply with the DoubleClick Ad Exchange policies for content and creative, or data and third-party ad serving.

Content & Creative: DoubleClick Ad Exchange reserves the right to disapprove ads in breach of the content and creative policies outlined in the Google AdWords Advertising Policies and to suspend entire accounts for certain violations. Here are the most common content and creative policy violations that may cause your ad to be disapproved:

Incorrect Destination URL Declaration means the actual destination URL does not match the declared destination URL.

Length of Image Animation means the length of the image animation is longer than allowed.

Adult Image/Video Content means the ad contains adult images or video content.

Landing Page Disabled means the landing page does not conform to Ad Exchange policy.

Pop-Up means the ad causes a pop-up window to appear.

Media Not Functional means that something is wrong with the creative itself. Please preview your third-party ad tag in a browser to make sure it is working properly.

Broken URL means the click through URL does not work properly. Please test your third-party ad tag in a browser to make sure it is working properly.

Data and Third-Party Ad Serving: In order to run ads on the Google Display Network through the DoubleClick Ad Exchange, buyers must follow the requirements for third-party ad serving. Here are the most common data and third-party ad serving violations that may cause your ad to be disapproved:

Problem with Click Macro means there is a problem with the way the click macro is used.

Invalid Fourth-Party Call means the ad makes a fourth-party call to a vendor that is not approved. See this list of vendors who are allowed to be on the DoubleClick Ad Exchange platform.

Usage of Locally Shared Objects (LSO) means the creative sets an LSO object.

No Border means the ad had a white or black background and no border.

Blank Creative means the ad serves a blank creative. Please preview your third-party ad tag in a browser to make sure the creative is loading properly.

Incorrect Ad Technology Declaration means the ad technology declaration is not accurate.
Google has an approved list of vendors who are allowed to be on the DoubleClick Ad Exchange platform.

Use of Raw IP means the ad contains a URL that uses a numeric IP address for the domain.
Please make sure to use the domain, and not the IP address.

Remember, each disapproved ad that is filtered out is a valuable impression you’ve missed out on. Therefore, always:

1. Leverage the creative REST API to submit creatives for verification, check the status of a creative that you have submitted, see disapproval reasons for your submitted creatives, and retrieve a list of all your approved creatives before bidding on the creative ad.
2. Review any disapproved ads in the snippet status report.

Have questions or want to enable the creative REST API or review your snippet status report for your disapproved ads issues? Reach out to your Ad Exchange account team.

Posted by the Ad Exchange Team

Today we’re launching the Ad Exchange Real-Time Bidding Optimization Series on the developer's blog to share updates, best practices and optimization tips with AdX developers. Our goal is to provide knowledge to our clients to help keep their proprietary bidders healthy, successful and evolving. To start things off the first blog post in the series covers post-filtered bids.

When using Ad Exchange, one of the most important factors is ensuring that your bid response is participating in the auction. If the bid response makes it to the auction, it has a better chance at improving win rate: percent of impressions won out of all bids submitted. However, it’s possible that some of your bids may not be entering the auction due to bid response filtering.

We’ll review bid response filters later in this blog entry: what they are, and how to ensure your bid responses are not filtered out. But before we dive in, let’s define bid response filtering.

What is bid response filtering?
Each real-time bid that is submitted to Ad Exchange undergoes a screening process before it can enter the live auction. During this process, your bid may be filtered due to publisher exclusions or incorrect use of the RTB BidResponse protocol. Among other things, we check for malformed URLs, ads that fall into a category the publisher has blocked, or incompatible elements in the bid response (e.g., a buyer who has declared an expandable ads technology vendor, but who has not actually trafficked an expandable ad).

Here is a basic visual representation of the process a bid goes through, including bid response filtering, to make it into the auction and win:

What are the main bid response filters?
As the bid response progresses through the process illustrated above, it might be filtered out by Google, the publisher, or during the actual auction for many different reasons. Each of the main bid response filtering mechanisms are discussed in detail below.

Google Filtered: First, Google will review the bid response to determine if both the ad creative and bid are compliant with Google’s policies and standards. Here are the most common reasons your bid response will be filtered out by Google:

Disapproved ad means that the ad in the bid response was disapproved due to one of several reasons. In order to determine the exact reason for which your ad was disapproved, review your snippet status report. The snippet-status-report-proto.txt file lists all the issues described in the <DisapprovalReason> section of the report. This is usually the culprit when your bid has been filtered out!
Note: The snippet status report will also show ads that have not been checked and are filtered.
And as a proactive measure, the creative REST API provides methods for submitting a creative for verification, for checking the status of a creative that you have submitted, and for retrieving a list of all your active creatives before bidding on the creative ad.

Max CPM is 0 or negative means the bid (max_cpm_micros) set in the bid response was 0 or a negative value. Change the bid to a positive value. If you are not interested in bidding for a particular bid request, be sure to return an empty bid response with the processing time set, not just an empty (0 bytes) response.

Click through URL is too short means for bid responses where html_snippet is set, the click_through_url is less than eleven characters. For example, the URL http://a.b would be too short. Verify that your click_through_url is more than eleven characters.

Click through URL is unparsable means the click_through_url in the bid response is malformed and cannot be parsed. For example, 'http://myad' will not work, since the domain name has to include at least one '.' (period).

Incorrect use of bid response protocol means that there is an improper setting in the BidResponse. In order to determine the proper protocol, review Building the Response and the realtime-bidding.proto.txt file. The realtime-bidding.proto.txt file defines the appropriate settings that should be included in the BidResponse. Examples of incorrect protocol use include: buyer_creative_id not set in the BidResponse or setting both the html_snippet and video_url fields in the BidResponse (only one should be set).

Poor landing page quality means that the landing page was disapproved by Google. Review the landing page of the ad to make sure the website provides a good user experience as measured by:

• Relevant and original content: The site needs to be relevant and have original content, it should not copy text from another site. 
• Transparency: The site needs to be very clear on what the business model is and what the information will be used for. 
• Ease of navigation: The site should be easy to navigate and it should not be intrusive to users. 

Publisher Filtered: Once the bid makes it through Google’s review, it is reviewed again to ensure it adheres to the publisher’s requirements. For each piece of ad inventory, the publisher can add exclusions. Here is a list of the main reasons a bid could be filtered by a publisher:

Sensitive category URL excluded means that the click_through_url in your bid response was either detected or declared with a sensitive category which was excluded by the publisher for this request. In order to determine the sensitive categories for each publisher, you will need to review the excluded_sensitive_category field in the bid request and the publisher settings report. The publisher-settings-proto.txt file lists the categories that are excluded. Your snippet status report will show the sensitive category with which your snippet’s click_through_url was classified by Google.

Product category URL excluded means that the click_through_url in your bid response was either detected or declared with a product category that has been excluded by the publisher for this request. In order to determine the product categories prohibited by each publisher, review the excluded_product_category field in the bid request and the publisher settings report. The publisher-settings-proto.txt file lists the categories that are excluded. Your snippet status report will show the product category with which your snippet’s click_through_url was classified by Google.

Declared vendors excluded means the bid response has declared a vendor_type which has been excluded by the publisher’s ad slot in the bid request. In order to determine the vendor types allowed by each publisher, review the allowed_vendor_type field in the bid request and the publisher settings report. The publisher-settings-proto.txt file will show you the allowed vendors.

Declared attributes excluded means the bid response has declared attributes which were excluded by the publisher’s ad slot in the bid request. In order to determine the allowed_vendor_type per publisher, you will need to review the excluded_attribute field in the bid request and the publisher settings report. The publisher-settings-proto.txt file will list the excluded attributes. 

Auction Filtered: After the bid response passes the Google and publisher reviews, it makes its way to the auction. However, the bid may not enter the auction if it was lower than the publisher’s required min CPM. If this is the case, a ‘Max CPM is lower than the publisher’s min CPM’ message will be generated.

Max CPM is lower than the publisher’s min CPM means the bid response contained a max_cpm_micros value that was less than the publisher’s min_cpm_micros setting. Ensure your bidder reviews the min_cpm_micros required by the publisher per bid request in order to bid properly on the impression. The min_cpm_micros value is listed in the AdSlot section of the bid request, you can review more details in the realtime-bidding-proto.txt file. 

Remember, each bid response that is filtered out is a valuable impression you’ve missed out on. Therefore, always review the following:

1. Disapproved ads in the snippet status report 
2. Excluded dimensions in the publisher settings report 
3. Publisher’s min CPM requirement in the bid request 

Have questions or want to get a report for your bid response filtering issues? Reach out to your Ad Exchange account team.

Posted by the Ad Exchange Team

We value our partnership and want to notify you of an important upcoming change for third party ad serving (3PAS) to Google owned and operated properties, including YouTube.

To provide greater security and ensure the privacy for our users, all ads, whether display or in-stream video, that are served to signed-in Google users must be Secure Socket Layer (SSL) compliant no later than January 15, 2013. After this date, the amount of inventory available on Google properties to non-SSL compliant buyers will be limited.

KEY REQUIREMENTS

• DoubleClick Ad Exchange (AdX) buyers must declare that a 3PAS ad is SSL-compliant via Real-Time Bidding (RTB) in the BidResponse or the AdX UI 
• All 4th-party calls to other technologies must be made from SSL-compliant vendors that have been certified by Google 
• All video companion banner ads must be SSL-compliant 

Note that if an ad is declared as SSL-compliant but makes any non-SSL-compliant responses, the ad will be disapproved.

SUMMARY OF CHANGES
RTB Protocol
To identify inventory requiring an SSL-compliant response, the excluded_attribute field (BidRequest.AdSlot.excluded_attribute) will include the value 48, which represents the RichMediaAdsVendor: RichMediaCapabilityNonSSL creative attribute from the dictionary file creative-attributes.txt. If the creative attribute value 48 is not present in the excluded_attribute field, both SSL-compliant and non-SSL-compliant ads can be returned. You should use this field to ensure that your ad serving technology responds properly to bids. This field will be present in BidRequests for both display and in-stream video ads.

User Interface
For 3PAS ads, there will be an additional checkbox in the Ad Exchange UI to declare that an ad is capable of serving both SSL and non-SSL ads. This checkbox will be available soon for both display and in-stream video 3PAS ads and will be un-checked by default.

For non-3PAS ads, there are no changes in the UI.

In-Stream Video
In addition to the above changes, there are specific changes that must be made for In-Stream Video ads to be eligible for SSL inventory:

• VAST: All VAST (Inline and Wrapper) URLS must serve over HTTPS when the ad request is made with HTTPS. 
• Media and tracking URLs: All tracking pixels and creative assets (including media files) must serve over HTTPS when the VAST URL is served over HTTPS. 
• Companion ads: All Companion banners, including any 4th-party calls, must serve over HTTPS when the VAST URL is served over HTTPS.

We understand that this change places additional burden on your team and we will do our best to help you through this process. In the interim, please do not hesitate to contact your Google technical account manager with any questions.

Posted by the Ad Exchange Team

Update: Ad Exchange will be affected by the downtime as well. Please see below for details.

As previously mentioned, we have an upcoming AdWords, Ad Exchange, and DFP service outage. This will occur on Saturday, September 22 -- AdWords, Ad Exchange, and DFP systems will be unavailable from approximately 10:00 am to 8:00 pm Pacific Time (17:00 Saturday to 03:00 Sunday GMT) due to system maintenance.

AdWords
During this time, your campaigns will continue to run as usual (with the settings you established as of 10am PST), but you won’t be able to make SOAP API calls or download reports. Requests to the AdWords API will fail with an HTTP 50x error during the maintenance window. Please also keep in mind that any automated rules scheduled during this time will not run and AdWords scripts will not execute during this period. We encourage you to verify your campaign settings prior to the outage.

Ad Exchange
During this time, your ad serving will continue to run per changes made prior to downtime period, but you will not be able to make API calls to Ad Exchange Buyer SOAP API. On Ad Exchange Buyer REST API, only the Direct Deals related API calls will be affected. For the Ad Exchange Real-Time Bidding Protocol, you will not be able to make changes to pre-targeting settings, everything else should continue to run as usual.

DFP
As mentioned above, ad serving will continue to run per changes made prior to the downtime period. If you use the audience feature in your network, any API call to the AudienceSegmentService service will fail with a SegmentError.UNEXPECTED_ERROR error. Also, if you target any audience segments in your line items, any calls to LineItemService, ForecastService, or LineItemCreativeAssociationService that involve those line items will fail.

We apologize for any inconvenience, and appreciate your patience as our engineers work to keep AdWords, Ad Exchange, and DFP running smoothly.

 - Kevin Winter, Ads Developer Relations Team

The Ad Exchange Team is excited to make this set of resources available to our developer community. Below you’ll find new and better ways to work with the Ad Exchange. If you have any questions or feedback, please contact us via the forum.

New website

• Built on top of Google’s new developers platform developers.google.com, we’ve created a new site for our community. There you’ll find docs for the real-time bidding (RTB) protocol, the REST API and the SOAP API. Plus, we’ve revamped the docs to make them easier to use and understand. 

Access to the Ad Exchange REST API

• This API gives you the ability to manage your RTB account configurations, submit creatives and list direct deals. Contact your technical account representative to set up access to the API. Then, try it out before you write a line of code, using the API explorer. 

Client library support and code examples in major programming languages 

• Trying out the client libraries first might save you a lot of time compared to coding directly against the APIs. Also, check out our code examples in your preferred programming language for both the SOAP and REST APIs. 

Access to the Ad Exchange Buyer API’s Forum 

• The Ad Exchange Buyer APIs Forum is a Google-monitored environment for public discussions where you can ask - and, if you like, answer - questions regarding the REST and SOAP APIs.

 - David Torres, Ad Exchange Team

On April 2, 2012, we’ll be rolling out a number of changes to the Ad Exchange real-time bidding protocol. Although we've distributed communication on each of these topics individually, we wanted to provide a final overview of the upcoming changes. And a reminder: Although some of these may require action on your part, we expect all of them to save you time and energy in the long run.

Trading Locations
As you may know, your bid requests have been coming from a variety of data centers throughout the world. Occasionally we change the set of data centers used, which can cause headaches for your bidder. To reduce complexity and increase predictability, we've announced a set of four new, fixed trading locations: West Coast U.S., East Coast U.S., Europe, and Asia. As of April 2, 2012, these locations will become the standard, and you should expect all callouts to come from these locations.

New Bid Response Deadline
Our current bid response deadline of 120ms is a combination of 40ms “network time” and 80ms “think time.” Because the new trading locations schema reduces network time by stabilizing the origin of callouts, we are lowering the bid response deadline from 120ms to 100ms beginning on April 2, 2012.

While this is a shorter time window, your 80ms think time should not be affected. In fact, you can actually increase your think time by strategically locating your data centers near the four fixed trading locations.

Buyer Creative ID Mandatory
Starting on April 2, 2012, we will require all real-time bid responses to contain a new field: buyer_creative_id, which lets you set a unique identifier for each new ad creative you submit. Moving forward, all reports on the status of your creatives will be based on this ID. The ID also enables us to investigate and troubleshoot issues much more quickly.

From April 2 onward, any bid responses without the buyer_creative_id field will be rejected. If you are ready to begin using this field prior to the deadline, contact your Technical Account Manager.

Deprecated/Renamed Fields
The following fields in the bid request have been deprecated and will no longer be filled starting April 2, 2012:

• protocol_version
• campaign_id
• excluded_click_through_url
• company_name

Please note that excluded URLs may still be accessed via publisher_settings files.

Additionally, the MobileApp submessage has been renamed to Mobile. The following fields that are part of the newly renamed Mobile submessage have been deprecated and will no longer be filled starting April 2, 2012:

• app_name
• company_name

Vendors
Starting on April 2, 2012, we’ll no longer be sending whitelisted vendors or GDN-approved vendors in the bid request. Check out this post for more details.

If you have questions about any of these changes, please reach out to your Ad Exchange Technical Account Manager.

Posted by the DoubleClick Ad Exchange Team

In April 2012, we will be making two changes to the allowed_vendor_type field of the Ad Exchange real-time bidding protocol. Before describing the upcoming changes, let’s review how to use technology vendors on the exchange.

Ad Exchange vendor policies

One of the benefits of buying on the DoubleClick Ad Exchange is the ability to use technology vendors for ad serving, research, remarketing and more. To protect Ad Exchange publishers, we certify vendors before they’re allowed to run on the exchange. And once they’re certified, we divide them into two categories, outlined in our Help Center:

1. No Declaration Required: Vendors that are whitelisted to run across the exchange, and therefore do not need to be declared in a bid response.


2. Declaration Required: Vendors that publishers are permitted to block, and therefore must be declared in a bid response.

Because Ad Exchange buyers have access to sites in the Google Display Network (GDN), the GDN runs an additional certification process to determine which vendors may run on their network. Therefore, there is a third label applied to vendors:


3. GDN Allowed: Vendors that are permitted to run on the Google Display Network. Note that categories 1 and 2 still apply to this subset; that is, some GDN Allowed vendors require declaration, and others don’t.

GDN Allowed vendors are listed in the GDN Requirements for 3rd Party Ad Serving. On this page, navigate to Vendors list (global) under the Requirements on the Google Display Network through the DoubleClick Ad Exchange section. Vendors marked with a + sign are bucket 2, Declaration Required.

An overview of the changes

In April 2012, we will make two simplifications to the allowed_vendor_type field of the Ad Exchange real-time bidding protocol.

1. Removal of No Declaration Required vendors: In the bid request, the allowed_vendor_type field will only contain vendors from category 2, Declaration Required; you will no longer see any bid requests with vendors from category 1. Accordingly, your bid responses should only contain vendors from category 2 (though your response will not be rejected if it contains a category 1 vendor). We have updated our vendors.txt file to include only the vendors that need to be declared.


2. Removal of allowed_vendor_type for GDN requests: Because every GDN site has the same set of allowed vendors, we will no longer include allowed vendors in bid requests for GDN sites (denoted by seller_network: “GCN”, soon to be updated to “GDN”). However, if the vendor you’re using falls into the Declaration Required bucket, you must still include it in your bid response. We have listed these vendors - those that are allowed on the GDN, and won’t appear in bid requests, but still require declaration - in gdn-vendors.txt.

As always, please reach out to your Google account team with any questions about this change.

Posted by Eileen Duffy, Ad Exchange Trainer