Category Archives: Google Ads Developer Blog

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

New geo targeting options in AdWords API

Building on our AdWords announcement in November 2013, v201402 of the AdWords API supports geo targeting for areas with particular places of interest or income levels. These are useful for reaching customers based on the types of places they visit or demographic information based on their location. Please check the support site for more information, and to determine if these new targeting options are available for the country you would like to target. Within the API, these new criteria types are called LocationGroups and can be applied on a campaign to affect all of its ads.

The targeting can be set up using a matching function, which you may already be familiar with from other parts of the API. There are three new operand types for LocationGroups matching functions. Each matching function will pair one of either IncomeOperand or PlacesOfInterestOperand with a GeoTargetOperand, which is always required, to target income brackets or places of interest within a specific geographical region.

For example, to target airports in New York City using the Java client library, you would set up a matching function using a PlacesOfInterestOperand and a GeoTargetOperand, like this:

LocationGroups locationGroup = new LocationGroups();
Function matchingFunction = new Function();
matchingFunction.setLhsOperand(new FunctionArgumentOperand[] {
new PlacesOfInterestOperand(null, PlacesOfInterestOperandCategory.AIRPORT)
});
matchingFunction.setOperator(FunctionOperator.AND);
matchingFunction.setRhsOperand(new FunctionArgumentOperand[] {
new GeoTargetOperand(null, new long[]{ 1023191L }) // ID for NYC
});
locationGroup.setMatchingFunction(matchingFunction);
You can look up geo target IDs via the LocationCriterionService or in the documentation. You can also see fully functional, runnable code demonstrating this criterion type in each client library (Java, PHP, .NET, Python, Ruby, Perl).

If you have any questions about this or anything else related to the AdWords API, please contact us on the forum or via our Google+ page.

Bidding on the DoubleClick Ad Exchange with the Google Cloud Platform

Real time bidding (or programmatic buying), is one of the fastest growing methods of buying and selling ads online, and is predicted to account for 25% of all display spending by next year. Marketers are embracing this model as it allows them to connect to audiences at scale quickly and we've been making ongoing investments to help them grow their programmatic businesses. Today we're continuing those investments by introducing rs.functionality that enables marketers to conduct their real-time bidding on the DoubleClick Ad Exchange (AdX) directly from Google Cloud Platform.

Speed is critical to success in programmatic buying and many exchanges, including the DoubleClick exchange, require that bidders respond to an ad request within a certain time limit in order to preserve the real-time nature of the marketplace. Real time bidding transactions typically happen within 100 milliseconds from a user visiting a website. Starting today, Ad Exchange users hosting on Google Compute Engine will always receive 100 milliseconds for bid request processing and free network transit from Google Cloud Platform to all Ad Exchange trading locations. This effective increase in processing time, combined with the strengths of Google Compute Engine will make Google Cloud Platform a great choice for DoubleClick Ad Exchange buyers.

To ensure that AdX customers have the best possible experience on Google Cloud Platform, we now offer complimentary Gold support for Google Cloud Platform to qualified customers hosting their bidding infrastructure for AdX. You can find more information on this offer as well as instructions on how to sign up here.

For customers who would like to jump start their real-time bidding using a framework provided by Google, Open Bidder provides you the real-time bidding infrastructure. You can sign up for access to Open Bidder here.

For those looking to build their own bidders without the use of our Open Bidder framework, we’ve also published a white paper on how to build real-time bidding solutions on Google Cloud Platform.

If you are interested in learning more about Open Bidder, real-time bidding on DoubleClick Ad Exchange, and bidder hosting on Google Cloud Platform, please join us at an AdX Developer Day in Google’s New York City or San Francisco office on April 9. You can register for the event here.



* For trading on the DoubleClick Ad Exchange Hong Kong trading location, please contact Ad Exchange Sales.

Introducing IMA SDK Downloads for FlashDevelop and Flash Builder

Using FlashDevelop or Adobe Flash Builder and looking to get started with the IMA SDK? Now it's even easier with new downloads specifically for FlashDevelop and Flash Builder 4.7.

Check out our guide to getting started with the Flash IMA SDK with these IDEs.

Once you've gone through the guide and are up and running with a compiled .swf, what's next? Check out the Flash IMA SDK Quick Start Guide and Flash IMA SDK API Reference docs to learn more about the features of the Flash IMA SDK.

If you have any questions about the Flash IMA SDK let us know on the IMA SDK forum. Follow our Google+ page for other announcements and updates.

Readying AdMob for the Second App Economy with New Features: Livestream from GDC Today

According to Gartner, more than 130 billion apps will be downloaded onto phones and tablets in 2014, and most of them will be free. At the same time, revenue from apps is expected to grow by over 200% in the next 4 years. That may sound contradictory, but the reason has been clear to many developers for some time: while the first app economy was predominantly focused on paying for apps up front, we’re now seeing the rise of a second app economy, the era of free apps and incremental payments.

In this second app economy, the currency of success has altered significantly, centered on three critical areas:

  • Understanding audiences: Developers should be able to segment their audiences based on in-app behavior and turn data into useful insights for better monetization.

  • Growing in-app purchase revenue: According to Gartner, soon in-app purchases will account for almost half of all app store revenues, but this model requires a sophisticated approach from app developers and the right tools haven’t been available.

  • Maximizing ad revenue: Developers shouldn’t have to worry about managing ads; ads should optimize themselves, in real time, so developers can focus on other important parts of their business.

To help every developer succeed in this new economy, the AdMob team will be at the Game Developers Conference today to share four announcements.

1. Google Analytics now directly available in AdMob.
We introduced mobile app analytics in mid 2012 and there are hundreds of thousands of app developers using it already. We've now built Google Analytics directly into AdMob so developers can understand how people are using their app, segment them based on behavior in just a few clicks, then act on those insights. For example, the Google Analytics ecommerce report shows key insights into in-app purchases: top items sold, overall revenue and average order value. Now that Google Analytics is built directly into AdMob, developers can have a holistic view on their monetization based not only on revenue from ads but also on in-app purchase performance. All these functionalities have been incorporated into the updated Home tab in AdMob, making it a one-stop shop for all your performance reports.

2. In-App Purchase Ads.
To help developers promote in-app purchases to users in a more relevant way, we're also introducing in-app purchase ads. A developer can use these ads to promote in-app items at the right time to the users who are most likely to make a purchase, while still showing AdMob ads to those who aren't. Segmentation tools enable developers to quickly find these users, and then in-app purchase ads can be used to build relevant interstitial ads to reach them. For example, a developer can discover which of their users began playing their game in the last 48 hours, and promote a ‘welcome pack’ of extra lives at a 50% discount. This creates a more customized experience for users and can help prolong engagement. A developer can also choose where to place these interstitial ads in their app, and they can appear in either portrait or landscape mode.

In-App Purchase Ad

3. Ad network optimization and Live CPM.
If a developer is using more than one ad network to monetize their apps, a mediation tool helps to manage them. However, these tools may not optimize for the highest revenue. To solve this, ad network optimization obtains the most up-to-date CPMs from ad networks in the AdMob mediation stack, and requests ads from the highest paying one.

Live CPM goes one step further to ensure developers earn the most money from their ad impressions. When a developer uses AdMob to monetize, they get real-time access to all of Google’s demand sources, including programmatic demand, via our integration with DoubleClick Ad Exchange. For each ad request, Live CPM compares the highest CPM a developer can get from Google’s demand sources, with the CPM they could get from other networks in their mediation stack. If a higher-paying ad is available from Google’s demand sources, it will serve that ad over lower-paying CPMs offered by the other networks. App developer iHandy Inc. began using Live CPM in February this year. Many apps' revenues increased at different rates, and certain apps achieved a 200% increase.

4. The App Developer Business Kit.
The App Developer Business Kit is an in-depth website designed to help app developers understand ways to build a successful business. For example, there are detailed chapters about building an app, different ways to earn money, and options for marketing your app. You can also check out the interviews with developers, read case studies and view market insights from AdMob surveys which give developers a head start into building apps for global users. For example, did you know that a third of smartphone gamers in China have spent money in apps to personalize characters?

Tune into Google’s GDC livestream today at 10AM PST. We have sessions for game developers all day, and the AdMob talk is from 12-12.30PM PST.

Posted by Jonathan Alferness, Product Management Director, Google

Changes to conversion counting in AdWords scripts

We recently announced changes to conversion counting and column names in AdWords. We are making the following changes to AdWords scripts to match the updated naming conventions:
  • We have deprecated the getConversions and getConversionRate methods in the Stats class. These methods will work for now, and will return the “converted clicks” and “converted click rate” values as per the new naming conventions.
  • We have introduced two new methods, namely getConvertedClicks and getClickConversionRate to replace the deprecated methods. Please use these methods in your new scripts.
  • We are keeping the column names unchanged in reports available through AdWordsApp.reports(). However, the meaning of values returned by these columns will reflect the new methods of counting conversions.
    • The following columns refer to “converted click” columns under the new naming convention.
      • Conversions
      • ConversionRate
      • CostPerConversion
      • ValuePerConv
      • ValuePerConversion
      • ConversionSignificance
      • ConversionRateSignificance
      • CostPerConversionSignificance
    • The following columns in AdWords scripts reports refer to the “conversion” columns under the new naming conventions. These columns will either return “All Conversions” or “Unique Conversions” values depending on the user preference for counting conversions. By default, this preference defaults to “All Conversions”, so these reporting columns will continue returning the same values as they do today, unless the user changes this preference to “Unique Conversions”.
      • ConversionManyPerClick
      • ConversionRateManyPerClick
      • CostPerConversionManyPerClick
      • ValuePerConvManyPerClick
      • ValuePerConversionManyPerClick
      • ConversionManyPerClickSignificance
      • ConversionRateManyPerClickSignificance
      • CostPerConversionManyPerClickSignificance
If you have questions or feedback about this change, let us know on our forum or via the Google Ads Developers Google+ page.

Anash P. Oommen, AdWords Scripts Team

New feed-based location extensions in v201402 of AdWords API

As previously announced, AdWords API v201402 lets you manage your upgraded, feed-based location extensions in addition to your campaign location extensions. Upgraded location extensions are linked to your Google Places for Business account and offer significant benefits over manually entered location extensions. Most importantly, once you configure your upgraded location extensions you don't have to worry about keeping them up to date with changes in your Google Places for Business account -- AdWords does it for you!

As mentioned in our detailed guide to upgraded location extensions, you can use the AdWords API to set up your extensions in a few easy steps: There are a few key differences between feeds with systemFeedGenerationData ("location feeds") and other feeds you may have created for sitelinks, app or call extensions.

Type or Attribute
Location Feeds
Other Feeds
Required

Defines the link between your AdWords and Places for Business accounts.
Not applicable
Not applicable

AdWords maintains the feed item attribute -> placeholder field relationship for you.
Required

You maintain the feed item attribute -> placeholder field relationship.
Automatically managed by AdWords.
Maintained by you via the FeedItemService
Required
Not applicable
Optional

Only needed if you want more control over which businesses from your Places account are used for location extensions on a particular Campaign.
Required
Optional
Optional
Only needed if you want more control over which businesses from your Places account are used for location extensions on a particular AdGroup.

Just as for other feed types, you can get stats for a location feed's extensions from the PLACEHOLDER_FEED_ITEM report.

This is just a quick overview of the AdWords API support for upgraded location extensions. For more information, check out our feed services guide for location extensions and the accompanying code sample in each client library (Java, Perl, PHP, Python, Ruby, .NET).

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

Introducing a new type of feed for AdWords API: Review extensions

Review extensions, which let you show accolades from reputable third parties right in your search ads, were introduced last year. We have now made this feature available for the AdWords API in v201402.

Creating review extensions is the same as creating sitelinks as described in this guide. The only differences are:
  • The different placeholderId for FeedMappingService. As shown in the feed placeholders page, the placeholderId for review extensions is 8.
  • A different set of Feed attributes for FeedService. A review extension consists of four attributes:
    • Text (String): Either an exact quote or paraphrase from a third-party source that appears beneath your ad
    • Source (String): Name of the third-party publisher of the quoted or paraphrased review you’re using in your review extension
    • Source URL (URL): Landing page of the third-party website where the quoted or paraphrased review is located
    • Format (Boolean): Indicates whether your review is formatted as an exact quote from the third-party source, or if you’re paraphrasing. Setting to true means your review is formatted as an exact quote, false means paraphrasing.
Here is the Java code to create a Feed for review extensions. Code examples in other programming languages are available as part of the client libraries.

FeedAttribute textAttribute = new FeedAttribute();
textAttribute.setType(FeedAttributeType.STRING);
textAttribute.setName("Text");

FeedAttribute sourceNameAttribute = new FeedAttribute();
sourceNameAttribute.setType(FeedAttributeType.STRING);
sourceNameAttribute.setName("Source Name");

FeedAttribute sourceUrlAttribute = new FeedAttribute();
sourceUrlAttribute.setType(FeedAttributeType.URL);
sourceUrlAttribute.setName("Source URL");

FeedAttribute exactlyQuotedAttribute = new FeedAttribute();
exactlyQuotedAttribute.setType(FeedAttributeType.BOOLEAN);
exactlyQuotedAttribute.setName("Exactly Quoted");

Feed reviewExtensionFeed = new Feed();
reviewExtensionFeed.setName("Feed For ReviewExtension from API");
reviewExtensionFeed.setAttributes(
new FeedAttribute[] {textAttribute, sourceNameAttribute,
sourceUrlAttribute, exactlyQuotedAttribute});
If you have any questions about this feature or the AdWords API in general, you can post them on the developer forum. You can also follow the Google+ page for updates about the AdWords API.

Reminder: AdWords API v201306 and Ad Exchange Buyer SOAP API v201306 to be sunset on March 31

As we have previously announced, if you're using the AdWords API or Ad Exchange Buyer SOAP API v201306, please note that support for this version will end on March 31st, 2014. If you are still using v201306 after that date, all requests will fail and your application will cease working until you migrate to a supported version. You can reference either the v201309 or v201402 migration guides for help upgrading to one of these versions.

In addition, remember that ClientLogin support is deprecated and you will have to migrate to OAuth 2.0 in order to authenticate starting in version v201402. It may be best to get this out of the way now, because with the sunset of v201309 on July 21st, 2014, all support for ClientLogin will go away and OAuth 2.0 will be required to access the API. Please reference our OAuth 2.0 migration guide for help with this process.

If you have any questions about this upcoming change or anything else related to the AdWords API, please contact us on the forum or via our Google+ page.

A new way to access our Ads SOAP APIs through Python

The Ads APIs Python client library, adspygoogle, has been around for quite some time, supporting versions of Python as old as 2.4 but capping out at 2.7. We’ve been getting more and more feedback recently that our users want Python 3 support. Also, many of adspygoogle’s dependencies are dated and no longer officially supported. We heard you, and with these items in mind...

A New Client Library

A completely new client library — googleads — is now available for Python 3 as well as Python 2.7. The new library has several advantages over our existing library:

  • Most of your code from the previous Python library will work with minimal modifications, listed below and in our migration guide.
  • The dependencies are all hosted on PyPI, so you do not need to use the --allow-external or --allow-unverified flags at install.
  • The constructors and attributes in the new library give you more control over client objects; for example, you can easily switch out OAuth 2.0 credentials and manage multiple accounts.
  • Data types are retained. Whereas adspygoogle uses strings for everything, googleads can send and receive numbers, booleans, datetimes, etc.
  • The library is more integrated with the Python standard library; for example, you can use the built-in logging framework to log SOAP messages.
  • The library is built on top of a fork of suds and allows users who are familiar with suds to take advantage of that library’s features.

Migrating to the New Client Library

Existing Python users can retain almost all of their logic working with the objects defined in our APIs. An important difference is that your responses from the API are now objects returned by suds instead of dictionaries. The objects support using dictionary syntax to retrieve values but you cannot use dictionary methods on them. Most importantly, this means that .get() and .update() are no longer supported. Where in adspygoogle you may have done this:

response = inventory_service.GetAdUnitsByStatement(statement.ToStatement())[0] ad_units = response.get('results')

You will now need to do this:

response = inventory_service.getAdUnitsByStatement(statement.ToStatement()) ad_units = response['results'] if 'results' in response else None

Some more minor changes that need to be made include changing your code to use the new methods for instantiating client and service objects and using the exact method names from our APIs, which are generally lower camel case.

For more information on migration, check out the migration guide we have posted in the new library’s wiki section.

The googleads library will be the primary focus of development moving forward. The existing adspygoogle library is now in maintenance mode but we will continue to add support for new AdWords and DFP API releases through December, 2014.

If you find any bugs, have a patch to contribute or just a feature request, please feel free to file an issue on the issue tracker.

Upcoming changes to call conversion settings in AdWords scripts

We recently announced the following changes to call metrics with call extensions in AdWords:
  • Call conversion tracking will be disabled by default starting March 3, 2014
  • Call conversion duration threshold will be sunset on April 7, 2014
Since these changes are incompatible with AdWords scripts, we have deprecated the following methods related to these features in AdWords scripts: These methods will be sunset on April 7, 2014. To make sure your scripts work properly, check any code that uses these methods, and fix them before April 7, 2014.

If you have questions or feedback about this change, let us know on our forum. You can also follow our Google+ page for updates about the AdWords scripts.