Google Ads Developer Blog: April 2012

Build a flexible app business with the latest AdMob SDK

Thursday, April 19, 2012

Get banner ads to be smart, regardless of screen size
New mobile device screen sizes pop up every day, but app developers shouldn’t have to worry about how banner ads will appear on different devices. AdMob SDK 6.0 eliminates this issue with the introduction of new banner ad formats that automatically expand to the full width of any smartphone screen, even in landscape mode. To learn how to implement these new banners, visit the AdMob Developer Site.

Serve more rich media ads
The lack of industry standards for mobile rich media ads has been a barrier for advertisers and made it challenging to app devs to run more of these engaging ads in their apps. The new AdMob SDK 6.0 is compliant with Mobile Rich Media Ad Interface Definitions (MRAID), a common API for mobile rich media ads running in mobile apps. This is a big step forward in reducing complexity as it establishes a standardized set of commands for developers creating rich media ads. It also means that advertisers will be able to build mobile rich media ads that can be served across networks regardless of device platform, application or technology used to display the media.

As we announced several weeks ago, the iOS version of the Google AdMob SDK no longer uses the universal device identifier (UDID). We are working toward a long-term solution that will benefit users, app developers and advertisers.

To learn more about how app devs can work with AdMob to build a great app business through monetization and promotion of their app, visit our new AdMob website.

Posted by: Chrix Finne, Product Manager, Mobile Ads

The Docs are Dead. Long Live the Docs!

Thursday, April 19, 2012

Recent visitors to any of the Ads API documentation pages will have noticed their shiny new appearance and a message to let you know the docs have moved to a new platform:

This move is much more than a skin-deep makeover. As we’ve blogged before, the new Google Developers platform is so named to reflect our focus on you, and not just on the tools we provide.Follow the links below to take a look at the full range of Ads API docs on Google Developers:

Google AdMob Ads SDK

AdSense Host API

AdSense Management API

AdWords API

DoubleClick Ad Exchange API

DoubleClick for Advertisers API

DoubleClick for Publishers API

Interactive Media Ads SDK

We’ll continue to try to improve the Ads API docs on Google Developers while, over time, Google Code returns to its original purpose as an open source project hosting service. Visits to the old Google Code docs will be redirected to the corresponding Google Developers docs throughout 2012, so be sure to update your bookmarks soon. If you have any questions about these changes please reach out to us through any of the Ads API forums or office hours.Lesley Burr, Ads Developer Relations Team

AdWords API - Updates in Ad Performance Report

Monday, April 16, 2012

Recently the Ad Performance Report and AdGroupAdService of the AdWords API were returning incomplete data from Dynamic Search Ads. The report and API service were not prepared to support this type of Ad, which resulted in the report returning an undocumented “Website Ad” type, and the service returning AdGroupAd objects with no set ad property. This issue was fixed as of March 20th. We apologize for any inconvenience this change might have caused.Note that even though Dynamic Search Ads are no longer returned in the Ad Performance Report, their performance data (i.e. impressions, clicks, conversions) is rolled up in reports such as the Account, Campaign and Ad Group performance reports.If you have any questions about this change please reach out to us in the forum or during one of our office hours hangouts.- The AdWords API Team

Changes to advanced location targeting

Monday, April 9, 2012

Last year we exposed advanced location targeting settings in the AdWords API, using the GeoTargetTypeSetting object. Based on customer feedback we are now rolling out a series of changes to improve the power and clarity of this feature. The full details of these changes can be found on the Inside AdWords blog, but some highlights are:

The advanced location targeting settings now apply to Display Network traffic in addition to Google Search and the Search Network traffic.

The default value of the exclusion setting will be more restrictive for new campaigns, taking into account both the physical location and the area of interest. In API terms, GeoTargetTypeSetting.negativeGeoTargetType will default to DONT_CARE for new campaigns. The value will not be updated for existing campaigns.

The AdWords web interface has reworded the language used to describe these settings. If you provide a user interface you may want to update your language as well.

If you have any questions about these changes please reach out to us in the forum or during one of our office hours hangouts.

- Eric Koleda, AdWords API Team

Processing updates in bulk with MutateJobService

Wednesday, April 4, 2012

The AdWords API is designed to handle a high volume of changes, and many services allow developers to submit a large number of operations in one request. Most of the AdWords API services are synchronous though, so the client sends the request to the server, waits for processing and receives the result back.

Unlike other services, the MutateJobService (MJS) is designed for an asynchronous workflow. This has the following benefits:

No need to manage connections for each job - the job is executed autonomously and the results can be retrieved when ready.
Multiple jobs can be submitted and executed in parallel. In fact, the service has no limit on the maximum jobs count.
Transient errors like 'CONCURRENT_MODIFICATION' are automatically retried with no extra requests necessary.
Workload is automatically balanced so you will never receive a 'RateExceededError' error.

Also, MutateJobService operations cost only 50% of usual operations units cost.

Using MutateJobService in existing applications

Replacing existing calls to synchronous services with calls to MJS is easy. In most cases you can just use the same operations array to submit a job. Once submitted, the application needs to check the job status periodically to see when it is complete. Once ready, the results can be retrieved with the getResult method.

Please see examples in Java, PHP, Perl, DotNet, Ruby and Python for more details.

Recommendations:

Don't poll for job status too often as this can result in RATE_EXCEEDED_ERROR error. We recommend pausing for 30 seconds between get requests with an exponential backoff.
For better throughput, fewer large jobs are preferred over many smaller jobs. Once a job is scheduled and is executing, its progress will be very rapid.
When submitting many jobs for the same customerID, overall operation throughput will be optimal if no two outstanding jobs will be modifying the same AdGroup. Making all your jobs touch all AdGroups can cause severe slow-down or even job failures.

Note: while the old BulkMutateJobService is still available we recommend to use the MutateJobService for all future developments.

MutateJobService is covered in more details in our video presentation: Efficient API Usage with the MutateJobService. As always, please feel free to ask any questions regarding the AdWords API on our forum or during scheduled office hours.

- Danial Klimkin, AdWords API Team.

Creating A GADBannerView Singleton in AdMob Applications

Tuesday, April 3, 2012

View controllers in iOS such as UITabBarController and UINavigationController allow users to navigate between screens quickly. Developers using these controllers often hesitate to create new GADBannerViews for each screen because the user may not spend enough time on each screen to see the ad, thus diluting their click-through rate (CTR). A nice alternative here is to use a singleton GADBannerView across the entire application. This blog post will outline the steps to get this up and running.InitializationCreate a class that wraps around GADBannerView to add some minimal functionality. We’ll call this class GADMasterViewController in our example. Define your header file to have properties similar to what’s below:@interface GADMasterViewController : UIViewController { GADBannerView *adBanner_; BOOL didCloseWebsiteView_; BOOL isLoaded_; id currentDelegate_; } You need to provide a static accessor method in your GADMasterViewController class:+(GADMasterViewController *)singleton { static dispatch_once_t pred; static GADMasterViewController *shared; // Will only be run once, the first time this is called dispatch_once(&pred, ^{ shared = [[GADMasterViewController alloc] init]; }); return shared; } You also need an init: method in GADMasterViewController. You can now initialize the GADBannerView normally. Presume the initialization gets called only once:-(id)init { if (self = [super init]) { adBanner_ = [[GADBannerView alloc] initWithFrame:CGRectMake(0.0, 0.0, GAD_SIZE_320x50.width, GAD_SIZE_320x50.height)]; // Has an ad request already been made isLoaded_ = NO; } return self; } Placing the AdWrite a method which takes a new view controller and places the GADBannerView into that view controller’s view hierarchy. Again, this code will go into GADMasterViewController. This will be called every time you want to display an ad inside a different view controller:-(void)resetAdView:(UIViewController *)rootViewController { // Always keep track of currentDelegate for notification forwarding currentDelegate_ = rootViewController; // Ad already requested, simply add it into the view if (isLoaded_) { [rootViewController.view addSubview:adBanner_]; } else { adBanner_.delegate = self; adBanner_.rootViewController = rootViewController; adBanner_.adUnitID = kSampleAdUnitID; GADRequest *request = [GADRequest request]; [adBanner_ loadRequest:request]; [rootViewController.view addSubview:adBanner_]; isLoaded_ = YES; } } At this point, putting an ad into a view that’s not the GADMasterViewController becomes extremely easy. The code can go into any view controller’s viewWillAppear: method (assuming the view conforms to the GADBannerViewDelegate protocol):- (void)viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; shared = [GADMasterViewController singleton]; [shared resetAdView:self]; } Forwarding Delegate NotificationsAn important note is that the AdMob SDK doesn’t let you change delegates after a request has been made. This means that if you switch view controllers after making an ad request, all GADBannerViewDelegate notifications will continue to be sent to the initial delegate (first view controller). A workaround for this is to make GADMasterViewController conform to the GADBannerViewDelegate protocol, then forward any notifications it receives to the correct view controller. This is the reasoning behind always setting currentDelegate_ in resetAdView:. Forwarding the notification takes minimal code. Here is an example of forwarding the adViewDidReceiveAd: notification:- (void)adViewDidReceiveAd:(GADBannerView *)view { // Make sure that the delegate actually responds to this notification if ) { [currentDelegate_ adViewDidReceiveAd:view]; } } With these easy steps, your application is set up to use a singleton GADBannerView. If you have any questions about this topic or the SDK in general, feel free to post them in our forum or come join us in our upcoming office hours.

- Raj Parameswaran, AdMob Team

Ads Developer Blog

Know Your AdMob IDs: Publisher vs Mediation

AdMob Optimisation Essentials

DFP API Test Network Update and Sandbox Shutdown