Subscribe: AdWords API Blog
Added By: Feedage Forager Feedage Grade A rated
Language: English
ads sdk  ads  adwords api  adwords  api  app  bid modifiers  bid  campaigns  firebase  mobile ads  mobile  modifiers  sdk 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: AdWords API Blog

Google Ads Developer Blog

The official blog for information about the AdWords, AdSense, DoubleClick and AdMob APIs and SDKs.

Updated: 2016-09-27T16:24:00.369-07:00


Google Mobile Ads Unity Plugin v3.0.7


We recently launched v3.0.7 of the Google Mobile Ads Unity Plugin. The updated v3.0.7 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.

Native Ads Express

This release introduces support for Native Ads Express. With Native Ads Express, you can create CSS templates that define how ads are presented in your app (things like image sizes, fonts, colors, and so on). These CSS templates are used to generate ad creatives that complement the native look and feel of your app. You can find more information on integrating Native Ads Express into Unity applications in our developer docs.

Android IL2CPP

The v3.0.7 release resolves compatibility issues with the IL2CPP scripting backend and the Google Mobile Ads Unity Plugin. This allows the use of the the IL2CPP scripting backend, a high-performance alternative to the Mono virtual machine and AOT compiler, in Unity applications with the Google Mobile Ads SDK.

The source code and a sample app for the plugin are available in our GitHub repo,asisa changelogfor this release. If you have any questions about Unity integration, you can reach us on our developer forum.


Support for Search Audiences in AdWords Scripts


AdWords Scripts now supports Audiences for Search and Shopping campaigns. This release covers all the features you can do through the Audiences Tab in the AdWords UI - target or exclude audiences for an ad group, exclude audiences for a campaign, and apply or adjust bid modifiers. You may also retrieve audiences and their stats associated with ad groups and campaigns. Audience creation is not supported in this release.

See the code snippets to learn how to use this feature. As always, let us know your questions and feedback on our developer forum.


Support for additional audiences in AdWords Search and Shopping campaigns


What's changing
Historically, some types of audiences have only been available for targeting and bidding in Display campaigns, as indicated by UserList.isEligibleForSearch = false in the AdWords API.

Starting at the end of September, 2016, both AdWords and the AdWords API will allow you to target additional audiences in Search and Shopping campaigns.

What you should do
  • Make sure that your application does not make assumptions about which user lists are available for Search and Shopping campaigns. Instead, your application should check the value of the isEligibleForSearch attribute of each UserList.
  • You can discover the audiences in your AdWords account and their eligibility for Search, Shopping, or Display campaigns by issuing an AdwordsUserListService get or query request that includes the IsEligibleForSearch and IsEligibleForDisplay selector fields. On an ongoing basis, you should periodically check for user lists where eligibility has changed due to improvements in AdWords.
  • If you'd like to add additional audience targeting to your Search or Shopping ad groups, add a BiddableAdGroupCriterion with a criterion set to an instance of the appropriate type of UserList. Make sure that your application can handle an OperationAccessDenied.OPERATION_NOT_PERMITTED_FOR_CAMPAIGN_TYPE error, which will occur if the particular UserList in your request is not currently available for Search and Shopping campaigns.
Further reading
For an overview of remarketing and audience targeting in the AdWords API, check out the Remarketing and audience targeting guide.

If you have any questions, please post on the forum or the Ads Developers Plus Page.

New dates for quality score changes in AdWords scripts


We recently announced some changes to the way AdWords scripts returns quality score data for keywords. To give developers more time to review their scripts that rely on Quality Scores in preparation for this update, null Quality Scores will now roll out on the the week of October 10th, 2016.

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

Use Google Mobile Ads SDK 7.11.0 to update apps for iOS 10


With the Firebase 3.6.0 launch comes the release of version 7.11.0 of the Google Mobile Ads SDK, which has been optimized for the latest release of iOS. Any app that supports iOS 10 should be built against v7.11.0 or higher of the Mobile Ads SDK. AdMob publishers can grab the latest version of the SDK using the Firebase/AdMob CocoaPod or via the Firebase manual download. DFP publishers can get the latest version from the Google-Mobile-Ads-SDK CocoaPod or via the Mobile Ads SDK manual download.

What changed?

With the rollout of iOS 10, the App Store’s privacy policy requires apps to provide a usage description when attempting to access privacy-sensitive data, such as a user’s calendaror Bluetooth. You may have seen the following errors when attempting to upload your app to iTunes Connect:

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data."

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothPeripheralUsageDescription key with a string value explaining to the user how the app uses this data."

The latest version of the Mobile Ads SDK has been updated for iOS 10, and will no longer cause these errors to appear.

Information for MRAID creative designers

To comply with the App Store privacy changes, we removed support for the mraid.createCalendarEvent() and mraid.storePicture() methods. You will now see that the mraid.supports("calendar") and mraid.supports("storePicture") methods always return false. Per the MRAID v2 spec, MRAID creatives should check for support of these features before using them, and correctly handle the case where they’re unavailable.

If you have any questions regarding these changes, please contact us through our forum.


More time for upgrading your standard text ads


In a previous blog post, we announced that you would need to upgrade your standard text ads by October 26, 2016 to expanded text ads. To make sure you have ample time to test and iterate your expanded text ads for the holidays, we are giving advertisers more time to upgrade your creatives. You now have until January 31, 2017 to make the transition to expanded text ads (instead of the original date of October 26, 2016).

Starting on January 31, 2017: Please take advantage of this additional time to upgrade your standard text ads. For more details and tips, check out this blog post.

Questions? Visit us on the AdWords API Forum or our Google+ page.

Upgrade to campaign drafts and experiments in the AdWords API


[Update 9/14/2016: The previous version of this announcement indicated that you would be unable to create experiments starting on October 17, 2016. After hearing your feedback, we have decided to continue to allow full ExperimentService functionality in existing API versions up until the final shutoff date.]

In v201603, we introduced campaign drafts and experiments to the AdWords API for Search campaigns, which is a more flexible alternative to the existing ExperimentService. Now that you can run experiments on Display campaigns as well, campaign drafts and experiments do everything the ExperimentService can do and more.

As a result of this expanded functionality, the ExperimentService will be sunset. If you’re still using the ExperimentService, please take the time to update your code to use campaign drafts and experiments instead.

On February 1, 2017, all experiments running via the ExperimentService will be stopped. After this date, all ExperimentService experiments will be deleted, stats will be unavailable, and API calls to the ExperimentService across all API versions will result in an error.

Please move off the ExperimentService before February 1, 2017 to ensure that you are able to continue running experiments.

If you have any questions, please post on the forum.


Google Ads API .NET client library runtime update


Beginning in November 2016, all new releases of the Google Ads API .NET client library will target .NET Framework 4.5.2+. Currently released client library versions will not be affected.

Why are runtime requirements changing?

On January 12th, 2016, Microsoft ended support for .NET Framework versions 4, 4.5, and 4.5.1. To ensure the continued security and stability of our client library, we will also stop supporting these legacy framework versions.

Additionally, increasing the runtime requirement allows us to make use of new framework functionality, to further improve and modernize the library.

How can you prepare?

If your application currently targets .NET Framework 4.5.2+, then no action is required. Users of .NET Framework versions <= 4.5.1 will need to upgrade to 4.5.2 in advance of the November 2016 release. Users on non-Windows platforms should similarly ensure that their version of Mono supports the .NET Framework 4.5.2 target.

If you have any questions or concerns, feel free to open an issue on the client library's issue tracker.


Support for account-level sitelinks in AdWords API


Sitelinks in ads let you show additional links to specific pages on your website and are an effective way to drive traffic to your business. Account level sitelinks started rolling out recently in the AdWords user interface.

The AdWords API already supports sitelinks at the account level across all versions without any changes. You can use the CustomerExtensionSettingService to read and mutate the existing extension type SitelinkFeedItem, or associate sitelinks via Feed services.

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

Productstatuses to include validation issues in Content API for Shopping


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.


Shippingsettings to replace Accountshipping in Content API for Shopping


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.


Demographic targeting in Search campaigns coming to AdWords API


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.


Announcing v201608 of the DFP API


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 ManagerOne 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. TraffickingOn 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. ReportingIt’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[...]

Migration to "Conversions" for conversion optimizer in AdWords API


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.


AdWords: Removing support for TrueView template ads in Display campaigns


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.


Announcing the New DFP Playground


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.

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

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


Changes to quality score in AdWords scripts


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.


Announcing v2.6 of the DCM/DFA Reporting and Trafficking API


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[...]

Importing the Mobile Ads SDK with Firebase


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: width="560" height="315" src="" frameborder="0" allowfullscreen> 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: width="560" height="315" src="" frameborder="0" allowfullscreen> 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 t[...]

Expanded Support for Device Bid Modifiers in AdWords Scripts


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.


Clearing platform bid modifiers of Target CPA and Conversion Optimizer campaigns starting in late August


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.[...]

Changes to the setting of positiveGeoTargetType in AdWords campaigns


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.

AdWords API v201601 sunset reminder


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: As always, if you have any questions about this migration, please contact us via the forum.



A new episode of The Mobile Ads Garage has hit YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

Did you know that AdMob serves ads to more than two hundred countries and territories? To celebrate, The Mobile Ads Garage presents Episode 8 in two languages! Katie from the Mobile Ads SDK team stops by to help Andrew talk about rewarded video mediation. You'll hear the basics of how and why to use AdMob mediation and the Mobile Ads SDK to show rewarded video ads in both English and Chinese.

Rewarded video is a full-screen ad format in which users watch ads in exchange for something, typically an in-game reward. Because users hold the power of choice, they don't have to see ads they aren't interested in. Plus, publishers can build the view/reward cycle into the mechanics of their games, creating monetization strategies that actually increase user engagement. When you add all that to AdMob's ability to automatically prioritize mediated networks by eCPM, you've got a complete solution.

width="560" height="315" src="" frameborder="0" allowfullscreen>

If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.


Announcing v201607 of the AdWords API


Today we’re announcing the release of AdWords API v201607. Here are the highlights: Expanded text ads. The AdWords API now supports creating these ads in production accounts. Previously, creation of ExpandedTextAds was only supported in test accounts. Greater transparency in quality score. To improve transparency, QualityScore in Keywords Performance and Criteria Performance will report a value of two dashes (--) when there aren’t enough impressions or clicks to accurately determine a keyword’s quality score. The HasQualityScore field introduced in v201605 will now return false for any row without a QualityScore. Finally, for criteria without a quality score, the qualityInfo attribute will no longer be returned by AdGroupCriterionService get and query requests. Price extensions. The new PriceFeedItem type allows you to showcase your services and range of products, along with their costs, with your mobile text ads. Read more about price extensions in this Inside AdWords blog post. Converted clicks is deprecated. ConvertedClicks and its related fields have been removed from all reports in favor of Conversions. Conversions is the ideal way to measure valuable actions, and most advertisers already use Conversions as their primary reporting and bidding metric. Conversions is more flexible and is capable of measuring behavior that spans multiple conversion events or multiple clicks. Check out the recent Inside AdWords blog post for more details. Platform bid modifiers. Bid modifiers specific to desktop and tablet have been added to the campaign and ad group performance reports. Also, managing bid modifiers for desktop and tablet is currently only available in test accounts, but we will be rolling it out to live accounts for all versions over the coming weeks. CustomerService.get is deprecated. The get method of CustomerService has been replaced with the more flexible getCustomers method. Check out our migration guide for details. If you’re using v201601 or v201603 of the AdWords API, please note that they’re now deprecated and will be sunset on August 27, 2016 and October 25, 2016, respectively. We encourage you to skip v201605 and migrate straight to v201607. As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201607 migration guide. The updated client libraries and code examples will be published shortly. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page. - Josh Radcliff on behalf of the AdWords API Team[...]