Starting on September 14th, 2016, Productstatuses will return all the errors and warnings present in the Diagnostics tab of Merchant Center. To explain the changes, first we separate errors and warnings for products into two categories:

• Validation issues are reported as a result of product insertion and update, and they include issues such as missing required fields or invalid item IDs.
• Data quality issues are reported later after either automatic or manual review of the data provided to Merchant Center, and they include issues such as product images being too generic or a non-matching price on the landing page.

Historically, only data quality issues were available from Productstatuses, while validation issues required the developer to check the returned status from the insertion or update of the product. After this change, developers can retrieve both data quality and validation issues using Productstatuses, but this means that developers may see more issues returned by Productstatuses than before.

Please note that the includeInvalidInsertedItems URL parameter to Productstatuses.list still defaults to false. This means that, by default, calls only retrieve products which had no validation errors, and thus the retrieved products will only include data quality issues and validation warnings (if any). If you want to retrieve information about products with validation errors, please set this parameter to true.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.

-Stevie Strickland, Content API for Shopping Team

We’ve launched a new Shippingsettings service which supports the new shipping settings in Merchant Center. This service replaces the old Accountshipping service, which has been deprecated and will be retired March 1st, 2017.

The new service uses rate tables instead of rate trees to describe complex rate systems, and also supports retrieving the available shipping services. Check out the updated Account-level Tax and Shipping guide and reference documentation if you're interested in what the new service looks like!

A note to users of Accountshipping: you can retrieve settings uploaded via Accountshipping through Shippingsettings, but not vice versa. Thus, if you currently have shipping settings, you can see what your current settings would look like in the new format expected by Shippingsettings by retrieving them using the new service.

If you're migrating from Accountshipping, we suggest you either first experiment with Shippingsettings on another Merchant Center account used for testing, or keep the code to upload settings via Accountshipping around until you're sure your new Shippingsettings code behaves as expected.

If you have any questions or feedback on the Shippingsettings service or other questions about the Content API for Shopping, please let us know on the forum.

-Stevie Strickland, Content API for Shopping Team

Adwords currently supports demographic targeting only for Display network campaigns, but starting September 19, 2016 and launching over the subsequent days, demographic targeting will also be supported for Search campaigns. All existing AdWords API versions will retroactively allow these criteria in Search campaigns.

The benefit here for AdWords API users is that AgeRange and Gender criteria will be allowed in Search campaigns. Formerly, you would receive a CriterionError.CANNOT_ADD_CRITERION_TO_SEARCH_PLUS_CAMPAIGNS error when trying to add these types.

If your application does any type of automatic bidding, make sure that you update your app to accommodate these new potential bid modifiers on Search campaigns before September 19. These new criteria may be added by users of the AdWords user interface, so your code may have to handle them even if your application doesn't add them explicitly. This may be particularly relevant if you use the "Target and bid" (targetAll=false) option in TargetingSettingDetail, because the new criteria will begin restricting targeting.

If you have any questions about this change, or other questions about the AdWords API, contact us via the forum.

- Michael Cloonan, AdWords API Team

If you’re in the Northern Hemisphere like I am, then you’re probably also experiencing the sweltering heatwave we’re enjoying this summer. You know what’s a great way to beat the heat? Stay inside and upgrade your DFP API version to the other hotness: v201608. If the prospect of air-conditioning isn’t enough to draw you away from the allure of melting outside, consider the following additional enhancements!

Programmatic & Sales Manager

One of the biggest features we’re adding to the DFP API is the support for programmatic guaranteed deals. This allows you to perform the end-to-end work of defining your inventory, negotiating with buyers, and trafficking to DFP all using the same great API you know and love (ours). To see how to create and use programmatic objects, see our API guide.

In addition to programmatic guaranteed, we’ve further enhanced the ProposalLineItem object by now providing information on whether the pricing model is Gross or Net via the ProposalLineItem.rateCardPricingModel field.

Trafficking

On the trafficking front, we’ve added the ability to delineate whether or not a creative isSafeFrameCompatible for applicable creative types such as CustomCreative. We’ve also added viewability tracking event types which can now be found on the ConversionEvent object. And finally, the one you’ve all been waiting for - there’s now support for the popular Html5Creative type.

Reporting

It’s not December, but it sure feels like the holiday season. If you’ve ever wanted to run a query you had saved in the UI, the ReportService has got your back. We’ve added ReportService.getSavedQueriesByStatement, which allows you to retrieve reports you’ve created in the UI. You can then run these using ReportService.runReportJob.

Of course, since this is an action-packed release, we can’t possibly list out everything we’ve changed in a blog post, so take a peek at the full release notes.

As a reminder, with each new release comes a new deprecation (this one’s special, it’s a double deprecation!). If you're using v201511 or earlier, it's time to look into upgrading to v201608. If you have any questions about upgrading, let us know on the developer forum.

 - Nicholas Chen, DFP API Team

In AdWords you could choose to optimize your automated bidding on "Converted clicks" or "Conversions." AdWords recently announced that we're saying goodbye to "Converted clicks" in favor of “Conversions,” which offers much more flexibility and measurement options. As a result, we’re updating the API.

The conversionOptimizerMode attribute of the Customer.conversionTrackingSetting allowed you to set ONE_PER_CLICK ("Converted clicks") or MANY_PER_CLICK ("Conversions") at the account level.

Starting on September 21, 2016, all AdWords accounts will be automatically migrated to set conversionOptimizerMode to MANY_PER_CLICK, and new mutate operations to change this setting will fail with RequestError.INVALID_INPUT.

Prior to September 21, 2016, ensure your CustomerService mutate requests do not attempt to modify the value of conversionOptimizerMode. You can also migrate your accounts before the migration by setting conversionOptimizerMode to MANY_PER_CLICK.

If you have any questions, please let us know on the forum.

-Mike Cloonan, AdWords API Team

Starting September 26, 2016, we will be removing support for all TrueView in-search video template ads (template ID 231) from Display campaigns, and will no longer accept new ads for that template. Existing Display ads of this template ID will stop serving and be moved to the DISABLED status. This is in line with the upgrade of TrueView campaigns during the integration into AdWords.

Please note that this only affects Display campaigns, and not existing video campaigns. Historical stats for these ads will still be available in reports.

If you have any questions about this change, or other questions about the AdWords API, please contact us via the forum.

- Michael Cloonan, AdWords API Team

Today we’re pleased to announce the new and revamped DFP Playground. Like the previous Playground, you can test PQL statements and examine JSON equivalents of the objects you retrieve from the DFP API. In the new DFP Playground, you can easily switch between services using a tab interface, and you can even view documentation for a particular service with a simple click of a button.

The new DFP Playground's tab-based interface is cleaner and less crowded.

Clicking a result produces a dropdown with the object’s JSON representation.

Checking out the GitHub project

The DFP Playground is available on GitHub. Reading the code should give you a good idea of best practices for interacting with the DFP API via the Google Ads Python client library in a web application environment. The process to set up your own instance of the DFP Playground and deploy it to AppEngine is documented in the README.

Feel free to post any bug reports or feature requests in the issues section. If you have any questions regarding the DFP API, please reach out to us on our forum.

 - Andrew Yang, DFP API Team

We are making some changes to the way AdWords scripts returns quality score data for keywords.

We will return a null quality score for keywords that don’t have enough impressions and clicks to determine a Quality Score, such as new keywords or old ones that haven't served a long time. This will impact your scripts in two ways:

• Reports: Starting with version v201607, the Critieria Performance and Keywords Performance reports will return a quality score of “--” for these keywords. Past versions (v201605 and earlier) of these reports will remain unchanged.
• getQualityScore method: Starting the week of Sep 12, 2016, the getQualityScore method of the Keyword entity will return NULL score for these keywords instead of a numeric value.

If you use use quality score information in your script, please make sure you update it to work with the new changes.

Filtering on quality score

Filtering on quality score will work as follows:

• If no filtering conditions are specified on the QualityScore field, all matching keywords are returned, including those with NULL quality score.
• If numerical filtering conditions are specified on the QualityScore field, keywords with NULL quality score information are excluded automatically. For example, QualityScore <= 6 will include keywords with quality score from 1 to 6 but exclude keywords with NULL quality score.
• To retrieve keywords with NULL quality score, filter using the condition HasQualityScore = FALSE.
• To retrieve keywords with NULL quality score along with keywords with specific quality scores, you need to run two separate reports and combine the results locally.

If you have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.

Anash P. Oommen, AdWords Scripts Team

Today we're releasing v2.6 of the DCM/DFA Reporting and Trafficking API. This release includes a number of highly anticipated features, such as:

• Reusable targeting templates for ads (learn more)
• Dynamic asset selection for In-stream video creatives (learn more)
• Support for the vCPM - Active View placement cost structure (learn more)

We've also improved click-through URL management for Display creatives, expanded custom floodlight variable support, and much more. See our release notes for full details.

Retiring legacy creative types

Beginning with this release, the DCM API no longer supports creating legacy HTML5 Banner and Image creatives. As previously announced, these legacy types have been replaced by the new streamlined Display creative.

Additionally, the ability to upload Flash assets into DCM was disabled back in June. Accordingly, this functionality is also being removed from the API beginning with this release. Previous API versions will continue to support uploading Flash assets until their respective sunset dates, but users are strongly encouraged to begin transitioning to HTML5 now.

Deprecation and sunset reminder

In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v2.5, which will sunset on February 28th, 2017. After this date, any requests made against v2.5 will begin returning errors.

As a reminder, API v2.3 will be sunset on August 31st, 2016. To avoid an interruption in service, all users are required to migrate off of this version by the sunset date.

Learn More

As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the release notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.

Give it a try and let us know if you have any questions!
- Jonathon Imperiosi, DCM API Team

The transformation of Firebase into a unified mobile platform brought with it new Gradle artifacts and CocoaPods that mobile developers can use to import the Mobile Ads SDK. With these additions, there are now several alternatives for each platform. Thanks to your feedback, we wanted to share a little more information about which ones we recommend and what libraries they include, so here's a quick run-down.

Android & Gradle

firebase-ads (recommended)

This is the best way to get the Mobile Ads SDK into your project. With the firebase-ads artifact, you get everything you need to load and display ads from AdMob, DFP, or AdX, plus Firebase Analytics built in. You'll also be ready to add the client components for any other Firebase services you want to use, like firebase-crash or firebase-config. Unless you have a specific need to use the SDK without Firebase, this is your jam.

If you'd like to see a screencast of how to get up and running with AdMob using firebase-ads, check out this episode of the Firecasts series:

play-services-ads

For those not using Firebase, this Gradle artifact contains the Mobile Ads SDK on its own. You'll get the client code for AdMob, DFP, and AdX, but no Firebase services.

play-services

This is the full Google Play services client, also without Firebase. This gives you not only the Mobile Ads SDK, but all the other Google Play services SDKs as well: Maps, Drive, Fit, and so on. Since you're probably not using every API that Play services offers, it's better to import them individually. If you need mobile ads and Play games, for example, just include play-services-ads and play-services-games.

play-services-ads-lite

The SDK team developed this new Gradle artifact for a very specific use-case. It contains a slimmed-down version of the Mobile Ads SDK designed to work only on devices that have Google Play services installed. If reducing app size is extremely important for you, this can help lessen the impact of the Mobile Ads SDK, but it won't be able to load and display ads on devices that don't have Play services. Make sure you're intimately familiar with your app's install base before considering this tradeoff, and see the Lite SDK guide for more details.

iOS & CocoaPods

Firebase/AdMob (recommended)

This is the Firebase CocoaPod for AdMob and the Mobile Ads SDK. While it's labelled as "AdMob," this pod gives you the iOS client code for DFP and AdX as well. You'll get everything you need to load and display ads from all three sources, plus Firebase Analytics built in. This CocoaPod is also easy to combine with any other Firebase pods your app needs, like Firebase/Crash and Firebase/Database. For most developers, this is the one you want.

The Firecasts series has an episode that shows how to import AdMob and Firebase into an app using Firebase/AdMob, so check that out for a detailed screencast:

Google-Mobile-Ads-SDK

For developers not yet using Firebase, this pod contains just the Mobile Ads SDK. You get everything necessary to show ads from AdMob, DFP, and AdX, but no Firebase services.

GoogleMobileAds

This is an older, alternate CocoaPod for the Mobile Ads SDK that should no longer be used. Google-Mobile-Ads-SDK is the better choice if you aren't using Firebase.

More Info

If you've got questions about Firebase and the best ways to get started, the Firebase support page also has a bunch of options that can help. If you've got technical questions about the Mobile Ads SDK itself, you're welcome to stop by the SDK support forum.

 - Andrew Brogdon, Mobile Ads Developer Relations

Along with the AdWords UI and API, AdWords scripts will be rolling out support for desktop and tablet bid modifiers (in addition to mobile) to accounts over the coming weeks. This functionality will be available for ad groups in the new AdGroupDevices class. For campaigns, you will be able to use the new tablet() and desktop() methods in the PlatformSelector class. See our code examples for ad groups and campaigns to learn more about using these methods.

Note: During the rollout, if the feature is not yet enabled in your account, attempts to set tablet and desktop bid modifiers will fail.

With this launch, the getMobileBidModifier() and setMobileBidModifier() methods of the AdGroup and ShoppingAdGroup classes will be deprecated. Updating existing scripts to use the new ad group interface is straightforward. For example, adGroup.getMobileBidModifier() becomes adGroup.devices().getMobileBidModifier().

If you have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.

Jason Goodman, AdWords Scripts Team

Update (Dec 13, 2016): The clearing of bid modifiers described in the previous version of this post are complete.

What’s changing?

Starting in late August, platform bid modifiers of campaigns and ad groups attached to Target CPA and Conversion Optimizer bidding strategies will be cleared. Your campaigns will continue to serve as they do currently.

Why is this happening?

The clearing of these bid modifiers is part of an upcoming feature launch. The new feature will allow users to set platform bid modifiers for entities attached to Target CPA and Conversion Optimizer bidding strategies. In the past, this platform bid modifier value was ignored. By clearing these values for you, we can release the functionality without affecting your currently serving campaigns.

How does this affect me?

For most users, we will only clear platform bid modifiers on Target CPA and Conversion Optimizer entities. Some customers will also see a shifting of platform bid modifiers where a Target CPA ad group inherits modifiers from a non-Target CPA campaign.

Here are some changes that you’ll see in your account before the new features launches:

• For ad groups, clearing mean the entire AdGroupBidModifier will be removed.
• For campaigns, clearing means CampaignCriterion.bidModifier will be set to 1.0.
• If the AdGroupBidModifier.bidModifier or the CampaignCriterion.bidModifier was set to 0.0 to opt-out, the bid modifier will not be touched.
• If the AdGroupBidModifier.bidModifier or the CampaignCriterion.bidModifier does not target a Platform criterion, the bid modifier will not be touched.

The new feature will roll out to all users over the course of three weeks starting in late August. Sometime during those three weeks, we will clear your platform bid modifiers, and shortly thereafter we will enable the feature for your account. You will then see the option to set platform bid modifiers in the AdWords user interface. Bid modifiers set after that point will be preserved.

What should I do?

• Check your code and verify that if you’re setting this platform bid modifier it’s intended because that code will have an effect on bidding after the clearing process.
• If you care about the platform bid modifiers that you have set for Target CPA or Conversion Optimizer campaigns, save them offline before late August.

Where can I learn more?

• Bidding guide
• Bid modifiers guide
• Ads API Client Libraries

Questions? Visit us on the AdWords API Forum or our Google+ page.
Nadine Sundquist, AdWords API Team

In September 2016, we will disallow the setting of positiveGeoTargetType as AREA_OF_INTEREST for non-search campaigns. Existing non-search campaigns whose positiveGeoTargetType are set to AREA_OF_INTEREST will be automatically changed to DONT_CARE. Any requests that attempt to set this to AREA_OF_INTEREST for non-search campaigns will fail.

In addition, for search campaigns, the behavior of AREA_OF_INTEREST will be changed. If you use this setting, the campaign will primarily target a user's area of interest and secondarily his/her location of presence. In other words, if the area of the user’s interest is explicitly present in a search query, such as “flower delivery in NYC”, then it’ll be used. If the search query doesn’t include any areas of interest, say “flower delivery”, the physical location of the user performing the search will be used instead.

If you have any questions or need help, as always, please post on the forum or the Ads Developers Plus Page.
Thanet (Knack) Praneenararat, AdWords API Team

AdWords API v201601 will be sunset on August 27, 2016, after which all v201601 API requests will begin to fail. This version was deprecated on May 27, 2016. If you are still on v201601, we recommend that you skip v201603 and v201605 and migrate directly to v201607. Please be sure to migrate prior to the sunset to ensure your API access is unaffected.

We've prepared various resources to help you with the migration:

• v201607 migration guide
• v201605 migration guide
• v201603 migration guide
• Release notes

As always, if you have any questions about this migration, please contact us via the forum.

- Michael Cloonan, AdWords API Team