Last week we announced the release of Google AdMob SDK 6.0 with Ad Network Mediation. We’ve noticed some confusion on how to use a mediation ID instead of a publisher ID, so we’d like to explain the difference between the two.

A publisher ID is generated after adding a site/app and is used to request ads from the AdMob network. A publisher ID can request banners as well as interstitials, giving you the ability to use the same ID throughout your application to get AdMob ads. However, for better reporting, we still recommend that you use a different publisher ID for each ad placement.

A mediation ID is generated after creating a mediation placement. A mediation ID is used to retrieve the mediation configuration from the server so the AdMob SDK can make ad requests to other ad networks on your behalf. Unlike a site/app, a mediation placement requires you to define an ad format, for example a 320x50 banner. Trying to request an interstitial ad with a 320x50 banner mediation placement (and vice versa) will result in the following error:

iOS - Failed to fetch interstitial ad: Unable to request an interstitial when server configuration was for kGADAdSizeBanner.

Android - onFailedToReceiveAd(There was an internal error.)

Therefore, you’ll need to create multiple mediation placements if you want to use banners and interstitials in the same application with mediation.

Feel free to post any questions regarding the AdMob SDK or ad network mediation to our forum. Even better, if you’d like real-time responses, join us at our upcoming office hours hangout session.

Whether your ads are from AdMob or another source, the focus of your app should always be on delivering the best possible user experience. Ads should be an integral part of your design process, rather than an afterthought so you can ensure that ads complement rather than compete with your content.

Increase Coverage

When choosing where to place your ad units, remember only one ad can be visible on the screen anytime. If your application involves playing a game with the controls at the bottom of the page then it is advisable you place the ad at the top. If your application carries a lot of article pages make sure you implement an ad unit on each of the article pages, sometimes these pages can be forgotten once the main pages are being served.

Increase Fill Rate

Take advantage of the Google certified ad networks feature within your AdMob account. Opting in to AdSense Backfill could help your fill rate improve substantially and therefore positively impact your earnings. Once you have the latest AdMob SDK implemented, you can access additional ad inventory from the Google Ad Network. Remember:

The backfill feature is enabled per site ID

Ads served from the Google Ad Network will not respect the filter rules set by your site ID at this time.

Increase Competition

Increase competition by keeping your filter list small. Filtering decreases the number of ads that can appear, thereby decreasing your potential earnings as well. Blocking ad groups may have a negative revenue impact because blocked ads won't compete in the auction on your site, and therefore won't drive up potential earnings for that ad space.

Optimize your refresh rate to improve your click-through-rate

It is important to keep in mind that users need time to interact with your content and the ad within your application. An ad that refreshes too often can adversely affect your CTR, by not giving users a chance to view the ad and decide if they are interested in clicking it. We would recommend setting your refresh rate between 45s - 60s and this can be managed within the AdMob interface.

Increase Traffic

If your app doesn't immediately make the top 50 rankings on an app marketplace, you have plenty of promotional options.

Advertising can drive downloads and place your app in the top 50 of an app store, where you'll likely enjoy even more downloads from people browsing the store. Read more about Google's solution to help you get discovered through advertising.

Get featured: App marketplaces, ranking and review sites tend to highlight the most interesting and advanced app offerings. Try to make your app unique, see more on Android design.

Allow social sharing: When people reach a goal in the app (say, a game level) or find something interesting in the app, make it easy for them to share this information directly with their social networks.

Cross-promotion is another easy and often free way to drive more users to your app; this occurs when you target users of other apps or properties and promote your app. For more information on promotion check out the guidetotheappgalaxy.com.

We announced in a previous post an easier way to test with the DFP API. We've iterated quickly and improved on that solution and we are also setting a date for the shutdown of the sandbox.

Test Accounts
When we initially launched the new test networks, you had to create a new Google account if you had any type of DFP network associated with the account. We've lifted this restriction. Now each Google account is always allowed to create a single test network using NetworkService.makeTestNetwork(). This means you can use the same google account for production and test networks.

Sandbox Shutdown
Now that we've given you a bit of time to switch off of the sandbox environment, we're announcing that we are shutting it down on May 24th, 2012. This allows for another month of testing, but we hope you will migrate to the new test networks as soon as possible.

Happy testing and stay tuned for more DFP API blog posts. Don't forget to join us on our next Hangout and, as always, let us know if you want to see any new features or blog posts on our forum.

Mobile applications are now big businesses, but the developers behind them are forced to spend more of their time dealing with increasing complexity. They need to develop for different devices with different screen sizes, choose from a myriad of advertising networks, and manage varying rich media ad creative formats.

The new Google AdMob SDK 6.0 release for Android and iOS is designed to reduce the complexity that app devs are managing, freeing them up to focus on continuing to grow their great app into a great app business. With AdMob SDK 6.0, app developers can:

Use multiple ad networks
We recognize that many app devs work with several ad networks to maximize fill rates, and ultimately, revenue. AdMob SDK 6.0 makes it easier to do this with our free AdMob Ad Network Mediation solution which allows app developers to allocate inventory across many top 3rd party ad networks on a country-by-country basis. App devs will retain full control and choice over the ad networks they use with a single UI that features the best-in-class AdMob reporting. For more information on AdMob Ad Network mediation, visit the AdMob Help Center.

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.

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.

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.

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.

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.

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.

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.

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.

Initialization

Create 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:

Write 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:

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):

An 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:

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.