Category Archives: Google Ads Developer Blog

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

DoubleClick Ad Exchange Seller REST API Report changes

The ability to generate saved reports using the API will be retired on April 6th, 2015, along with six dimensions due to low usage. After the sunset, any API calls to Reports.Saved or requests for these dimensions will result an error.

After the introduction of the Query Tool to the UI last year, the ability to create and edit saved reports in the UI was removed--leading to the sunsetting of Reports.Saved in the API.

The dimensions that will be removed are
  • AD_FORMAT_CODE
  • AD_UNIT_EXTERNAL_ID*
  • AD_UNIT_CODE*
  • DSP_BUYER_NETWORK_ENCRYPTED_ID
  • EXPANSION_TYPE_CODE
  • PLATFORM_TYPE_CODE
[*] these dimensions haven't been relevant for 6 months due to the move to Enhanced Inventory Controls and only are retained in the UI for historic purposes.

To find out if you will be affected, search your code for any of the strings above and remove them; they will be associated with a call to Reports.Generate.

For a full list of available dimensions please see the AdX Seller REST API documentation.

-- Dean Lukies, Ads Developer Relations

Announcing Upgraded URLs for the AdWords API

Today we’re rolling out access to Upgraded URLs for all AdWords API users. Upgraded URLs provide an easier and faster way to manage and track important information about each click on your AdWords ads. This new feature lets you enter the landing page portion of your URL and your tracking information separately in AdWords. Now you have the option to update your tracking information at your account, campaign or ad group without having to reset your ad stats.

For more information, please check out the AdWords blog. We've also put together a guide on how to set up Upgraded URLs via the AdWords API, which includes examples in each of our client libraries.

One final note: Upgraded URLs are intended to replace the old destination URL field in all relevant ad types. We have built tools to help you update your URLs to the new system, and you have a few different upgrade options, depending on your current URL structure. For more information on the sunset timeline and your options for upgrading, see our getting started guide.

If you have any questions or comments about this new feature, please contact us on the forum or via our Google+ page.

- Michael Cloonan, AdWords API Team

Announcing version 7.0.0 of the Google Mobile Ads SDK for iOS

Today we’re releasing v7.0.0 of the Google Mobile Ads SDK for iOS. For this release, we focused on making the SDK easier to use, including distributing it as a framework. We’re also showing our DFP publishers some love by launching new first-class APIs to support the common DFP features they’re already using with Google Publisher Tag. A detailed list of these and other changes can be found on our release notes page.

SDK as a framework

The SDK is being distributed as a framework in this release. This comes with the following benefits:

  • You only have to add one item to your project. No more worrying about adding headers separately!
  • The SDK automatically links frameworks it depends on. No more manually adding framework dependencies!
  • Classes that use the SDK can now automatically import the necessary headers files with a single line of code: 
    @import GoogleMobileAds;
    Previously, you had to import header files separately. 

    #import "GADBannerView.h"
    #import "GADBannerViewDelegate.h"
    #import "GADRequest.h"

If all that wasn’t awesome enough, we also removed the need to include the -ObjC linker flag in your project! Just drag in the library to start using it.

If you’re using CocoaPods, you automatically get all of these changes by referencing version 7.0.0 of the Google-Mobile-Ads-SDK podspec. Since this is a major release, make sure you update your Podfile to grab major version 7:

pod 'Google-Mobile-Ads-SDK', '~> 7.0'

Introducing new friendly DFP APIs

Version 7.0.0 also adds first-class support for custom targeting and category exclusions in a brand new DFPRequest object.


DFPRequest *request = [DFPRequest request];
request.customTargeting = @{
  @"gender", @"male"
};
request.categoryExclusions = @[@"cars", @"sports", @"pets"];

New to 7.0.0 is the ability to roadblock creatives and prevent competing ads in mobile apps. The SDK does this by adding an updateCorrelator method with similar functionality to the same method in GPT: 


[DFPRequest updateCorrelator];

All subsequent DFP ad requests will use the new correlator value until the correlator is updated again. Requests with the same correlator are capable of being roadblocked, and will not serve competing ads.

For more information on the DFP API improvements, see the developer docs.

Dropping support for iOS 5

With this release, we are also dropping support for iOS 5. We’ve noticed that almost all users are running iOS 6 or higher, and dropping support for older versions means the library can take advantage of the newer iOS APIs and offer more stability for you and your users. The SDK now supports only iOS 6.0 and up.

Sounds great! Where can I download the SDK?

As always, the latest SDK can be found on our downloads page. If you have any technical questions about these updates, drop us a line on the forum.

 - , Mobile Ads Developer Relations

Updated RMF Schedule and Non-Compliance Fees on the AdWords API Rate Sheet

If you're a software developer that builds tools for agencies or other advertisers to manage AdWords campaigns, or if you use the AdWords API to provide reporting dashboards to clients, please take a minute to review these updates.

In May 2014, we extended the deadline for all Required Minimum Functionality (RMF) until December 31, 2014. Now that the extension period has expired, we’d like to explain how we’ll review RMF in 2015. If you’re subject to RMF, you’ll receive emails in the days and weeks ahead explaining the details, so please be sure to update your contact information in the AdWords API Center of your MCC account.

At a high level, the review will look like this: first you’ll confirm your contact information and help ensure the demo account for your tool is working properly. Then, if any requirements are missing from your tool, you’ll receive a detailed non-compliance email followed by a 30-day “fix-it” period to bring your tool into compliance. We hope this will provide sufficient time to address any shortcomings. After that, if you’re not in compliance after the 30-day fix-it period, you’ll be subject to non-compliance fees (which have been reduced) as specified on the updated API rate sheet. And if you’re still not in compliance within 120 days of receiving the initial non-compliance email, your token may be downgraded to Basic Access. Throughout the process, we’ll send you reminder emails of the important milestones and deadlines.

Please note again that we’ve reduced the fees associated with non-compliance. You can see a full list of changes to the API rate sheet.

If you have any questions please feel free to reach out directly to the API Review Team.

-- AdWords API Team

New features in AdWords scripts

We have added the following new features in AdWords scripts.

Bidding

You can now manage bids for your campaigns, ad groups and criteria in AdWords scripts. Support is also provided to retrieve and update shared bidding strategies in your account. The current release allows you to use MANUAL_CPC, MANUAL_CPM, BUDGET_OPTIMIZER or CONVERSION_OPTIMIZER as bidding strategies; and set CPC, CPM or CPA bids to your biddable entities. See our guide and code snippets to learn more about this feature.

Display criteria

You can now manage the following display criteria through AdWords scripts: keywords, placements, topics, audiences. Check out our code snippets for usage examples.

New ad extensions

You can now manage review and callout extensions for your campaigns and ad groups in AdWords scripts.

If you have questions or feedback about these features, let us know on our forum.

Anash P. Oommen, AdWords Scripts Team

Upcoming removal of AdWords legacy PLA objects

Now that all existing legacy Product Listing Ads campaigns have been upgraded to Shopping campaigns, some cleanup is in order. On March 23, 2015, we'll be removing criteria and ad objects related to AdWords legacy PLA campaigns, specifically:
  • All AdGroupCriterion objects for Product criteria (Product Targets):
    • Criteria that accrued impressions will be marked REMOVED. These objects will continue to appear in API reports in v201406 and v201409.
    • Criteria that did not accrue impressions will be permanently deleted. These objects will no longer appear in API reports.
  • All ProductAd objects for legacy Product Listing Ads campaigns will be marked DISABLED. These objects will continue to appear in API reports in v201406 and v201409, regardless of whether or not they accrued impressions.

Actions required

If you are interested in capturing the components of legacy Product Listing Ads campaigns that did not accrue impressions, retrieve that information before March 2015 using the appropriate services (e.g., AdGroupCriterionService, AdGroupAdService).

Learn more

If you haven't started using Shopping campaigns, check out the following resources. Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

- Josh Radcliff, AdWords API Team

Announcing the launch of account-level tax and shipping and improved product dates in Content API for Shopping

We are pleased to announce the launch of API support for account-level tax & shipping for the Google Content API for Shopping v2. Previously, this was only available on the Merchant Center UI. This API feature will match the configuration options available in the UI.

This launch enables you to programmatically specify default tax and shipping rules that apply to all products within an account through the Accountshipping and Accounttax services. Specifically, the account-level tax and shipping rules apply to all products, but can be overridden by item-level tax and shipping settings, which are in the Products service. Note that products' taxes and the Accounttax service are only applicable to products targeting the US.

The shipping settings allow you to set-up different shipping services using calculation methods ranging from flat rate to carrier-based rates, and you can use rate tables or decision trees to specify conditions on price, weight, and delivery location. Please see our guide and reference documentation: Accountshipping service, Accounttax service, which will help you get up and running with these new services.

The second addition is new date fields that many have asked for. The Productstatuses service in v2 of the API has 3 new fields:
  • creationDate: the date that a product was first inserted into the Merchant Center.
  • lastUpdateDate: the date that the product was last updated. This may be the same as the creationDate. It also reflects updates from Inventory service.
  • googleExpirationDate: the date that your product will expire in Google Shopping. By default, products usually expire after 30 days of no updates.
Also, the Products service contains an expirationDate field. This field represents the date as submitted by the merchant. The field is optional, and can be useful for setting an expiration date that is closer than 30 days away.

Another use case of expirationDate is for products you wish to expire later than 30 days away; for example, 40 days away. As you continue to resubmit the product, this date will remain unchanged, and the product will not expire until the expirationDate is reached. Remember that if you don’t resubmit a product within a 30-day window, it will automatically expire, regardless of what date you set in expirationDate. There is no equivalent v1 field to expirationDate.

On that note, please be aware that these new features are not available in v1, which is deprecated and will be sunset at the end of February 2015.

We hope these new features will simplify your process for configuring tax and shipping settings, and clarify your product expiration dates. As always, feel free to reach out on the developer forums if you have any questions.   —Yufeng Guo, Shopping Developer Relations

Mobile Ads SDK Interstitial Best Practices

As you know, interstitials are a great way to monetize your app while still providing a great user experience, with natural "commercial breaks" in your user flow. However, interstitials can take a while to load, and we know that this can make it tricky to implement since you must explicitly call loadAd() before calling show().

A common mistake is to call interstitial.show() in the onAdLoaded() callback. This makes the show() call not dependent on the app state, but on the asynchronous loading. Since the developer doesn't control when the onAdLoaded() callback happens, this provides a terrible user experience; the ad will show as soon as it's finished loading, which could be in the middle of another user interaction. This can result in policy violations due to accidental clicks.

Instead, we recommend loading the ad earlier in the lifecycle of the application, then polling interstitial.isLoaded() to see if the ad is ready to be shown. If it isn't ready, we recommend moving to the next state in the application.

We provide an example of proper interstitial loading in our sample "Impossible" game. When the game begins, we call loadAd() on the interstitial. When the user loses and clicks the button to try the game again, we check to see if the ad is loaded with isLoaded(). If it is, then we show an ad before starting the new round. Otherwise, we show a toast message that the ad isn't loaded and begin a new round.

This example focuses on the Android experience, but the same ideas apply to iOS. We hope our new interstitial example can help you create the best user experience as you integrate the Mobile Ads SDK into your apps. Check out this video for more on interstitial best practices. And as you're adding interstitials to your app, hit us up with technical questions on our developer forum!

 - , Mobile Ads Developer Relations

Reducing Google Play services’ impact on APK size

Like any Android library, the Google Play services SDK impacts the final size of applications that include it. Good developers care about the size of their apps, so today we’d like to show you two ways that you can leverage the Android plugin for gradle to reduce the APK size of applications that include Google Play services.

  1. Split JAR Architecture

    Beginning with Google Play services 6.5, additional maven artifacts have been added to the Google Repository that contain single domains of functionality. This means that you can include just those portions of Google Play services that your app uses. For example, here’s how to configure gradle to incorporate the JAR that contains functionality relating to ads:


    dependencies {
        compile 'com.google.android.gms:play-services-ads:6.5.+'
    }

    That line instructs gradle to include everything Mobile Ads developers need, with the exception of the IMA SDK JAR needed for IMA applications.

    Please note that if you currently initialize Mobile Ads SDK banner ads via XML layout files, you should continue including the full Google Play services artifact. See this blog post for more information.

  2. Shrink Resources

    The Android gradle plugin supports the ability to automatically exclude unused resources during the build process via the shrinkResources gradle property. To take advantage of this in your release builds, just add “shrinkResources true” to your build.gradle file’s release configuration:


    android {
        buildTypes {
            release {
                minifyEnabled true
                shrinkResources true
            }
        }
    }

    Note that the shrinkResources property requires that minifyEnabled be set to true as well, though that’s already a good practice for release builds.

Both of these techniques are quick to implement, so consider giving them a try. In testing, the use of shrinkResources and the new, split JAR maven artifacts reduced the APK size of our Interstitial Example by 1.2MB -- almost 50%!

If you have questions about these techniques and how to put them to work in your applications, visit us on the Mobile Ads SDK forum or the IMA SDK forum.

 - , Mobile Ads Developer Relations

Bulk Upload in AdWords Scripts

AdWords scripts now support bulk changes to your account through uploading data in CSV format. You can upload data from a CSV file on Google Drive, a Google spreadsheet, a Microsoft Excel spreadsheet, or construct a bulk upload request in your script at runtime.

AdWords scripts currently support the following operations for bulk upload:
  • Campaign management: You can create, edit or delete campaigns, ad groups, keywords and text ads using bulk upload. You can also edit existing ad group criteria, ads and product groups.
  • Offline conversions: You can upload offline conversions to your account using bulk upload.
Learn more about this feature on our guide, and check out our code snippets for usage examples. If you have questions or feedback about this feature, let us know on our forum.

Anash P. Oommen, AdWords Scripts Team