When we’re not guiding a tiny bird across a landscape of pipes on our phones, we’re getting ready for our biggest-ever Developer Day at this year’s Game Developers Conference in San Francisco. On Tuesday 18 March, all the teams at Google dedicated to gaming will share their insights on the best ways to build games, grow audiences, engage players and make money. Some of the session highlights include:

  • Growth Hacking with Play Games
  • Making Money on Google Play: Best Practices in Monetization
  • Grow Your Game Revenue with AdMob
  • From Players to Customers: Tracking Revenue with Google Analytics
  • Build Games that Scale in the Cloud
  • From Box2D to Liquid Fun: Just Add Water-like Particles!

And there’s a lot more, so check out the full Google Developer Day schedule on the GDC website, where you can also buy tickets. We hope to see you there, but if you can’t make the trip, don’t worry; all the talks will be livestreamed on YouTube, starting at 10:00am PDT (5:00pm UTC).

Then from 19-21 March, meet the Google teams in person from AdMob, Analytics and Cloud at the Google Education Center in the Moscone Center’s South Hall (booth no. 218), and you could win a Nexus 7.

Posted by Greg Hartrell, Lead Product Manager


AdWords API users in the United States, United Kingdom, Germany, France and Spain who have been using call metrics with call extensions may be affected by a change we are rolling out starting on March 3rd, 2014.

Previously, the default was to enable call metrics when the TRACKED placeholder was not included as an AttributeFieldMapping in the CALL Feed. We will be updating how this works by enabling this feature only when specifically requested. You can still enable call metrics, if available in your country, when setting up the call extension or modifying an existing extension with this placeholder.

This change may affect your current call extensions. Any call extensions that have not explicitly enabled call metrics will stop collecting metrics starting on March 3rd. If you rely on call metrics data, you should make sure that all of your call extensions have explicitly enabled call metrics. If you were already setting this flag when creating call extensions in any version of the API, then no further action is required.

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.

TL;DR Projects using the AdSense Management API should now check for accounts with multiple AdSense/AdX accounts and let users pick instead of using the default namespace, as it will be disabled for some accounts.

API users with access to more than one AdSense or AdX accounts will receive an error when using the default namespace due to cases of ambiguity. We expect a very small percentage of users to have this problem, as this functionality is restricted to a limited set of accounts.

To avoid complications, make sure you're not using the default account namespace adclients.list, adunits.getAdCode, etc. and specify an account ID for every call. For that, use accounts.adclients.list, accounts.adunits.getAdCode, etc. You’ll find the whole list of calls in the API reference pages.

The flow you should always use from now on is:
  • Authenticate
  • Call accounts.list
  • Show a publisher account picker if there's more than one account
  • Do the rest of the requests using the account ID
If you have questions about this change or need help with updating your code, please let us know on the AdSense API forum or our Google+ page.

We previously announced that we are removing the ability to set contentBid for “Display Network only” campaigns in the AdWords API on February 18th, 2014. However, based on developer feedback, we are moving this date to March 3, 2014.

If your application modifies ad group bids for Display-only campaigns, then your application may be affected by this change.

To make sure your applications and scripts work properly, you should make the following changes to your application code before March 3, 2014:
  • Modify your code to set the default ad group bid instead of contentBid for “Display Only Campaigns”.
  • Clear out the contentBid field for “Display Only Campaigns” by setting it to zero so that AdWords will start using the default ad group bid when serving your ads.
  • If you store campaigns in a local data store, re-sync your data store with AdWords to pick up the updated default bid values.
If you have any questions about this change or the AdWords API in general, you can post them on our developer forum. You can also follow our Google+ page for updates about the AdWords API.


We have added a few new helper methods to the Account class. The new methods are

  • getLoginEmail: Returns the email address of the account's first login user.
  • getName: Returns the name of the account.
  • getStatsFor: Returns stats for the specified predefined or custom date range.

We hope you enjoy these new features. If you have questions or feedback, let us know on our forum!


AdWords API users take note - an upcoming AdWords feature may affect your conversion-related AdWords API reports.

Starting February 25th, 2014, AdWords users will be able to change the conversion counting option between All Conversions and Unique Conversions. The conversion counting option is defaulted to All Conversions - when left as the default option, your conversion related values in the reports will not change.

How will this affect your reports?

If an AdWords user manually changes the conversion counting option in the AdWords UI from All Conversions to Unique Conversions, then the following conversion-related report columns will reflect the counting option selected by the user across all reports:

  • ConversionManyPerClick
  • ConversionRateManyPerClick
  • CostPerConversionManyPerClick
  • ValuePerConvManyPerClick
  • ValuePerConversionManyPerClick
  • ConversionManyPerClickSignificance
  • ConversionRateManyPerClickSignificance
  • CostPerConversionManyPerClickSignificance

When the conversion counting option is changed, the values in these columns will no longer be many-per-click, but it will reflect the counting option selected by the user. Please see the help center article for specific examples of how counting Unique Conversions differs from counting All Conversions.

AdWords API currently doesn't allow you to retrieve counting option associated with the conversion tracker. It will be available in the next release of the API.

In AdWords API v201309 we released a new Google Click ID field (GCLID) in the Click Performance report. Originally, this field value was limited to 26 characters. We will be extending the maximum length of this field in order to support improvements to our advertising system. Starting March 31st 2014, the value of GCLID can be up to 100 characters long.

Since this value is used in many client systems, we’re giving you advance warning of this change. Make sure your log, storage and redirecting systems can handle the extended size of the GCLID value.

Note: as a result of this change, the Click Performance report will only be available for dates up to 90 days before the time of a request. If you need the older click data, download and store these details before March 31st, 2014.

If you have any questions about the change, reach out to us on the forum or via the Google+ page.


Since joining Google Play services back in October 2013, Google Mobile Ads has added support for the following products:

  • AdMob
  • DoubleClick for Publishers
  • DoubleClick Ad Exchange

The new Google Mobile Ads APIs also offer additional features that the standalone Android SDK doesn’t have:

  • The new library has full support for the Android Advertising ID, and is compliant with the latest Google Play Ad Policy.
  • Google Play services offers automatic service updates via the Google Play store, so you get the benefit of always being on our latest and greatest mobile ads library without the hassle of having to update your apps.
  • The DoubleClick Ad Exchange JavaScript adapter is now included in the Google Play services library. This means you have one less dependency in your application, and you can be sure that the adapter will always be compatible with future Google Play services updates.

As part of the Google Play services 4.2 update, we are deprecating the standalone Android SDK in favor of the Google Play services library. The deprecation allows us to focus our development efforts on Google Play services and offer additional exciting features going forward. Here is the deprecation timeline:

  • On August 1, 2014, the Play Store will stop accepting new or updated apps that use the standalone Google AdMob SDK. The standalone SDK does not use the Advertising ID, and will therefore be non-compliant with the Google Play Ad Policy on this date.
  • We will stop offering technical support for questions specifically related to the standalone Android SDK on August 1, 2014.
  • Ad serving through the standalone SDK will continue to work after August 1, 2014.

There are currently no plans to stop serving ads through the standalone SDK, but we strongly encourage you to update your apps sooner rather than later to avoid the August 1, 2014 deadline. Note that the Google Play services library still supports the same devices -- you can still serve ads through this library even on devices that don’t have the Google Play store installed.

Be sure to refer to our migration guide to help you upgrade. If you have any questions about the deprecation or how to upgrade, post them on our forum. You can also stay tuned to ads-related SDK updates on the Google Ads Developers +Page.

In the recent DFP API releases, we announced the addition of more tables to the PublisherQueryLanguageService, starting with Line_Item and Ad_Unit. These tables are an alternative to retrieving entities from their respective services’ get***ByStatement methods. They allow you to retrieve sparse entities containing only the fields you’re interested in. For example, the following select statement retrieves the first page of only the ID and name of line items that are missing creatives.
SELECT Id, Name from Line_Item WHERE IsMissingCreatives = true LIMIT 500 OFFSET 0
In this blog post, we’ll go over some situations where this feature can be utilized to speed up entity retrieval times from hours to minutes.

Entity synchronization

The first major use case that benefits from these new tables is entity synchronization. For example, if you’re synchronizing line items on your network into a local database, you’re most likely using LineItemService.getLineItemsByStatement and hopefully taking advantage of the LineItem.lastModifiedDateTime field to only filter out line items that have changed since the last time you synchronized. But even with lastModifiedDateTime, this synchronization can still take a while, depending on how many line items you have on your network, and how complex their targetings are. If you don’t need to synchronize all the fields in your line item objects, you may be able to use the Line_Item PQL table to perform this synchronization instead.

If you do need to synchronize fields not yet available in the Line_Item table, such as targeting, you can still take advantage of this table for computed fields that don’t affect lastModifiedDateTime, such as LineItem.status. What you can do is synchronize your line items as usual with getLineItemsByStatement filtering on lastModifiedDateTime. Then update your local statuses with selected line item statuses from the Line_Item table (a very quick process):
SELECT Id, Status from Line_Item LIMIT 500 OFFSET 0

Match tables for reports

Local copies of line item information can also be used as match tables to construct more detailed reports. Sometimes, you may want more information in your reports than what is currently available as a dimensionAttribute. For example, if you run a report by line item ID, you may also want other line item information like isMissingCreatives to show in the report. Because LineItem.isMissingCreatives is unavailable as a DimensionAttribute, you can create a local match table containing line item IDs and additional columns to be included in the report. Then you can merge this match table with the report by the line item ID to obtain a report with those additional columns.

For example, let’s say you run a report with the following configuration:
The report in CSV_DUMP format looks something like this:
Dimension.LINE_ITEM_ID, DimensionAttribute.LINE_ITEM_COST_TYPE,
1234567, CPM, 206
1234568, CPD, 45
1234569, CPD, 4
To also include LineItem.isMissingCreatives in the report, you would fetch a match table and save it (as a CSV file for example) by retrieving ID and isMissingCreatives from the Line_Item table.
SELECT Id, IsMissingCreatives from Line_Item LIMIT 500 OFFSET 0
Full examples of how to fetch match tables are available in all our client libraries. For instance, Python’s is here. Then using a script or a spreadsheet program, merge the match table with the report to produce something like this:
Dimension.LINE_ITEM_ID, DimensionAttribute.LINE_ITEM_COST_TYPE,
    Column.AD_SERVER_IMPRESSIONS, LineItem.isMissingCreatives
1234567, CPM, 206, true
1234568, CPD, 45, false
1234569, CPD, 4, false
If you have any questions on these new PQL tables, or suggestions on what PQL tables you want in the next release, please let us know on the API forum, or on our Google+ Developers page.

Hello students!
We're now a few months into the AdMob Student Challenge. By now many of you have probably made some headway on your app, but aren't completely sure about how you want to integrate AdMob. Today we'll give you some tips on best practices for integration.


In general, ad placement should work with the flow of your app. Banners can be placed at the bottom of a screen containing another view, as elements placed in a ListView (as long as you don't show more than one banner on screen at once!) or other places that work with the current layout of the screen.
On the other hand, interstitials should be placed at a natural break in your flow from screen to screen - for example, in between game levels. You can see more examples of ad integration in our Ad Catalog app.

Event-based Action

If you want to track the different lifecycle events of an AdView object, you can use an AdListener. This allows you to not only track, but also take action in onAdOpened(), onAdClosed() and other methods. You can see an example of an AdListener in the Ad Catalog app, and the basic AdListener behavior in this sample app.


Another fun thing to do is create Custom Events, which allow you to serve your own ads in the ad space. For example, if you know your user's birthday, you could deliver a Happy Birthday message instead of an ad on that day. Custom Events give you a lot of flexibility with your ad space, and we're excited to see how you use them.

For additional controls, such as location and ad color, check out our docs. And if you have any SDK-related questions, you can ask other AdMob developers (including me!) for help on our forum.
Remember, using AdMob is a requirement to submit your app for the student challenge. We're looking forward to your submissions and hope to see some innovative uses of the AdMob SDK!

As part of the latest Java client library, the SelectorBuilder utility class facilitates the creation of the generic selectors that are needed to query the AdWords API. Because of the nature of the generic selectors, some boilerplate code is needed in order to instantiate the selector objects properly. Also the way that a selector is configured depends on the implementation that is being used.

With the new SelectorBuilder, you have less boilerplate code and can still chain method calls and edit selectors without needing to know all the details of the generic Selector class. Let’s take a look at some examples comparing the current way of creating selectors, and the way it is with the utility class.

NOTE: Using the SelectorBuilder class to create selectors does not restrict the user from editing the selector after it has been built.

Some examples

The SelectorBuilder class is just a builder-like object that can be chained in order to simplify the code needed to create the predicates and fields used with the API. Let’s now take a look at how the selector is created in the GetCampaigns example (available on GitHub):
    SelectorBuilder builder = new SelectorBuilder()
       .fields("Id", "Name")
You still need to pass all the field names as strings, but all the boilerplate code involved in setting everything on the selector is handled by the SelectorBuilder. More than that, the methods have the same signature for Axis and JAX-WS.

NOTE: To add a new field to the selection, you must call the method fields passing all fields that were used before, plus the one that you want to add:

       // new field to the selection
This will return the same Selector as previously, but with the field status added to the selection. (IMPORTANT: The previously created Selector DOES NOT change when making additional method calls to the builder).

All configurations available in the selector can be set using the SelectorBuilder utility. Looking at the GetKeywords example, there is sample code on how to add predicates to the selector:

    SelectorBuilder builder = new SelectorBuilder()
       .fields("Id", "AdGroupId", "MatchType",
       .in("AdGroupId", adGroupId.toString())
       .equals("CriteriaType", "KEYWORD")
More examples are available in the client library repository in GitHub.

Some additional considerations

It is important to remember that the builder returns a Selector, so all its accompanying features are still present, even if you use the builder to create it.

SelectorBuilder makes available all possible predicate operators as utility methods:

       .equals(“”, value)
       .notEquals(“”, value)
       .contains(“”, value)
       .containsIgnoreCase(“”, value)
       .doesNotcontain(“”, value)
       .doesNotContainIgnoreCase(“”, value)
       .in(“”, collection)
       .notIn(“”, collection)
       .greaterThan(“”, value)
       .greaterThanEquals(“”, value)
       .lessThan(“”, value)
       .lessThanEquals(“”, value);
There are also additional ordering, paging and date range methods:

       .forDateRange(start, end);
The start and end dates are Joda-Time dates, so it is easy to add and remove days from them. The builder will parse dates according to the API format.

If you have any questions about the client libraries, you can post them on our forums. Check out our Google+ page for client library and Ads APIs updates.

Gustavo M. P. Moreira, Ads API Team

As your networks grow, so does their data in the DFP servers. While previously making requests for tens of line items, you now find yourself requesting tens of thousands of line items. Of course, with more data comes more responsibility - your requests are now taking longer and the response sizes have increased accordingly. You notice that some of your requests are now returning with 'ServerError.SERVER_ERROR.' Things might seem hopeless, but don’t panic...

Many of these problems can be solved with pagination! What does this mean from a developer's perspective? In a large number of implementations, what we've noticed is that applications will make requests with empty statements to calls like this:
getCreativesByStatement(" ")
getLineItemsByStatement(" ")
getOrdersByStatement(" ")
getCustomTargetingValuesByStatement(" ")
These requests do not limit the size of the returned result set. In doing so, the applications are asking for the data of every single object belonging to that service. When you’re talking about thousands of line items, each with their own distinct custom targeting, the amount of data will often cause the request to fail.

The fix? When creating PQL statements to query for DFP objects, you’ll find our client libraries all utilize a recommended page size (500) to limit your queries to smaller batches using the 'LIMIT' keyword, which should feel familiar for most who've used SQL. After the first page has returned successfully, you can then use the 'OFFSET' keyword to retrieve each subsequent page until your request returns nothing. If the calls still seem to take a long time to return a page or fail at this point, you can try to use a smaller page size.

If you use pagination to retrieve data, you not only get the benefit of increased reliability, but also protect yourself should something go wrong. Instead of retrying the entire request from the start again, you can simply pick up where you left off.

To see how to implement pagination logic, you can find examples in each of our client libraries:
If you have any questions on using pagination with your queries, post them on the API forum or Google+ Developers page.

 - , DFP API Team