Category Archives: Google Ads Developer Blog

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

Proguard and AdMob mediation

If you’re an Android developer who uses ProGuard to post-process builds, you already know the improvements it can make to APK size and speed. Just as handy, though, is its ability to obfuscate your compiled code by stripping out debug information and renaming classes, methods, and fields to generic identifiers. It’s a great way to discourage reverse-engineering of your application. If you’re an AdMob publisher who uses mediation, however, you need to take special care when configuring ProGuard in order to avoid obfuscating some of the code used in the mediation process.

AdMob mediation needs two classes to maintain their original names in your final APK: AdUrlAdapter and AdMobAdapter. If either of those has been renamed by ProGuard, it can cause the SDK to incorrectly return “no fill” responses for the AdMob demand in your mediated ad units.

The good news is that it’s easy to avoid this problem. Just add the following two keep options to your ProGuard configuration file:


-keep class com.google.ads.mediation.admob.AdMobAdapter {
    *;
}

-keep class com.google.ads.mediation.AdUrlAdapter {
    *;
}

These options instruct ProGuard to avoid renaming the two classes, and to leave the names of their fields and methods unobfuscated as well. With the original names intact, the mediation system will be able to instantiate them dynamically whenever they’re needed, and your otherwise obfuscated application won’t miss out on any AdMob impressions.

The third-party networks your app mediates may also need certain classes exempted from obfuscation. Be sure to check with those networks to find out if they have recommendations for ProGuard configuration.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.

 - , Mobile Ads Developer Relations tags: android, admob_mediation, mobile_ads_sdk

Reporting changes in AdWords API v201509

AdWords API v201509 introduces some changes to reporting columns, particularly Clicks. Recently, AdWords introduced new columns called Engagements and Interactions. It also added reporting columns related to video campaigns such as VideoViews, which have previously been unavailable via API reporting. AdWords API version v201509 has updated its reporting to match these changes.

The new Interactions field, available in API performance reports, can be thought of as the main action a user takes with the ad format: clicks for text ads, engagements for Lightbox ads, and views for video ads. Previously, views for video ads were not returned in API reporting, so having access to this data is new.

Prior to v201509, the Clicks field always included both clicks and engagements. Starting in v201509, the Clicks field includes only click actions, like clickthroughs to a landing page or clicks to call. This means that clicks on video ads, which are unpaid, will be included in this field. However, engagements for Lightbox ads will not be counted.

If measuring performance across multiple ad formats, you might consider using Interactions to view the total number of primary user actions on ads, all in the same column. Clicks, Engagements, and VideoViews are available as well for more fine-grained reporting by ad format.

The table below summarizes the changes in each field for various ad formats.

Field
v201506
v201509
Clicks
Text ads: clickthrough to a landing page

Lightbox ads: hover to expanded ad format
Text ads: clickthrough to a landing page or clicks to call

Lightbox ads: clickthrough to a landing page

Video ads: clickthrough to a landing page
Engagements
N/A
Lightbox ads: hover to expanded ad format
VideoViews
N/A
Video ads: view
Interactions
N/A
Text ads: clickthrough to a landing page or clicks to call

Lightbox ads: hover to expanded ad format

Video ads: views

Please note that reporting in v201506 and previous versions is unaffected; they return the same data that they always have, represented the same way. This means that when comparing the data you receive from older versions of the API to user interface reports, or to v201509 reports, the numbers will not directly match up. Video-related stats will still be excluded from v201506. The Clicks column in v201506 will match the Interactions column from v201509 if you subtract out video interactions.

For ease of reporting, it’s recommended to migrate to v201509 as soon as possible.

Keep in mind these aren’t the only reporting changes in v201509 — for more details on conversion-related reporting changes, please see the release notes.

If you have any questions about this or other aspects of the AdWords API, please contact us via the forum or the Ads Developers Plus Page.

- Michael Cloonan, AdWords API Team

Important changes for gaming publishers using the IMA HTML5 SDK

In the coming weeks, we’ll be making changes to the way the IMA HTML5 SDK handles AdSense and Ad Exchange non-linear and full slot ads. To facilitate these changes, we’re adding a new API: AdsRequest.forceNonLinearFullSlot. Gaming publishers are required to set this parameter to true to ensure that all ads returned to your player are correctly rendered as full slot ads. This change is planned to go live the week of November 30th. Keep an eye on our release notes for the exact date as the change is released.

As always, if you have any questions, feel free to contact us via the support forum.

 - , IMA SDK Team

IMA HTML5 – changes to non-linear and full slot ads for AdSense and Ad Exchange

In the coming weeks, we’ll be making changes to the way the IMA HTML5 SDK handles AdSense and Ad Exchange non-linear and full slot ads. You should be aware of these changes to ensure that your video player behaves as expected once the changes have taken effect.

Definitions

A non-linear ad is a static or animated ad that displays over the video content during content playback. These are also sometimes referred to as “bottom-third” ads, because they typically take up the bottom third of the video player.

A non-linear ad.

A full slot ad is a static or animated ad that usually appears before or after the content, occupying the entire view area. It renders a close button that when clicked closes the ad and, if rendered before the content, triggers the content to start.

A full slot ad.

Current behavior

Currently, non-linear ads are rendered as expected, but full slot ads are also rendered as non-linear ads. So instead of pausing, the video continues to play underneath them while they take up a large portion of the video display.

New behavior

With the new behavior, any non-linear AdSense or Ad Exchange ad greater than 90 pixels in height will be rendered as a full slot ad. This means it will take up the entire video display. When the user clicks the close button, the content will start.

We will also be adding a new UI to these full slot ads which includes a countdown timer and a skip button. You should remove any custom UI elements you’ve added for full slot ads to ensure there are no conflicts with this new UI.

Lastly, to ensure that your ads are rendered properly, make sure your AdDisplayContainer is rendered on top of everything else and takes up the full size of your video player.

Full slot ad with the updated UI.

Testing the changes

If you’d like to test these changes, you can load the test version of our SDK by replacing your load of ima3.js with ima3_test.js. This is a watermarked test binary that changes frequently and without notice; it is not intended for use in production.

As always, if you have any questions, feel free to contact us via the support forum.

 - , IMA SDK Team

New ad UI and click behavior for IMA HTML5 SDK

Starting this week, we’re going to incrementally roll out a change in the way the IMA HTML5 SDK handles an ad’s UI.

We will be adding a Learn More button to Ad Exchange and AdSense ads on both desktop and mobile. Clicking on the button will take the user to the advertiser’s site, while clicking elsewhere on the ad will pause or resume it. This is a change from the existing behavior, where clicking anywhere on the ad opens the advertiser’s site.

The new ad UI.

This change will also be rolling out to all mobile web ads that do not use custom click tracking. Note that ads that have no UI before the change will gain a UI with this change. This will allow our mobile web behavior to be consistent with native mobile behavior.

If you have any questions about these changes, feel free to contact us via the support forum.

 - , IMA SDK Team

Upcoming changes to inactive ad group CPA bids in AdWords

In preparation for improvements to CPA bidding in AdWords, starting October 26, 2015, we'll perform a one-time removal of inactive ad group-level CPA bids.

What's an inactive ad group CPA bid, you ask? An ad group-level CPA bid is inactive if the ad group's effective bidding strategy is not a CONVERSION_OPTIMIZER strategy. This includes CPA bids on ad groups whose effective bidding strategy is TARGET_CPA, since the target for such ad groups is specified at the strategy level. The effective bidding strategy is the ad group-level strategy, if specified. Otherwise, it’s the bidding strategy set at the campaign-level.

How this change impacts the AdWords API

After the one-time removal of inactive CPA bids, there are two categories of ad groups you'll want to review:
  • Ad groups from which inactive CPA bids were removed: For these ad groups, the AdGroup object will no longer have a CpaBid in the bids attribute of its ad group-level BiddingStrategyConfiguration. Therefore, if you change the effective bidding strategy of these ad groups back to a CONVERSION_OPTIMIZER strategy, you will have to add a new CpaBid to the ad group’s BiddingStrategyConfiguration for your ads in the ad group to serve. You will only have to make this change once.
  • Ad groups you change from TARGET_CPA to CONVERSION_OPTIMIZER: AdWords will no longer copy the TargetCpaBiddingScheme.targetCpa value to a CpaBid on the ad group's bidding strategy configuration. Therefore, you will not automatically get the TARGET_CPA strategy bid if you transition to CONVERSION_OPTIMIZER. If the ad group's bidding strategy configuration already has a CpaBid, then CONVERSION_OPTIMIZER will use that bid. Otherwise, you will have to add a new CpaBid to the ad group BiddingStrategyConfiguration before ads in your ad group will serve.

How this change impacts bidding

Since the CPA bids being removed are inactive, this change will have no impact on bidding or ad serving.

What you should do

If you are interested in inactive CPA bids for CONVERSION_OPTIMIZER bidding strategies, download the current bids using AdGroupService before the removal date.

More bidding resources

Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

- Josh Radcliff, AdWords API Team

Support for v201509 reports in AdWords Scripts

We have added support for AdWords API v201509 reports in AdWords scripts.

Changes to conversion columns

This release includes several changes that coincide with the recent announcement on conversion columns. Several reporting columns were removed and new columns were added. See the AdWords API release notes for more details.

Video and multi-channel reporting

We are now including statistics and metrics for AdWords for video and TrueView video campaigns in several reports. This includes a new Video Performance Report. Note that reports will only include data for newly created video campaigns in AdWords campaign management or campaigns that were migrated from AdWords for video.

We have also added new reporting columns that help multi-channel advertisers more easily manage reporting for specific campaign types like Search, Shopping, Display, and Video.

See Video and multi-channel reporting changes for more details.

Miscellaneous reporting changes

  • All columns that have a List or Map return type now return data in JSON format.
  • Shared set type is now returned as an ENUM instead of an Integer in SHARED_SET_REPORT and CAMPAIGN_SHARED_SET_REPORT.
  • Several new columns have been added to existing reports.
  • A few duplicate columns in existing reports were removed.
  • MatchType and MatchTypeWithVariant columns were renamed to QueryMatchType and QueryMatchTypeWithVariant in PAID_ORGANIC_QUERY_REPORT and SEARCH_QUERY_PERFORMANCE_REPORT.

See Miscellaneous reporting changes for more details.

If you use API versioning in your reports, you need to modify your code to use v201509 as shown below. If you don’t use API versioning, no code changes are required. 


var report = AdWordsApp.report(query, {
   apiVersion: 'v201509'
});
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 API Team

Using the Google My Business API to manage your location extensions

Last year, we announced upgraded location extensions, a more efficient way to manage and use business locations in ads by linking Google My Business and AdWords accounts. To help you manage your business locations more easily at scale, we’re now releasing the Google My Business API.

Google My Business will be the central repository for managing your business locations. The creation of manual location extensions as feed items through the AdWords API has been deprecated and will sunset in Q2 2016. Please update your code before March 31, 2016 to avoid being impacted by this transition.

Supported features
The first version of the Google My Business API allows you to read, create, update and delete unverified business locations. Supported attributes are name, address, contact numbers, URL, categories, and business hours. Unverified locations can be used as location extensions in AdWords, but have to be verified to be eligible to show up on Google Maps.

Future releases of the Google My Business API will support additional functionality that will allow you to fully manage your location data across Google Ads and Maps.

Getting started with the Google My Business API
If you already use the AdWords API and manage more than 50 business locations, you can apply for access to the Google My Business API. Once granted, you will have access to the Google My Business API documentation and you can follow the steps there to get started. For accounts with 50 or fewer locations, please use Google My Business Locations for now.

Linking locations to accounts, campaigns or ad groups as location extensions
Users managing multi-location businesses (chains) must have a separate Google My Business account for each chain for bulk-verification. If you already manage locations under bulk-verified accounts in Google My Business today, you can link those accounts to AdWords to have your location extensions in sync.

For developers managing AdWords accounts with a large number of locations for small and medium businesses, we recommend creating one Google My Business account as a central repository for all locations. Each physical location should be created only once. If different owners and managers are involved per location or for sets of locations, we suggest using Business Accounts.

Once the AdWords accounts are linked to your shared Google My Business account, the locations will be available as feed items in AdWords. You are responsible for creating a CustomerFeed and using an appropriate matching function to make sure only locations that actually belong to the customer are linked to their related AdWords account. You can use CampaignFeeds or AdGroupFeeds for additional filtering based on campaigns or ad groups.

The best way to filter locations from a shared Google My Business account is to create location labels through the Google My Business API and use a matching function that uses these labels for selection. For example, you can label each location with its AdWords Customer ID in Google My Business and use these Customer ID labels for filtering in AdWords. Or you can label each location with a unique ID, as long as you keep track of these IDs.

Please see our guide for managing location extensions for further details, which also includes an end-to-end code example.

Migration of existing location extensions
If you are using manual location extensions through the AdWords API, we recommend migrating your locations to Google My Business before March 31, 2016. After this date, the creation of manual location extensions will sunset. All unmigrated locations stored in AdWords will be auto-migrated to Google My Business at a later date. Further details about the timeline and process will be announced in this blog.

Timo Bozsolik, AdWords API Team

AdWords API v201502 sunset reminder

AdWords API v201502 will be sunset on November 12, 2015, after which all v201502 API requests will begin to fail. This version was deprecated on June 25, 2015. If you are still on v201502, we recommend that you migrate directly to v201509 (released last week) and skip v201506. Please be sure to migrate soon to ensure your API access is unaffected.

We have prepared various resources to help with the migration: As always, if you have any questions about this migration, please contact us via the forum or the Ads Developers Plus Page.

- Michael Cloonan, AdWords API Team

Sunset of the v201408 DFP API

On Monday, November 30, 2015, in accordance with the deprecation schedule, v201408 of the DFP API will be sunset. At that time, any requests made to v201408 will return errors.

If you're still using v201408, now's the time to upgrade to the latest release and take advantage of new features like line item level reconciliation (see our guide here). To do so, check the release notes to identify any breaking changes, grab the latest version of your client library and update your code.

Some changes to look out for:

This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions. To be notified of future deprecations and sunsets, join the DFP API Deprecation Announcements group and adjust your notification settings.

 - , DFP API Team