Is your AdWords API client application still using ClientLogin? If so, you should start your migration from ClientLogin to OAuth 2.0 as soon as possible.

Your AdWords API client applications must be fully migrated to OAuth 2.0 before ClientLogin is sunset in June 2014, as previously announced. If you don't migrate by then, your client applications will fail -- they won't be able to access your MCC account or any AdWords account via the API.

How do I get started?

We have prepared a ClientLogin to OAuth 2.0 migration guide which includes:

• Detailed migration strategies based on use cases
• Code samples to automate parts of the migration
• Client library-specific migration videos, code, and pertinent OAuth 2.0 documentation

You don't want to worry about your applications failing, so get started now. For most developers with a single top level MCC, this migration will involve only a few configuration and code changes. But if you run into any issues with your particular application or AdWords accounts, you'll be glad you left plenty of time before the sunset to work things out.

We are here to help

If you run into any issues, or if you have any questions, please reach out to us on the AdWords API Forum.

- Ray Tsang, AdWords API Team

In v201311 we changed how the API returns locations to:

• More granularity in targeting 
• Streamlined code paths 
• Increased flexibility for handling location objects

Along with the update to location objects, we've also expanded the list of targetable locations far beyond what was previously available. If you look at new Geo_Target table - which replaces the individual City, Country, Metro, Postal Code, and Region tables - you’ll find that you now have far more control over where your ads will serve. In the past, the smallest location you could target was a city; now, you can target something as specific as an Airport.

Many of you have asked how to migrate from the deprecated PQL tables to the new Geo_Target table.

Instead of having a table for each geo locations type, we combine everything into a single table with the type defined as a new column. This not only makes things easier for you, it also allows us to add even more types of locations to target in the future without having to make new tables.

As far as how the old tables relate to the new Geo_Target table, the Country, City, Postal_Code, and Region tables will map to their respective namesake columns, with only the Metro table being different, now mapping to the more canonical DMA_Region. To see how simple it is to replicate the old behavior, look at this Python example that pulls down the targetable City locations.

If you’re not entirely sure how to break out your targeting into smaller geo locations, we’ve got you covered there too - instead of trying to make your own relational mapping between cities, metros, regions, and countries, the new Geo_Target table simplifies the task with the ParentIds field, which yields a list of parent location IDs that encompass a child location.

For the new year, make a resolution to switch over to the new Geo_Target table and reap the benefits thereafter.

 - Nicholas Chen, DFP API Team

When we launched the new DFP a couple of years ago, one of the major changes was a new API and accompanying support infrastructure. The DFP API brought many significant enhancements to DFP and is a core component of our overall offering. However, as our publishers and partners went through the upgrade process, they had to rebuild any DART API integrations from scratch. In addition, due to the rapid development cycle of DFP, we were pushing out new versions very quickly.

While the terms of service for our API call for only a 6-month window to support each version, to limit the impact to our developers, we've continued to support every version of the DFP API released to date -- that’s 12 and counting. While we've had a “soft” deprecation for older versions, we've only removed documentation - those versions have continued to run.

By the end of this year, all upgrades will be complete and the release schedule for the API will continue on a regular quarterly basis. Given the growing use of our API -- not to mention the growing number of versions we’re supporting -- we’ll need to begin hard deprecations for older versions. As a result, we’re introducing a new deprecation schedule and want to give all our developers enough time to plan for upgrades.

Going forward we are planning to deprecate each version one year after its release. This means at any time we’ll be supporting four versions. For example, when the Q1 release (v201402) comes out, we’ll deprecate support for the Q2 release of the previous year (v201302). That depreciation will be a “soft” one and it will still run until the Q2 release before being completely turned off; i.e. every version will be accessible for approximately 14 months.

In order to help developers adjust, we’ll be phasing in this new schedule. Our next scheduled release will be in Q1. On April 1st, 2014, we will be turning off v201206 and older, and putting v201302 and lower into “soft” deprecation. On August 1st, we’ll be turning off v201302 and older, and v201308 and v201306 will go into “soft” deprecation.

As of April 1st, 2014, these will be the only versions supported on DFP:

Version	State
v201402	Scheduled
v201311	Supported
v201308	Supported
v201306	Supported
v201302	Soft deprecated
v201211	Soft deprecated
v201208	Soft deprecated
v201206	Deprecated
v201204	Deprecated
v201203	Deprecated
v201201	Deprecated
v201111	Deprecated
v201108	Deprecated

As of August 1st, 2014, these will be the only versions supported on DFP:

Version	State
v201408	Supported
v201405	Supported
v201402	Supported
v201311	Supported
v201308	Soft deprecated
v201306	Soft deprecated
v201302	Deprecated
v201211	Deprecated
v201208	Deprecated

And finally, as of approximately a year from now, these will be the only supported versions:

Version	State
v201411	Supported
v201408	Supported
v201405	Supported
v201402	Supported
v201311	Soft deprecated
v201308	Deprecated
v201306	Deprecated

If you are using any version less than v201308 right now, you need to upgrade by August 1st, 2014 and if you are using any version less than v201211 right now, you should plan to upgrade in Q1 2014.

Our recommendation is to upgrade to v201311 now. This will delay your need to upgrade until Q1 2015.

Finally, just a reminder that v201311 is the last version to support ClientLogin and OAuth 1.0 authentication mechanisms. All future versions only support OAuth2. It’s also the last version supported by the old Java client library which means there’s no support for new API releases next year. When v201311 is deprecated in Q4 of 2014, everyone will need to be on a newer version using OAuth2 and the new Java client library.

If you have any questions, please let us know on our Ads Developer Google+ page.

-- The DFP API Team

We’ve noticed some confusion around which identifier to use after upgrading to the new AdMob front-end, so we’d like to take this opportunity to explain the terminology and the format of the identifier that the Google Mobile Ads SDK expects for serving AdMob ads (DFP and Ad Exchange identifier formats remain unchanged).

Previously, we referred to this identifier as “publisher ID” if you were serving AdMob only, which represented a string of 15 hexadecimal characters starting with the letter “a”, such as a141234567890ab. If you were using mediation, we referred to the identifier as “mediation ID”, which represented a string of 16 character hexadecimal characters such as e123456789012345.

In the new AdMob, this identifier is referred to as “ad unit ID” and has a format of ca-app-<publisherId>/<slotname>. The term publisherId now represents a unique account identifier with the format pub-xxxxxxxxxxxxxxxx (16 digits) and slotname identifies a unique ad space and has the format nnnnnnnnnn (10 digits).

If you configure the Google Mobile Ads SDK with an incorrectly formatted ad unit, the ad request will fail with the error message: "Cannot determine request type. Is your ad unit id correct?". Make sure your ad unit has the format ca-app-pub-xxxxxxxxxxxxxxxx/nnnnnnnnnn without any whitespace.

Note that passing just the publisher ID from your new AdMob account, for example pub-1234567890123456, will return the error message above. Instead, you should find the full ad unit ID you wish to use from your apps in the Monetize tab on apps.admob.com.

As always, we’re available on our forum to answer any technical questions you may have about Google Mobile Ads. You can also find us on Google+.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

Version 1.4 of the AdSense Management API is now available and comes with new features mainly based on suggestions and requests from developers:

• List your AdSense account payments: Now you can list your payments in the corresponding currency.
• Dismiss alerts: If an alert is dismissible, you can now call the delete method that will hide it in the API and AdSense web interface.
• Added start and end dates to the reports response: Specially important if you’re using relative dates when generating reports (today, yesterday, firstDayOfMonth-1m, etc.), the response now includes the date range you requested.

If you are new to the API, check out the new getting started video that covers everything you need to know to start your integration with the AdSense Management API.

Remember to visit the AdSense API forum or our Google+ page if you need any help implementing these new features!

- Jose Alcérreca, AdSense API Team

After launching the new AdMob in May, we’ve been excited about how the platform could enable us to build new tools to benefit your apps business. Today, we’re announcing two new features; ad network optimization and impression goal campaigns for house ads, that can help you earn more from your apps.

Ad network optimization

Many app developers use more than one ad network to improve fill rate in their apps. Yet the challenge of earning the most revenue from networks remains. Allocating impressions to the best-performing networks often means manually comparing CPM reports, a method that doesn’t capture the most recent CPM.

Ad network optimization is a free service that makes the process a whole lot easier; it evaluates the CPM of each network in your mediation stack, and dynamically reorders them so the network with the highest CPM serves an ad to your app.

Once set up, AdMob continually obtains the freshest possible CPM value from each ad network and compares them. In addition, you can enable the AdMob network to bid alongside other networks on each impression. Ad network optimization currently supports AdMob, InMobi, JumpTap, and MdotM, with more ad networks coming soon.

Impression goal campaigns

AdMob house ads are an essential way to promote other apps to your users, using your own inventory, free of charge. Now, with impression goal campaigns, you can set a limit on the number of impressions you want to serve in a house ads campaign.

Impression goal campaigns are served via AdMob Mediation and take precedence over other ad sources in the mediation stack. Having more control over your house ad impressions means you can more intelligently cross-promote apps from your portfolio, while balancing the revenue you earn from mediated networks. Alternatively, you can work out a deal directly with an advertiser outside of AdMob, to run their campaign in your app.

Both of these features are only available through the new AdMob, so if you haven’t upgraded your account yet, we recommend you do.

Check out the new AdMob help center to get started with ad network optimization and impression goal campaigns.

Posted by Vishay Nihalani, Product Manager, AdMob

[Update 2/17/2014: Based on developer feedback, we have moved the date of this change back to March 3, 2014.]

We're making a change to how the contentBid setting works in “Display Network Only” campaigns. Here's some background on the change and how it might affect you.

Currently, if you have a campaign that targets only the Display Network, then you can use a CpcBid at the adgroup level to specify a default bid and a display network bid override for content networks. In the past, we've allowed users to specify a contentBid in a "Display Network Only" campaign type, even though contentBid is useful only for "Search & Display Networks" campaign type. This allowed users to switch between "Search & Display Networks" and “Display Network only” campaign types without modifying their bids.

Since display campaigns have become so much more specialized over time, we've recently removed support for switching “Display Network only” campaigns to other campaign types. This makes contentBid setting obsolete for “Display Network only” campaigns, so we are removing the ability to set contentBid for “Display Network only” campaigns in AdWords API. The default bid value will be used for serving your ads on Google Display Network.

What this means for you

If you do not set contentBid at the adgroup level for a “Display Network only” campaign, this change will not affect you.

Starting on February 18th, 2014, if you set contentBid for a “Display Network only” campaign, then you will start receiving a ReadOnlyError.READ_ONLY error for all versions of the API. You can use the fieldPath of the ApiError object to identify the operation triggering the error.

To avoid getting errors, you should:

• modify your code to set the default adgroup bid instead of contentBid
• clear out the contentBid field to make sure that AdWords will start using the default adgroup 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're still using contentBid to set ad group display bids in “Display Network only” campaigns within a few days of February 18th, 2014, we plan to do a one-time migration of those bids to become your ad group default bid. This migration is intended to ensure your ads serve with the correct bid; you must still make sure your code is able to handle ad group bids on the Display Network properly.

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.

Anash P. Oommen, AdWords API Team

Editor's note: re post from Inside AdSense blog. --Stan Grinberg

As the holidays approach, you can expect an increase in smartphone usage, especially in activity with gaming apps. Each year around this time, millions of new mobile devices are activated and billions of apps are downloaded. A recent AdMob study* also revealed that downloading and playing gaming apps are users’ top priority when getting a new smartphone, which represents a special opportunity for developers.

A new strategy for game-app developers can help them make the most of this increase in usage. Game developer Izumi Artisan used this strategy to increase his revenue by 60%, and so today we’ll share the details on how he achieved these results.


Step 1) Create a strategy guide for your game and post it on your website
Game guides, strategy manuals, and walk-throughs have become commonplace for gamers looking to get the edge or just take the easy path through a tricky section of a game. As a result, numerous third party game-strategy sites have popped up, and are attracting users in mass numbers.

This represents a great opportunity for you as a game developer, as you can create your own strategy or walk-through guide and host it on your website. There are many examples of successful game guides on the Web that you can use as a model when creating your own. The guides will vary in structure and length depending on the format of the game, so we suggest browsing a few to find the most suitable format. If there are already third-party guides competing for your users’ attention, try releasing the “Official” guide to separate yourself from the rest of the pack.

Step 2) Monetize your new website with AdSense
Creating great content and putting it on the Web is an important step for those looking to generate income online. To start earning revenue from your online content you can use AdSense to show highly relevant ads on your website.

With AdSense, advertisers will bid against each other to show their ads next to your content. The ads that appear are highly targeted, so they’re likely to be interesting to your visitors. AdSense also offers a number of great features including customization options to control the appearance, placement and type of ads that will show up on your site, as well as the ability to restrict the subject matter of the ads.

If you’re not already an AdSense publisher, sign up for a free AdSense account.

Step 3) Use house ads in AdMob to drive users to your new website
One of the most difficult pieces of building a successful website is attracting visitors. As a game developer, you have the benefit of an existing and engaged audience -- your users. By taking advantage of this built-in audience you can quickly generate demand for your new web content...you just have to point them in the right direction.

You can do this by using AdMob’s house ad feature, which lets you display your own promotions to your users at no cost. By creating a “house ad” promotion for your new website and displaying it in an appropriate section of your game (i.e., on the home screen, or in-between game play, etc.), you can easily generate awareness for your web content while preserving a good experience for your users. The great part is, you won’t need to push a new version of your app since the house ad can be updated directly within the AdMob interface.


Sign up for an AdMob account here. It’s free.

Be sure to make the most of the app usage increase that comes with the holiday season by trying this strategy. Have these tips worked for you? Do you have other tips to share? Let us know in the comments!

Posted by Max Sack - Publisher Advocate


*Mobile Apps Consumer Study, AdMob and Parks Associates, Oct 2013