[go: nahoru, domu]

The Ad Exchange Seller REST API is deprecated. Existing API clients should migrate to the DoubleClick for Publishers API before July 26, 2018. After this date, all requests to the Ad Exchange Seller REST API will return errors.

This migration guide provides instructions for getting started, as well as a mapping of each Ad Exchange reporting metric to its equivalent in the DFP API.

For more details about reporting in the DFP API, see the reporting guide.

For general assistance with the DFP API or your migration, reach out on our developer forum.

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.

The Ad Exchange Seller REST API is being deprecated as of October 26, 2017. No new API clients will be supported after this date. Existing API clients will need to migrate to the DoubleClick for Publishers API before July 26, 2018. After this date, all requests to the Ad Exchange Seller REST API will return errors.

What action is required

Current Ad Exchange Seller REST API users will need to migrate to the DoubleClick for Publishers API before July 26, 2018. This migration guide provides a mapping of each Ad Exchange reporting metric to its equivalent in the DFP API.

For more details about reporting in the DFP API, see the reporting guide.
For general assistance with the DFP API or your migration, reach out on our developer forum.

Why this is happening


As a part of our effort to provide a unified tool to manage your ad business and monetize your inventory, the DoubleClick for Publishers API now supports all of the features of the Ad Exchange Seller REST API. The DFP API is more robust and has more frequent updates.

What isn't changing
Users will not need to create new accounts. All Ad Exchange Seller users already have a DoubleClick for Publishers account.

No data is changing. The only change is how you programmatically access that data.

We’ve just released v2beta1 of the DoubleClick Ad Exchange Buyer REST API. Unlike previous releases, this is an early access open beta that only allows three new resources—Clients, Invitations, and Users. In order to access this version, new users will need to go to the API Manager in the Google Developers Console and enable “Ad Exchange Buyer API II”; current users will have this enabled automatically. For access to existing resources such as Accounts or Creatives, you should continue using v1.4.

The new resources available in this release allow you to add and manage clients programmatically rather than through the Ad Exchange UI. A Client represents an advertiser, agency, or brand that can view, negotiate, and/or approve deals in areas of the Ad Exchange UI related to the Marketplace. You can send Invitations on behalf of a Client to add Users—the individuals accessing the UI as the Client.

To get even more familiar with these new resources, check out the Client Access Overview. There are some subtle differences when using the client libraries with this version, so we recommend that you look at our samples for guidance on initializing clients and making API calls. At this time, the Java, PHP, and Python samples have been updated for compatibility with this version and the others are planned for the near future. If you have any questions or feedback related to these changes, feel free to reach out to us at the DoubleClick Ad Exchange Buyer API forums or the Ad Developers Google+ Page.

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.

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.

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.

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.

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.

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.

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: Have questions or feedback? Reach out to your Ad Exchange account 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.

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: 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.

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.

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:

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.

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: 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.

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



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.

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).

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.

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.