Google Ads Developer Blog

Changes to quality score in AdWords scripts

Monday, August 15, 2016

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

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

Tuesday, August 9, 2016

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

Friday, August 5, 2016

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 & Gradlefirebase-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-adsFor 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-servicesThis 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-liteThe 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 & CocoaPodsFirebase/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-SDKFor 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.GoogleMobileAdsThis 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 InfoIf 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

Expanded Support for Device Bid Modifiers in AdWords Scripts

Thursday, August 4, 2016

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

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

Tuesday, August 2, 2016

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?

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

Nadine Sundquist, AdWords API Team

Changes to the setting of positiveGeoTargetType in AdWords campaigns

Tuesday, August 2, 2016

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 sunset reminder

Monday, August 1, 2016

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.

- Michael Cloonan, AdWords API Team

Ads Developer Blog