Google Ads Developer Blog: March 2013

Announcing v1.2 of the Ad Exchange Buyer Rest API

Friday, March 29, 2013

We’re pleased to announce that version 1.2 of the Ad Exchange Buyer REST API is now available. This release provides one of the most requested features— detailed creative disapproval reasons. Additionally, it also provides a new field for creatives that can be used to identify the agency providing the creative and a new field for direct deals that can be used to determine whether a deal originated from a private auction. You may view a more specific listing of the changes implemented in v1.2 in our release notes.Detailed Creative Disapproval ReasonsThe Creatives resource now has an improved disapprovalReasons field. Previously, this field provided a list of strings that described the reason for disapproval in a broad context that may have been somewhat ambiguous. Each element of disapprovalReasons now provides two additional fields— reason and details. One can use disapprovalReasons.reason in order to access a categorized reason for disapproval, or use disapprovalReasons.details to retrieve a list of strings describing the disapproval reason in detail.Identify Where Your Ads Came FromPublishers now have greater control over their inventory— e.g. with the new inventory management system, they may set rules that could offer special pricing or limit access to a specific set of creative agencies. With the new agencyId field, you can identify the creative agency that produced the ad with one of the IDs listed in agencies.txt, and consequently gain access to publisher inventory that utilizes these features.Determine Your Eligibility for Private Auction DealsWe’ve given publishers the ability to create private auction deals, which you can read more about in our help center. You can now determine whether you have a fixed price deal or private auction deal by checking the private_exchange_min_cpm field— if it is set instead of the fixed_cpm field, you have a private auction deal. When you bid on ad slots from the publisher offering this deal, you are expected to offer at least the amount provided by this field.You can read more about the new features in the Buyer REST v1.2 documentation. As always, we welcome you to join us on our forum to discuss and ask questions about these changes. To keep informed on all of our ads-related technologies, follow our Google Ads Developers Google+ page.

- Mark Saniscalchi, Ad Exchange Buyer Team

Introducing the AdMob eCPM Floor Beta

Wednesday, March 27, 2013

Today, we’re giving AdMob developers more control over the value of ad impressions served to their apps. The AdMob eCPM Floor beta allows developers to set a minimum CPM they’d like to receive for each ad. The beta is available to AdMob developers who are using AdMob Mediation.

How does this work? Advertisers bid to show their ads on apps in the AdMob network, and an auction is run for every impression to determine the winner. We predict what the ‘expected CPM’ (eCPM) of that ad impression will be. The developer sets a minimum eCPM and we will only serve ads to their app that meet or exceed that level. For example, if a floor of $1.25 is set, we’ll only show ads with an eCPM of $1.25 or more. When choosing a floor value it’s important for developers to look at their own reporting and determine a value that’s relevant to them.

Here are a few details to know when taking part in the beta:

Make sure the eCPMs that are set for other ad networks are accurate.
We don’t guarantee the final value of the eCPM, since we don’t know if a user will click on the ad.

Developers who use the beta have the option of setting just one network line item in their mediation stack which uses the eCPM floor. Or, they can have two network line items, one that uses the eCPM floor and one without, so they can continue to fill impressions at their current fill rate. Setting the eCPM floor at a very high value will likely lead to a decrease in the fill rate.

Find setup instructions in the AdMob Help Center here under the article titled ‘Allocate traffic by eCPM’.

Posted by: Vishay Nihalani, Product Manager, Google

Changes to Content Bidding

Thursday, March 21, 2013

We’re changing the way that bidding works for the display network, by removing implicit ordering and introducing something more simplistic. You can migrate your AdGroups now or allow them to be automatically migrated for you. But before we can explain the new system, let’s take a look at what we’ve got now.

Historically, bidding on the display network has relied on implicit priority orders to determine how to use the criteria added to an AdGroup.

In the current system, criteria-level bid overrides an AdGroup default bid. But since the display network supports up to 6 dimensions of targeting, we often need to pick one of many possible bids to use for a given impression. To do so, we use the following order:

Placement (most specific)
Age
Gender
Topic
Interests and remarketing list
Display Network (AdGroup-level)
Keyword
Default AdGroup Bid (least specific)

to choose which value to use. If a matching placement has a bid, we use that. If not, we look for a matching Age bid, etc. If we get to User Lists/Interests and still have not found a bid override, we look for an AdGroup-level “Display Network Bid”. If that also doesn’t exist, then we take a Keyword bid if there is one. Finally, if we still haven’t found a bid to use, we use the default AdGroup bid.

For further information, see how bids are used on the display network.

Explicit Content Bid Dimension
We will be replacing the implicit order with a single display bid override dimension per AdGroup. Ads serving on the display network will honor bids from that dimension and ignore any bids that may exist on other dimensions. We will use this same override dimension for URL overrides - serving will honor urls from the display override dimension, and ignore urls from any other dimension.

In the new implementation, you will be able to explicitly specify which bid dimension will be used per AdGroup. You can set this by using the new object: BiddingStrategyConfiguration, and the new attribute on the AdGroup object: contentBidCriterionType, both are modified through the AdGroupService. For more information on the new implemenation, please see this guide on Bidding.

Migration
With the introduction of AdWords API version v201302 you’ll be able to manually migrate your AdGroups to take effect as you have been used to with the existing implementation. If you chose not to set these on existing AdGroups, however, for the duration of the migration period, things will continue with the existing order. After the migration period, we will automatically select the most appropriate dimension for each of your AdGroups.

To manually migrate your AdGroups, or to configure new AdGroups, you need to set the contentBidCriterionTypeGroup to the desired CriterionTypeGroup. You can then add new Bids using the BiddingStrategyConfiguration, that can then be selected at a later time.

Please note, by setting the contentBidCriterionType, the AdGroup will be marked as migrated.

Once the manual migration period has ended, those AdGroups that have not been migrated will be automatically migrated to the new structure. The automatic migration will select the contentBidCriterionTypeGroup, for un-migrated AdGroups, based on the existing method of prioritization. All automatically migrated AdGroups can continue to be edited through the API.

Once the automatic migration is complete, the old system of bidding will be retired and all AdGroups will honour the new bid dimension system. Also, once an AdGroup has a contentBidCriterionType, all subsequent changes to the effective bid dimension should be done through the same field.

Reports
With these changes, comes a new report, the PLACEMENT_PERFORMANCE_REPORT which will contain all the information about manual placements. We strongly recommend using this report for queries regarding placement performance, moving forward.

There will also be changes to the AUTOMATIC_PLACEMENTS_PERFORMANCE_REPORT and URL_PERFORMANCE_REPORT to better match the AdWords website.

- Paul Matthews, AdWords API Team

4 days left to migrate out of AdWords API v201206

Thursday, March 21, 2013

On March 25, 2013, we will be sunsetting version v201206 of the AdWords API.

Calls made using this version will not longer work after March 25th. It is therefore critical that you migrate to a newer version for your applications to run without interruption.

We encourage you to use the following resources for a successful migration:

Review the v201302 release notes.
Make sure you’ve made the essential changes laid out in the v201209 and v201302 migration guides.
Review the resources in the AdWords API client libraries.
Attend the office hours sessions, to get face-to-face Q & A sessions.
Make sure your contact information is up to date in your My Client Center account.
Post questions on the forum.
Subscribe to our Google Plus page for news and announcements.

- David Torres, AdWords API Team

Device column available in Click Performance Report

Wednesday, March 20, 2013

We recently exposed the Device column in the Click Performance Report. The Device column can have TABLET, HIGH_END_MOBILE or DESKTOP as its valid values. This is a segmentation column, so requesting it will prevent zero impression rows from being returned. If you have migrated to Enhanced Campaigns, then this column can be useful in finding out how your ads performed on various platforms, and adjusting your mobile bid modifier accordingly.

If you face any issues with the above changes or have any questions about this feature, you can ask us on our developer forum, or at the upcoming GDL Office Hours with the Developer Relations team.

- Anash P. Oommen, AdWords API Team

DFA API v1.18 Sunset Date Pushed Back

Tuesday, March 19, 2013

The sunset of DFA API version v1.18 has been pushed back to April 16th, 2013. This version of the API has been deprecated since November, 2012 and was previously scheduled to be retired on February 28th, 2013.If you’re still using v1.18, please be sure to update your applications before April 16th. Our release notes will help you identify differences in v1.19, the most important one being the necessity to use HTTPS connections. We are available on our forum to help you with any questions you have.

- Joseph DiLallo, the DFA API Team

Deprecation of the old Java library for AdWords and DFP APIs

Monday, March 18, 2013

As previously announced, the new Java client library for the AdWords and DFP APIs is now available. As of the v201302 release of the AdWords and DFP APIs, the old Java client libraries have been deprecated.

With the deprecation:

Support for new API releases will be added until the end of 2013.
New feature requests won’t be accepted.

We strongly encourage you to migrate to the new Java library, which has better coverage of important features such as OAuth 2.0 and Maven.

You can check out the migration guide that describes procedures for migration along with best practices. Also, we’ll discuss some of the advantages you will benefit from by migrating to the new Java library in upcoming blog posts. If you’d like to discuss the migration with us, you can come to our scheduled office hours for AdWords API and DFP API.

As always, please feel free to ask any questions regarding the client libraries on our forum for AdWords API and DFP API. You can also follow the Google Ads Developer page for all Ads-related updates.

- Takeshi Hagikura, AdWords API Team

Customizing Your AdMob Mediation Ad Requests

Monday, March 18, 2013

Ad networks take into account a variety of signals when targeting ads to your users. Generally speaking, the more information you provide to an ad network, the more accurately that network can target its ads, and the better those ads perform.Many parameters, such as age, gender, and location, are commonly used by most ad networks. AdMob Mediation supports passing those parameters directly in the AdRequest; these parameters will be passed to the networks you’re mediating:AdRequest adRequest = new AdRequest(); adRequest.addTestDevice(AdRequest.TEST_EMULATOR); adRequest.setBirthday(new Date(2000, 1, 1)); adRequest.setGender(AdRequest.Gender.MALE); adRequest.setLocation(location); AdMob Mediation also supports passing specialized parameters to specific networks. Any custom parameters used by a specific ad network can be passed to an instance of that network adapter’s NetworkExtras object, which is then set on the AdRequest. Here is how you can customize the background and text colors for AdMob text ads, and set education level and number of children for a hypothetical Example ad network: AdMobAdapterExtras adMobExtras = new AdMobAdapterExtras(); adMobExtras.addExtra("color_bg", "00FFFF"); adMobExtras.addExtra("color_text", "FF0000"); adRequest.setNetworkExtras(adMobExtras); ExampleAdapterExtras exampleExtras = new ExampleAdapterExtras(); exampleExtras.setEducation(Education.BACHELORS); exampleExtras.setNumberOfChildren(2); adRequest.setNetworkExtras(exampleExtras); AdMob Mediation will pass an adapter only the NetworkExtras object specific to that network. So in this case, the AdMob adapter will be provided with the AdMobAdapterExtras object, and the Example adapter will be provided with the ExampleAdapterExtras object. You can find the class name for each ad network’s NetworkExtras object in their respective adapter jar file.Custom EventsYou can also use CustomEventExtras to pass special parameters to any custom events that your app implements. Keep in mind that you can call AdRequest.setNetworkExtras() with only one instance of CustomEventExtras for all custom events that you implement. To make sure your custom event doesn’t access parameters meant for other custom events, we recommend you create a HashMap for each custom event, and pass in any necessary key-value pairs related to that custom event in that map.CustomEventExtras customEventExtras = new CustomEventExtras(); HashMap customExtras1 = new HashMap(); customExtras1.put("key1", "value1"); customExtras1.put("key2", "value2"); customEventExtras.addExtra("customEvent1", customExtras1); HashMap customExtras2 = new HashMap(); customExtras1.put("key1", "othervalue1"); customExtras1.put("key2", "othervalue2"); customEventExtras.addExtra("customEvent2", customExtras2); Your custom event implementation just needs to check CustomEventExtras for the HashMap at whatever key that was designated for it - in this case customEvent1. You’ll use these parameters to construct your custom event.HashMap extras = (HashMap) customEventExtras.getExtra("customEvent1"); Load the AdOnce you’re done setting all targeting options, make sure to call loadAd with that request.// This snippet assumes you have an AdView object named "adView". adView.loadAd(adRequest); If you have any questions or comments about AdMob, mediation, custom events, or targeting, we can field them in the forum. Also follow us on our Google+ page for ads-related updates.

- Eric Leichtenschlag, AdMob Team

Working with App promotion ads

Friday, March 15, 2013

AdWords API has released a new template ad specifically meant for mobile app developers who want to run ads promoting mobile and tablet apps. This ad format, known as “click-to-download” ad or app promotion ads, makes it easier for people to download your mobile app, from Google Play Store or iTunes. Version v201302 of the AdWords API adds support for this new ad format. To use this format, you first need to upgrade your campaign to enhanced campaigns.

App promotion ads will only show on the device from which the app can be installed. This means that ads for Android apps will only show on Android devices, and not on iOS devices. Ads for apps available only for tablets won’t show on mobile devices. This ensures that your application is promoted only to the right device platforms.

App promotion ads can be created as a template ad, using template ID 353. You need to create template element fields for headline, description1, description2, appId and appStore; other element fields are optional. Check out the full list of template fields and a complete Java code example.

You can find your Android package name by looking up the app in Google Play. The package name can be determined from the URL, which is of the form https://play.google.com/store/apps/details?id=<package_name>. For iOS, you’ll find the App ID within the app’s URL, which appears in the following format: http://itunes.apple.com/us/app/example-app-name/id#########. Appstore field can be 1 (iTunes), or 2 (Google Play Store).

If you face any issues with the above changes or have any questions about this feature, you can ask us on our developer forum, or at the upcoming GDL Office Hours with the Developer Relations team.

- Anash P. Oommen, AdWords API Team

Phasing out NGRAM_GROUP in AdWords API’s TargetingIdeaService

Tuesday, March 12, 2013

TargetingIdeaService currently has an NGRAM_GROUP AttributeType that gives you back the longest matching substring of the given keywords that appear more than n times (n is defined by AdWords System).

We’ve phased out the NGRAM_GROUP AttributeType starting from v201302 release. If you need to calculate NGRAM, you can do that using steps below.

1. Tokenize keyword ideas.
First, normalize the list of keyword ideas into a list of tokens and remove the low quality tokens (identical, consecutive or single character tokens). (e.g. Given keyword ideas of ["foo foo bar a baz", "foo bar"] become [["foo", "bar", "baz"], ["foo", "bar"]])

2. Generate all the possible n-gram candidates.
Then, generate all possible n-gram candidates from the list of separated tokens. (e.g. From the tokens [["foo", "bar", "baz"], [“baz foo”]], the n-gram candidates are [“foo bar baz”, “foo bar”, “bar baz”, “baz foo”])

3. Apply the n-gram groups to the unassigned keyword ideas.
For each keyword idea, we assign the longest n-gram candidate that appears at least n-times across all the keyword ideas. (e.g. Suppose n-gram candidate [“foo bar baz”, “foo bar”, “bar baz”, “baz foo”], keyword ideas ["foo bar baz", "foo bar”] and n is 2. candidate "foo bar" will be assigned to keyword ideas "foo bar baz" and "foo bar". The candidate “foo bar” appears 2 times in the keyword ideas.)

With those steps, you will get the longest matching substring that appear more than n times.

The complete code example is available here.

As always, please feel free to ask any questions regarding the client libraries or the AdWords API on our forum or during scheduled office hours. You can also follow the Google Ads Developer page for all Ads-related updates.

- Takeshi Hagikura, AdWords API Team

Reports, Negative keywords and more in AdWords scripts

Tuesday, March 12, 2013

AdWords reports using AWQL gives you the ability to look at your account performance with high granularity. This provides access to a large array of stats and fields as well as allow a script to exceed normal entity read limits.

Negative keywords at the campaign and ad group levels allows you to better manage keyword exclusions.

IDs on most AdWords entities allow you to easily tie report performance to actionable changes by selecting just the objects you care about.

New information about the execution environment and current account, such as whether or not the script is being previewed, account currency and more.

We've raised our limits: you can now work with 250k entities per script.

You can find more information about these features in our documentation. Join us on our forum for discussion and to have your questions answered.

- Kevin Winter, AdWords Scripts Team

Building for the Future: an update on DFP and the end of DART

Thursday, March 7, 2013

Editor's note: re posting from DoubleClick Publisher Blog. --Stan Grinberg

In 2010, in order to help publishers maximize the value of every impression, we introduced the new version of DoubleClick for Publishers (DFP).

In the years since, we’ve continued to invest in this platform, including new features that we heard were most important to our publisher partners - like the ability to manage desktop, mobile and video on a single ad server, and tools that help publishers better optimize campaign performance and save time. Today, thousands of publishers, such as The Weather Company, Gawker Media, Forbes, The Wall Street Journal and YouTube, are all leveraging DFP. And over two-thirds of our overall publisher ad impressions run through this new platform, up from one-third last year.

As far as we’ve come, we are just getting started with innovation to help publishers build for the future. To preview just a few of our 2013 plans, we’ll be helping publishers grow with new data-driven revenue models by enabling Audience Extension from directly within DFP. We’re increasing their ability to tap into the accelerating brand opportunity with new ways to measure such as Active View reporting for viewable impressions. We’re investing to make it easier for publishers to manage advertising across devices with tools like the Google Publisher Tag, which automatically selects the appropriate ad for the screen size (aka “responsive design”). And we’ll also be making it faster to access online content: since the new DFP is roughly twice as fast at serving as DART, when we’re done upgrading we’ll be saving Internet users 63 years a day in waiting for ads to serve.

This year our team is shifting all of our effort and investment to DFP to deliver even greater innovations for our partners. With this in mind, we’ll be ending support for our DART for Publishers legacy ad serving platform on September 1, 2013. To ensure continuity of ad serving, support and training, publishers who haven't upgraded to DFP by that date will be automatically scheduled for an upgrade date between September 1 and December 31, 2013 when ad serving on the DART for Publishers legacy platform will cease. Note that publishers using the DFP Small Business platform do not need to take any action and are already supported on the new DFP.

We strongly advise all publishers to complete their upgrades to DFP before September 1 to make sure you are able to use the new DFP to its full potential during the busy 2013 holiday season. Please contact your account manager as soon as possible if you don’t have an upgrade date scheduled. And if you’re not sure who to contact, you can always reach out to our customer support team.

We know our partners are looking for tools that can grow and adapt to the needs of their business not just today, but also for tomorrow, the next year and ten years from now. That’s why we’re fully committed to the new DFP. We’re ready to accelerate our pace of innovation on our platform, and we look forward to helping publishers as they break new ground in digital.

Posted by Jonathan Bellack, Director of Product Management

AdSense APIs Chart Tools updated to AdSense Management API v1.2

Thursday, March 7, 2013

Last year we featured a series of posts called Chart Tools week to connect the AdSense Management API to Google Chart Tools. The resulting code samples have been updated to version 1.2 of the API.

There are four episodes that can be used as a great exercise to familiarize yourself with the AdSense Management API and Google Chart Tools:

Monday: Apparently, your CEO wants more than a spreadsheet. This exercise connects the necessary parts to create a line chart that securely fetches data from your AdSense account. [code, result]
Tuesday: Your boss loved the idea but he wants a column bar chart with shadows and 3D graphics. This is no longer 1989 so you rely on the tasteful aesthetics of Google Chart Tools to show multiple metrics in a single bar chart. [code, result]
Wednesday: To complete the dashboard, we add a table and geo chart that will show our performance per country. [code, table, geo chart]
Thursday: This last exercise lets you explore controls and dashboards which are advanced features of Google Chart Tools. A slider filters results by one of the metrics. [code, result]

If you have any questions about these samples or the AdSense APIs in general, visit the AdSense API Forum. You can also follow our Google Ads Developers Google+ page for ad-related updates.

- Jose Alcérreca, AdSense API Team

Six new guides for AdWords API v201302 are now available

Wednesday, March 6, 2013

With the release of AdWords API v201302, we’ve introduced several new features as well as a number of changes to the existing services. Six new guides covering key features of v201302 are now available on the Developers site:

We’ve covered every advanced feature released in v201302 with this set of guides and hope you’ll find them useful. As usual, feel free to ask us questions on the forum or during office hours.

- Danial Klimkin, AdWords API Team.

Announcing the AdWords API Workshops Series in March / April

Monday, March 4, 2013

The Ads Developers Relations Team is pleased to announce the next global AdWords API Workshop series in March and April. This series follows the v201302 API release and will include tons of important information, updates and best practices around the new features introduced in the release.

We are inviting our AdWords API developers to join us in the following cities:

San Francisco, March 18th
London, March 18th
Hamburg, March 20th
Amsterdam, March 22nd
New York City, March 22nd
Paris, March 25th - New Location added this year
Sydney, April 9th - New Location added this year
Tokyo, April 12th

The agenda for the workshops will be quite packed and we will be presenting on many important topics as listed below. In addition to these technical deep-dives, we will have the AdWords API team on hand to meet with in person and answer all your API-related queries. We will also be closing the workshops with a Q&A panel.

Workshop topics include:

Latest on the AdWords API
Enhanced Campaigns & New Extensions Support
New Bidding & Budgeting in the AdWords API
New & Improved MCC Services
Account Performance Tracking & Optimization (and introducing a new tool - Kratu)

All events will have the same agenda, and will run from approximately 9:00AM - 5:00PM (local time). These workshops are geared towards a technical developer audience who should be already familiar with the AdWords API. Each session is technically focused and will involve going over code examples and other technical topics. We will also be recording and publishing videos for these sessions for those who might not be able to attend the event in person.

For more information and to register please check out the AdWords API Workshops page here:
http://sites.google.com/site/awapiworkshops/home

- Sumit Chandel, AdWords API Team

Announcing v201302 of AdWords API

Monday, March 4, 2013

We are pleased to announce the release of AdWords API v201302. This latest release of the API adds native support to AdWords enhanced campaigns along with a rich set of new functionalities.

v201302 Highlights:

With the release of v201302, the version v201209 is now deprecated and will sunset on July 1st, 2013. For more information about the AdWords API sunset schedule visit this page.

We are also excited to announce that we will be hosting a new series of global AdWords API Workshops and inviting partners and developers to learn about all the new changes and best practices in the new API. We will be posting more details and opening registration for the workshops shortly.

As with every new version of the AdWords API, we encourage you to review in detail all the API changes listed in the release notes and the v201302 migration guide. We have also published updated client libraries and code examples. In the upcoming weeks you will be able to enjoy several GDL recorded presentations discussing the features of the v201302 release. If you have any questions please post on the forum or attend one of the AdWords API Office Hours Hangouts.

- The AdWords API Team

Announcing v201302 and the deprecation of 3 versions of the DFP API

Friday, March 1, 2013

Today we are launching v201302 of the DFP API. This version includes many of the most requested features, such as managing contacts, running sell-through reports (if enabled on your network), and improved partner management integration. We've also added the new ad rule service, activity/activity group services, content bundle service, as well as many other features, which can all be found on our release notes page.

Keeping in touch

Starting with v201302, you will be able to manage all of your DFP contacts in one place. We believe this is a powerful feature for the API since quite a few publishers have large databases of contacts that can now be easily synced. Once your contacts are in DFP, you can add them to companies and orders. You can also fetch all contacts that haven’t been invited to view their partner orders yet and use that list to invite contacts in the UI.

We've also improved partner management in the API. You can now set up ad units for affiliate/distribution partners using the partnerId field. Once your partner ad units are set up, you can then report on them using partner revenue dimensions and columns.

Reporting

We've added over 60 new columns and dimensions in this version to more closely match what exists in the UI today. In addition to reporting on your partners as discussed above, you’ll now be able to run sell-through reports (if enabled on your network) on your inventory and reach reports on the lifetime (i.e. the last 6 months) of your orders.

As well as adding new columns, we've also changed a few existing ones. To provide more flexible revenue reporting, existing revenue columns have been renamed to indicate that they do not include cost-per-day (CPD) revenue. New WITH_CPD columns have been added to include CPD revenue in your reports.

Finally, we've made some changes to entity dimensions. Since including a dimension like Dimension.LINE_ITEM added both the name and the ID as columns in the report, the exact behavior of including a dimension wasn't always clear. Ambiguous dimensions have now been replaced by NAME and ID counterparts. To replicate the old behavior, include both of these dimensions in your report.

Housekeeping and deprecation

Starting in v201302, we are shifting many of the disjointed creative asset properties to a single manageable object - CreativeAsset. The first type of creatives to get this treatment is image creative. The 4 fields that previously represented the image asset have been replaced by a single primaryImageAsset field. With the new field, you’ll always know where to find the URL to preview the asset, instead of having to programmatically determine the name of the property.

Last but not least, to make room for all the new features, versions v201203, v201204, and v201206 are now deprecated. On June 1st, we’ll be removing them from our online documentation and client libraries. If you are using one of these deprecated versions, now would be great time to update to take advantage of all the new features.

Be sure to also follow us on our Ads Developer Google+ page. We'll be publishing some great tips on using the API there soon. If you have any suggestions or questions about the new version, but sure to visit our forum.

- Adam Rogal, DFP API Team

Ads Developer Blog

Announcing v1.2 of the Ad Exchange Buyer Rest API

Introducing the AdMob eCPM Floor Beta

Changes to Content Bidding

4 days left to migrate out of AdWords API v201206

Device column available in Click Performance Report

DFA API v1.18 Sunset Date Pushed Back

Deprecation of the old Java library for AdWords and DFP APIs

Customizing Your AdMob Mediation Ad Requests

Working with App promotion ads

Phasing out NGRAM_GROUP in AdWords API’s TargetingIdeaService

Reports, Negative keywords and more in AdWords scripts

Building for the Future: an update on DFP and the end of DART

AdSense APIs Chart Tools updated to AdSense Management API v1.2

Six new guides for AdWords API v201302 are now available

Announcing the AdWords API Workshops Series in March / April

Announcing v201302 of AdWords API

Announcing v201302 and the deprecation of 3 versions of the DFP API

Labels

Archive

Feeds

Google Ads API [+]

AdWords API [+]

Google Ads scripts [+]

Content API for Shopping [+]

Google Ad Manager API [+]

DCM API [+]

Mobile Ads [+]

IMA SDK [+]

More Google blogs