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:
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.
- Eric Leichtenschlag, AdMob Team
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.
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.
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:
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.
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.
If your app doesn't immediately make the top 50 rankings on an app marketplace, you have plenty of promotional options.
We hope these new resources help you make the most of AdMob.
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:
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
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
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:
DONT_CARE
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
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.
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:
@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;}
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:
-(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];}
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:
- (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.
