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

Today we’re announcing the deprecation of v1 and v1.1 of the DoubleClick Ad Exchange Buyer REST API, both of which are scheduled to be sunset on December 1st, 2014. These versions are becoming increasingly less relevant as we expand on the latest and greatest version of the API—currently v1.3. We recommend that you migrate to v1.3 before this date in order to take advantage of the newest functionality and also to continue having uninterrupted access to the API. If you have not migrated from these deprecated versions by December 1st, calls against the API will return an error response.

The vast majority of users have already migrated to newer versions of the API, but if you’re among the few who haven’t, we expect it to be an easy upgrade because newer versions still support all of the resources you’re familiar with. The only changes that could cause a code break when migrating from v1 to v1.3 are in the Creatives resource; the adgroup_id field was removed and the disapprovalReasons field is no longer a list of strings. You can use the following resources to help you with your migration:

• Release Notes: A listing of all changes between versions of the API.
• Code Examples: Examples demonstrating how to use the client libraries with the most recent version of the API.
• Developer Guides: Guides covering the most recent version of the API.

Of course, if you have any questions or need help with the migration, feel free to reach out to us via the forum or the Ads Developers G+ page.

 - Mark Saniscalchi, DoubleClick Ad Exchange Team

Last year, we posted an optimization series article about auction filtered reasons. The article addressed 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. For information on how the AdX auction works today, please see this Ad Exchange Auction Model article in our Help Center.

Posted by the Ad Exchange Team

As you may know, we announced the release of our new Python client library—googleads—in March, 2014. Since then, we’ve received a lot of feedback that has helped us further improve the library. Given the positive reception we’ve had with googleads, along with the improvements we’ve made to it over the past few months, the time is right for us to give our legacy Python client library—adspygoogle—a proper send-off. The legacy ads APIs Python client library has been deprecated and will be sunset on January 5th, 2015.

Between now and the sunset date, all upcoming API releases will be supported. The legacy client library will no longer be available on GitHub or PyPI after the sunset date. You can continue to use it while supported versions of the APIs are available, but it will eventually become obsolete and won’t be supported if any new issues are discovered. In order to smoothly transition to the new client library and have uninterrupted access to the newest versions of the APIs, we suggest you migrate to googleads as soon as possible. To help you migrate, we’ve prepared a migration guide.

If you discover any bugs, would like to contribute, or have feature requests for googleads, feel free to let us know via the library’s issue tracker. If you have any questions or feedback for us, you can reach us on the Google Ads Developers Google+ page.

 - Mark Saniscalchi, Ads Developer Relations 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

If you are running DoubleClick Ad Exchange Real-Time Bidding campaigns, you can now use the Snippet Status Report Generator to obtain a Snippet Status Report for your creatives. The Snippet Status Report contains the approval status of your creatives, as well as the sensitive and product categorization that Ad Exchange automatically detects. The Snippet Status Report Generator produces reports using the Ad Exchange Buyer REST API.

There are three versions of this report available through the generator: a human readable text format, a binary protocol buffer format, and a spreadsheet-friendly CSV format. The text and protocol buffer version of the report can also be obtained via Google Cloud Storage. The CSV version can be used with spreadsheet programs such as Google Sheets, Microsoft Excel or LibreOffice Calc:

The Snippet Status Report Generator is available on GitHub as a python program. You are encouraged to download it and make modifications to generate reports in your desired format.

If you have any questions or feature requests for the Snippet Status Report Generator, please create an issue on the project’s issues page.

For any questions about the Ad Exchange Buyer API, visit us on the forum or our Google+ page.

- John Qin, Ad Exchange RTB API team

Starting January 1st, 2015, the PHP Ads client library will stop supporting PHP 5.2:

• We will no longer test against PHP 5.2, or fix bugs that only affect PHP 5.2 users
• Newer versions of the library may not work with PHP 5.2

This will impact PHP client library users of the AdWords API, the DoubleClick for Publishers API, and the DoubleClick Ad Exchange Buyer APIs.

PHP 5.2 hasn’t been supported since 2011 and should be upgraded to a current, stable version. Upgrading ensures you’ll receive the latest security updates.

In addition, there are numerous issues when using the PHP 5.2 SOAP client, such as:

• No support for chunked encoding
• Inability to set HTTP protocol version
• Inability to set custom HTTP headers

In particular, custom HTTP headers are required for the DoubleClick for Publishers API starting from DoubleClick for Publishers API v201405 - the OAuth 2.0 access token must be passed via the HTTP headers rather than the URL parameter. In this case, PHP 5.2 users must upgrade in order to use DoubleClick for Publishers API v201405.

As always, if you have any questions, drop us a line on the forums (AdWords API, DoubleClick for Publishers API, DoubleClick Ad Exchange Buyer API) or Ads Developers Google+ page.

- Ray Tsang, AdWords API 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

Whether you’re just starting out with the DoubleClick Ad Exchange Buyer REST API or are working with an unfamiliar client library, our examples will help you get started! Our examples are now on GitHub and have been expanded to cover the following languages:

• C#
• Java
• PHP
• Python
• Ruby

Each of these include documentation to help you get started with the corresponding client library and demonstrate how you can use the Service Account authorization flow with the DoubleClick Ad Exchange Buyer REST API.

If you have any feedback or feature requests for these examples, we’d definitely be interested in hearing about it! Feel free to contact us via the forum or our Google+ page.

 - Mark Saniscalchi, Ad Exchange Team

We’d like to remind you that v201306 of the AdWords API and Ad Exchange Buyer SOAP API are scheduled to be sunset on March 31st, 2014. Start your migration to v201309 now to avoid having your API calls fail on the sunset date. If you are still using ClientLogin, we strongly recommend that you also migrate to OAuth2.

The following will help you to migrate to v201309:

• Announcement blog post for v201309 — includes highlights of v201309
• Release notes — lists every API change and version diffs
• Migration guide — includes a listing of breaking changes between v201306 and v201309
• Client libraries and samples page — updated official client libraries
ClientLogin to OAuth2 migration — detailed guide on OAuth2 implementation

For migration help, contact us on the AdWords API forum or Ad Exchange Buyer API forum. Our Google+ page is also a great resource for keeping up-to-date with the latest announcements and communicating with us.

Mark Saniscalchi, Ads Developer Relations Team

We have moved all our client libraries to GitHub. Here’s a complete list of all our client libraries, with their new locations:

	AdWords and DoubleClick Ad Exchange Buyer	DoubleClick for Publishers	DoubleClick for Advertisers
Java	googleads-java-lib	googleads-java-lib	googleads-java-lib
.NET	googleads-adwords-dotnet-lib	googleads-dfp-dotnet-lib	googleads-dfa-dotnet-lib
PHP	googleads-php-lib	googleads-php-lib
Perl	googleads-perl-lib
Python	googleads-python-lib	googleads-python-lib	googleads-python-lib
Ruby	google-api-ads-ruby	google-api-ads-ruby

We have also moved all Wiki pages and open issues to the corresponding GitHub projects. You can find downloads for a project under its releases page. All future client library releases will be published on GitHub only, so make sure you follow us on GitHub to keep track of new releases and report issues. If you tracked the git repository on code.google.com for a client library, you should update your master branch to point to the GitHub repository instead.

If you have any questions about the client libraries, you can post them on our forums. Check out our Google+ page for client libraries and Ads APIs updates.

- Anash P. Oommen, Ads Developer Relations

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

We've noticed a lot of interest in having the Google Ads APIs Python Client Library made available on PyPI, so we're happy to announce that we've recently added support for it. If you use a tool such as pip, you can now install or update to the latest version of the library with all its dependencies using one simple command, for example:

pip install [--upgrade] adspygoogle

This feature was added based on community feedback, so if you have additional feature requests or a bug to report, feel free to let us know about it by creating an issue on our issue tracker or contacting us on our Google+ page.

- Mark Saniscalchi, Ads Developer Relations

We've recently made several enhancements to version v1.3 of the DoubleClick Ad Exchange Buyer REST API. To make it even easier for buyers to work with the DoubleClick Ad Exchange, our team is improving the functionality of our APIs. Today we would like to let you know about some recent enhancements to version v1.3 of the Ad Exchange Buyer REST API. Below are the details of the new features and stay tuned for more releases over the coming year.

Performance Report Resource

A new resource, performanceReport, has been added. This resource is an improvement on the existing CSV performance reports. You can now use the API to view these reports in JSON format and without having to interface with Google Cloud Storage. These reports are aggregated over 5 minute intervals rather than the 1 minute intervals that the CSV reports use.

Creatives Resource

We’ve improved the creatives resource with the addition of two new sets of fields: filtering reasons and corrections. The filteringReasons are intended to give you better insight into why some snippets have been filtered out of the auction. The Buyer REST API will show you the metrics for the previous day. If you’d like to see longer term filtering metrics, they can be found in the Snippet Status Report.

The corrections field is intended to help you correctly submit creative declarations. We recommend using our corrections as feedback to update your application to submit the right attributes, ensuring your ads serve correctly and on time.

You can always find a listing of the latest updates on our release notes page. Your feedback and questions are welcome on our forum or Google+ Page. Let us know what you think!

- Joseph DiLallo, the DoubleClick Ad Exchange Buyer API Team

Today we’re announcing the v1.3 release of the Ad Exchange Buyer REST API. This release improves the behavior of creative submission by allowing you to resubmit creatives with the same buyer creative ID. If you resubmit a creative with the same ID, the new creative will replace the old and will initiate a new review. Additional information about the changes implemented in v1.3 can be found in our release notes and in the reference documentation.

You can contact us on our forum to discuss these changes, and to keep informed on all of our ads-related technologies, follow the Google Ads Developers Google+ page.

- Mark Saniscalchi, Ad Exchange API Team

Editor's note: repost from the DoubleClick Publisher Blog --Stan Grinberg

With every new plot planted and zombie zapped to bits, the online games industry is changing the way we interact with entertainment. Online games publishers work with us to grow their gaming empires across all screens, from distribution and downloads through to in-game advertising. We’ve also recognized a growing advertiser demand to reach highly engaged games audiences. So we were especially excited to announce two launches at Europe’s Game Developer Conference: we’re launching the TrueView video ad format across our games monetization platforms, and opening up the DoubleClick Ad Exchange to monetize desktop games.

TrueView creates a better ad experience for gamers, and higher monetization for publishers

We all know how important it is to create a gamer-friendly ad experience, which is why we’re bringing one of our most successful ad formats to games: the skippable video ad. TrueView Instream skippable video ads drive a lot of advertiser demand on YouTube, the Ad Exchange, and AdSense for video. Following on Susan Wojcicki’s beta announcement earlier this year, we’re now making TrueView video ads available to all games publishers on AdX, AdSense for games, and select mobile publishers on AdMob. During the beta, we found that TrueView video ads contributed to lower abandonment rates and greater monetization compared to normal instream video ads.

The Ad Exchange posts a new high score with desktop in-game ads

Programmatic channels have revolutionized the way we buy and sell online advertising - and now the launch of in-game ads on the Ad Exchange gives developers the same sophisticated platform to accelerate their monetization efforts. Publishers who have desktop Flash and HTML5 games can now access the global advertiser demand, top-performing ad formats, and finely-tuned controls offered by the Ad Exchange. Advertisers can now specifically target online games’ highly engaged audiences with wide range of gamer-friendly ad formats. These include image and text overlays and interstitials, right through to standard video ads and the skippable TrueView video ad format.

We think that opening the programmatic channel and the rise of gamer-friendly ad formats like TrueView will drive even better monetization for games - which is great news for game publishers, but perhaps not for the zombies.

Posted by
Rebecca Illowsky and Allen Huang
Product Managers, Games Monetization

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