Smart banners are a handy thing for publishers. You can drop an AdMob smart banner into a layout or storyboard, and it’ll stretch or squeeze itself at runtime until it’s just the right size for the device, then request an ad to match. They’re a great feature with all the extra work hidden under the hood.

If you’re building an Android mediation adapter or custom event, though, things aren’t quite as simple -- after all, you’re under that hood, too! A common rough spot for developers is retrieving a smart banner’s size. Because the Google Mobile Ads SDK uses constants to internally represent a smart banner’s height and width, the getHeight and getWidth methods of a smart banner’s AdSize will return those constants (they’re negative numbers, so they’re quite hard to miss). That means relying on calls to getHeight and getWidth to determine a smart banner’s true size isn’t a workable strategy.

So how should adapter and custom event developers calculate sizes correctly? By avoiding getHeight and getWidth, and instead asking for pixel counts using getHeightInPixels and getWidthInPixels, two other methods offered by AdSize. You can scale their return values according to the device’s metrics and end up with the same kind of DPI values returned by getWidth and getHeight for other ad sizes. Here’s a code snippet that shows how it’s done:

// Get the raw pixel counts.
int widthInPixels = size.getWidthInPixels(context);
int heightInPixels = size.getHeightInPixels(context);

// These metrics include screen density, which is what we’re after.
DisplayMetrics displayMetrics = Resources.getSystem().getDisplayMetrics();

// These are values you can send to your mediated network’s SDK.
int widthInDpi = Math.round(widthInPixels / displayMetrics.density);
int heightInDpi = Math.round(heightInPixels / displayMetrics.density);

Once you finish the math, you’ll have proper DPI values that can be sent to whichever network you’re mediating. The calls to getHeightInPixels and getWidthInPixels require a valid Context, but you can use the one provided as a parameter to the requestBannerAd methods in MediationBannerAdapter and CustomEventBanner.

Now you know the best way to gauge the size of a smart banner! Use this approach and it’ll help keep your mediation running smoothly.

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


Recently, we announced the availability of native ads for apps in DFP. Here, we’re going to introduce you to creating native creatives with the DFP API using the ads Java client library. A native creative consists of a set of assets (headline, image, etc.) which are sent to mobile apps for custom rendering in their own code (see our Android and iOS developer guides for details).

Native creatives are actually just another type of template-based creative. While the DFP UI abstracts this, in the API you create a native creative using a TemplateCreative with the system-defined native template ID. The creative template IDs available in your network can be retrieved by the getCreativeTemplatesByStatement method in the CreativeTemplateService. You can also view these IDs in the UI under Delivery > Creatives > Native ad formats (see the ID below each native ad format name in the table). The native app install template ID is 10004400.

    TemplateCreative nativeAppInstallCreative = new TemplateCreative();

Because native creatives do not have a predetermined size, you need to set a placeholder size of 1x1.

    Size size = new Size();

Finally, specify a name and destination URL; this example is for the Pie Noon app:

    nativeAppInstallCreative.setName("Pie Noon native ad");

Settings specific to native creatives are set via template variables. An app install native creative requires the following unique template variable names to be set:

  • Headline
  • Body
  • Image
  • Price
  • Appicon
  • Calltoaction
  • Starrating
  • Store
  • DeeplinkclickactionURL

Note that creative template variables are case sensitive and those of type AssetCreativeTemplateVariableValue (“Image” and “Appicon”) must have a unique filename.

You can find the full Java example on how to create native creatives in our GitHub repository here. All of our other ads client libraries have similar examples.

As always, if you have any questions, feel free to drop us a line on the DFP API forums or the Ads Developer Google+ page.


Fall 2015 AdWords API Workshop registration is now open. Access the registration forms on the workshop website at

Once you choose a location we'll send you an email confirming your registration.

Workshops will be held on the following dates and locations:

  • New York City: October 20
  • San Francisco: October 22
  • London: October 27
  • Hamburg: October 29
  • Tokyo: October 29
  • Amsterdam: November 3

These workshops are technical in nature and are ideal for API developers. We hope to see you at these events. Register today!

If you have any questions about the AdWords API Workshops, you can post them on our forum. Check out our Google+ page for AdWords API updates.

We have added support for AdWords API v201506 reports in AdWords Scripts. This version adds support for FINAL_URL_REPORT, the Upgraded URLs-compatible replacement for the DESTINATION_URL_REPORT.

This version also introduces several changes to the reporting columns
If you use API versioning in your reports, then you need to modify your code to use v201506 as shown below. If you don’t use API versioning, no code changes are required.
var report =, {
   apiVersion: 'v201506'
If you have any questions about this feature or AdWords scripts in general, you can post them on our developer forum.

We are updating the referer of ad clicks to improve security and system reliability for users searching on Google. Starting within October, the referer for many ad clicks will only contain the Google domain from which the click occurred (domains like or This means that we will no longer be communicating specific paths such as “” or “”

While the referer will no longer differentiate Google’s organic search clicks from ad clicks, and in some cases may be absent entirely, there are still multiple strategies to track the origin of your clicks. Recommended strategies include: This change is a continuation of our general user security efforts. Users are safer when sites use HTTPS instead of HTTP, which is why we encourage the use of HTTPS. In fact, in August 2014 we began to use HTTPS as a ranking signal.

By default, browsers do not pass a referer from HTTPS sites to HTTP sites. To minimize advertiser disruption, we implemented a custom ads solution back when the Google search page migration to HTTPS took place. Now, many modern web browsers provide better control over referer behavior via the meta referer tag. This development is an improvement over our previously-implemented custom ads solution both in terms of reliability and latency.


The AdWords API Workshops are back, and the registration form and agenda will be available on the website soon: In the meantime, you may review the site Resources section for previous event presentations.

These workshops are a series of technical events, ideal for those who are working with the AdWords API.

Workshops will be held on the following dates and locations:

  • New York City - October 20
  • San Francisco - October 22
  • London - October 27
  • Hamburg - October 29
  • Tokyo - October 29
  • Amsterdam - November 3

Stay tuned and keep an eye on the website for more details on how to register.

--AdWords API Team

AdWords Scripts now support negative keyword and excluded ad placement lists, and the ability to share them across campaigns. Follow these links for implementation details and code examples: We have also released a new solution named Master Negative List that uses this feature to maintain a master list of negative keywords and placements for AdWords accounts. The list of negative criteria can be managed from a spreadsheet. Separate versions are available for AdWords accounts and manager accounts.

Special thanks goes to Terence Nip, who implemented this feature during his summer internship at Google.

Give this feature a try and let us know what you think! You can post your questions and feedback on our developer forum.