Google Ads Developer Blog

Updates to our AdMob SDK

2012-05-10T10:06:00.000-07:00

Editor’s note: We’d like to share this post from Chrix Finne which announces updates to the Google AdMob Ads SDK. -- Eric Leichtenschlag, Ads Developer Relations Team

Today we are posting an update to the AdMob SDKs for iOS and Android. This SDK update features several minor bug fixes and improvements.

We are also releasing an optional version of our SDK for iOS that includes the UDID parameter, which is used to improve ad performance and relevance. Apps utilizing this version must obtain appropriate user consent for sending device identifier information in compliance with relevant iOS policies.

Posted by Chrix Finne, Product Manager

Placing ads to prevent accidental clicks in your mobile app

2012-05-03T10:29:00.000-07:00

In this blog post, we will help you understand how you can monetize your mobile applications while following our ad placement guidelines to ensure a good experience for your users.

As you may know, Google takes issues regarding program policy compliance very seriously. We have our AdSense program policies and AdMob program policies to help ensure a positive experience for our publishers, our users, and our advertisers. As such, we ask that our publishers/developers comply with these policies.

One of the most common policy violations is placing ads in a way which can trigger accidental clicks. Your ads’ proximity to the other elements within your application can influence whether or not users click on ads by accident.

Here are some tips to decrease the chances of accidental clicks:

Ads should not be right next to interactive buttons, such as a “next” button, or on a game play screen where users are interacting continuously with the application. We have seen that when a user is clicking or tapping repeatedly within an application and there is an ad near or within the interaction area, there is a much higher rate of invalid activity.
If the space within your application is limited, it helps to then delineate the ad from the application content by creating a thick border between the ad and the application’s interactive portion.

An example of a placement to avoid:

A recommended ad placement in this scenario:

Please double check your ads’ implementation with the tips above. With the right implementation, you’ll be able to monetize your application properly without accidental clicks.

- Maiko Fujita, AdMob Team

Know Your AdMob IDs: Publisher vs Mediation

2012-04-27T14:14:00.000-07:00

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.

- Eric Leichtenschlag, AdMob Team

AdMob Optimisation Essentials

2012-04-26T08:43:00.000-07:00

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 hope these new resources help you make the most of AdMob.

- Dairine Kennedy, EMEA Mobile Specialist

Build a flexible app business with the latest AdMob SDK

2012-04-19T11:56:00.000-07:00

Editor’s note: reposting from Google Mobile Ads Blog post by Chrix Finne. -- Stan Grinberg, Ads Developer Relations Team

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.

Posted by: Chrix Finne, Product Manager, Mobile Ads

The Docs are Dead. Long Live the Docs!

2012-04-19T04:36:00.003-07:00

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

Creating A GADBannerView Singleton in AdMob Applications

2012-04-03T16:12:00.001-07:00

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:


@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 Ad

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];
}

Forwarding Delegate Notifications

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.

- Raj Parameswaran, AdMob Team

Embedding AdMob Ads Within A ListView on Android

2012-03-13T15:59:00.000-07:00

We’ve already shared how you can get ads up and running along the bottom or top of your app using the ListView layout in Android applications. This post will show you how to embed AdMob ads within the ListView as list items.

For this scenario, let’s assume that we want ads to occur every k items within the list.

Embedding ads within a ListView requires writing a custom adapter that extends BaseAdapter. This adapter will add functionality to allow ads to behave as list items within a ListView. Your class declaration will look something like:


public class ListViewExampleListAdapter extends BaseAdapter 
    implements AdListener{

  // Constructor takes in a BaseAdapter also
  public ListViewExampleListAdapter(Activity activity, BaseAdapter delegate) {
 …

Notice how we use the decorator pattern by passing in a BaseAdapter into the constructor of the custom adapter class. Using this pattern, we can accept any type of adapter (including a custom adapter) instead of having to hard-code the types of acceptable list items. We only have to implement functionality relevant to AdMob ads within our list adapter, and defer to the underlying adapter class for functionality related to any other list items.

The most important step is to override getView() to return ads for every k items. We can use delegate.getView() to return the view for any items that aren’t ads. The code for this looks like:


  @Override
  public View getView(int position, View convertView, ViewGroup parent) {
    if ((position % k) == 0) {
      if (convertView instanceof AdView) {
        // Don’t instantiate new AdView, reuse old one
        return convertView;
      } else {
        // Create a new AdView
        AdView adView = new AdView(activity, AdSize.BANNER,
                                   INSERT_ADMOB_ID_HERE);

        // Convert the default layout parameters so that they play nice with
        // ListView.

        float density = activity.getResources().getDisplayMetrics().density;
        int height = Math.round(AdSize.BANNER.getHeight() * density);
        AbsListView.LayoutParams params = new AbsListView.LayoutParams(
            AbsListView.LayoutParams.FILL_PARENT,
            height);
        adView.setLayoutParams(params);

        adView.loadAd(new AdRequest());
        return adView;
      }
    } else {
      // Offload displaying other items to the delegate
      return delegate.getView(position - (int) Math.ceil(position / k) - 1,
          convertView, parent);
    }
  }

The bolded code makes sure that the adView list item is large enough to fit the ad.

The other methods that we need to override are pretty trivial. They require adding information specific to our ad implementation and deferring to the delegate for everything else. These methods are:

If you have any questions about embedding ads within a ListView, or even any questions about the SDK in general, feel free to post them in our forum come join us in our upcoming developer hangout. Take a look at AdCatalog v2 for Android for a working example of everything demonstrated here.

- Raj Parameswaran, AdMob Team

Announcing Release of DFP Showcase and Ad Catalog v2

2012-03-09T15:00:00.000-08:00

We would like to announce the release of the DFP Showcase application for iOS and Android, as well as v2 of the Ad Catalog project for Android.

DFP Showcase

DFP Showcase is a sample project that features the various creative types you can display in mobile applications with DoubleClick for Publishers (DFP) Mobile. DFP Mobile provides publishers the ability to set up campaigns with different ad types, and uses the Google AdMob Ads SDK to display the ads in mobile applications.

The DFP Showcase application features expandable ads, image animation, click to map, and more!

You can download DFP Showcase directly or clone the source code from the dfpshowcase-android or dfpshowcase-ios repositories.

Ad Catalog v2

We are pleased to announce the release of Ad Catalog v2 for Android. This new version shows examples of best practices for ad placement in four different types of layouts - TabView, ListView, OpenGLView, and ScrollView.

Here are some details about the implementation of these examples:

The TabView example makes use of Android’s v4 support library to implement fragments for tabs while maintaining support for Android 1.5 and higher.
The ListView example adapter was written to accept any type of list items, and will embed ads every k^th item in the list provided.
The OpenGLView and ScrollView examples show how to dock an ad to the top or bottom, but outside the content on the screen.

You can get v2 of the Ad Catalog by downloading a zip file from the google-mobile-dev download page or by cloning the source code.

Have any questions, comments, or feature requests for the DFP Showcase or Ad Catalog projects? Let us know on the forum, or join us during office hours! Also, stay tuned for the release of Ad Catalog v2 for iOS.

- Eric Leichtenschlag, AdMob Team

Embedding Google AdMob Ads Within A UITableView

2012-03-06T13:55:00.000-08:00

We previously talked about docking AdMob ads to the bottom or top of a UITableView. In response to that post, we’ve had a lot of developers asking us about embedding AdMob ads within the UITableView cells, so we wanted to share how this can be best achieved.

Challenge

Placing ads within a Table View in iOS as list items can bring up a number of issues:

Inflated impression numbers because tables in iOS refresh when the user scrolls.
The one-to-one mapping between data in the Table View and the application’s model will usually be lost.

Choosing A Solution

Table Views in iOS are populated by implementing the tableView:cellForRowAtIndexPath: method. Cell objects are often reused so that new ones aren’t instantiated each time the Table View is refreshed (by a scroll for example). There are two ways that ads can be implemented within Table View cells:

Only use one GADBannerView throughout the table. This would mean that the same ad is displayed in different cells in the table (preferred).
Leverage dequeueReusableCellWithIdentifier: so that GADBannerViews are created only when new cells are created.

Using one GADBannerView throughout the table does decrease ad diversity but generally increases the CTR for the ads that are shown because the user will more likely see the ads that are displayed. The example below will show how to implement this approach as it is the better practice.

Solution - Single GADBannerView Method

For the purposes of this example, let’s assume that every 10th element in the list is going to be an ad. This means tableView:cellForRowAtIndexPath: will be set up with a conditional that modifies the placement of the GADBannerView for every tenth cell:


- (UITableViewCell *)tableView:(UITableView *)tableView
         cellForRowAtIndexPath:(NSIndexPath *)indexPath {
  int row = [indexPath row];

  // Assume that kFrequencyAdsInCells is 10 so every 10th row is an ad
  // Don't want first item to be an ad so use 10-1=9 instead of 0
  if ((row % kFrequencyAdsInCells) == (kFrequencyAdsInCells)) {
    cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
  
    //Need to create a new cell object
    if (cell == nil) {
        cell = [[[UITableViewCell alloc] initWithFrame:CGRectZero
                                       reuseIdentifier:CellIdentifier]
                autorelease];
    }
    // If bannerView_ has a superview, then it has been added to a cell
    if (!bannerView_.superview) {
      // First ad request made, make the ad request and add it to this cell
      [self requestAd];     
    }
    // The banner will be removed from the other cell and put into here
    [cell.contentView addSubview:bannerView_];


}
…

Since ads are being inserted into the Table View now, any previous mapping to data in the model will be lost. Some quick math is necessary here to figure out how the rows in the Table View line up.


  // Complete in cellForRowAtIndexPath: if not ad
  
  // Make sure we get all of the items from our model
  row = row - floor((float)row/kFrequencyAdsInCells);
  
  cell.textLabel.text = [dataController_ objectInListAtIndex:row];

The methods tableView:NumberOfRowsInSection: and tableView:heightForRowAtIndexPath: will need to be modified as well. The method tableView:NumberOfRowsInSection: would now return the number of elements (including ads in that number) and tableView:heightForRowAtIndexPath: would return the height of an ad for every tenth cell, respectively.

If you have any questions about embedding ads within a UITableView, or even any questions about the SDK in general, feel free to post them in our forum. Keep an eye out for AdCatalog v2 for all kinds of advanced layouts options integrated in the project.

- Raj Parameswaran, AdMob Team

Announcing AdCatalog v1 for iOS

2012-01-27T16:36:00.000-08:00

We’re very pleased to announce the release of AdCatalog v1 for the iOS platform. AdCatalog is a sample project that demonstrates how to incorporate banner and interstitial ad units into your application. In particular, AdCatalog showcases implementations for two standard banner ad sizes—320x50 and 300x250—and several use cases for interstitial ad units: basic, app launch splash screen, in-between game levels, and before playing a stored video.

AdCatalog can be downloaded as a zip from our google-mobile-dev project. Additionally, feel free to clone the repository or examine the source from the checkout page. In version 2, we’ll be looking to add even more advanced layout options to our banner scenario, so be sure to stay tuned. As usual, if you have any questions, comments, concerns, or feature requests, we appreciate hearing the feedback on our developer forum.

- Wes Goodman, AdMob Team

Get Started with Ad Catalog for Android

2012-01-11T14:11:00.000-08:00

Last quarter we announced the release of Ad Catalog for Android, a sample project that demonstrates how to incorporate ads into your application using the Google AdMob SDK. Today, we are excited to announce the release of a walkthrough video to help you get started with Ad Catalog in five minutes! This video will guide you through the entire setup process, from downloading the source code to running it on an emulator. The only preconditions are that you have Eclipse installed as well as an Android SDK version 3.2 or higher.

Ad Catalog shows you two implementations for standard banner ads. You can select the size of the ad that is displayed on the Banners screen by selecting either the 320x50 standard banner ad or the 300x250 medium rectangle ad.

In addition to display ads, Ad Catalog demonstrates various use cases for interstitial ads. Ad Catalog provides examples on how to include interstitial ads in between game levels, before loading a YouTube video, and in between a screen swipe. There is also an option to receive a splash screen interstitial ad. If enabled, the app will load and display an interstitial ad the next time it starts up.

The first version of the Android Ad Catalog source code can be downloaded from the google-mobile-dev project. In the next version, we plan to add examples of banner ads in various advanced layouts. The iOS implementation of Ad Catalog is almost complete, so stay tuned for another release announcement. We appreciate your feedback, so please post any questions or feature requests you may have to our forum.

- Eric Leichtenschlag, AdMob Team

AdMob and AdWhirl Refresh Rates - A Subtle but Important Difference

2011-12-28T08:15:00.000-08:00

The AdWhirl SDK provides a framework that allows developers to display banner ads from different ad networks in their iOS and Android applications. You simply tell AdWhirl what ad networks you want to use and the percentage of requests to allocate to each network, and AdWhirl handles the ad requests. But how do you choose an acceptable refresh rate, and what settings should you use for both AdWhirl and your individual ad networks?

AdWhirl has its own refresh rate; when it comes time to refresh, AdWhirl removes the current network’s ad view, chooses a new ad network, and creates a new ad view for that network. So how is this different from the AdMob refresh rate? Well, the AdMob refresh rate determines when its own ad view will request a new ad.

AdWhirl does not know about the specific ad networks’ refresh rates. Most networks expose the refresh rate on the client side; AdWhirl takes advantage of this by turning off refreshing for these networks. AdMob, however, only supports configuring the refresh rate on the server side. Therefore, AdWhirl must rely on you, the developer, to turn off the network refresh rate. Forgetting to do so may result in unexpected refreshes. This is best demonstrated with an example.

Let’s say AdWhirl has selected the AdMob network for displaying an ad, and your AdMob refresh rate is 29 seconds while your AdWhirl refresh rate is 30 seconds. AdWhirl will load up an AdMob view, and then the AdMob view will request and show an ad. After 29 seconds, AdMob decides it's time to refresh, grabs a new ad on it's own, and displays a new ad. AdWhirl has no idea that AdMob just refreshed. One second later, AdWhirl decides it’s time to refresh (30 seconds have passed), and removes the AdMob view and picks a new ad network from which to show an ad.

In the above example, AdMob displayed a new ad that was shown for only one second--it had virtually no chance of being clicked. This results in extra impressions that reduce your click through rate and confuse your customers. To avoid having AdMob refresh on its own, make sure to turn off automatic refreshing for the AdMob publisher ID you are mediating with!

Please post to the forum for any questions regarding refresh rates. You’re also welcome to attend one of our office hours hangouts.

- Eric Leichtenschlag, AdMob Team

Incorporating Google AdMob ads into a Table View in iOS

2011-12-22T12:07:00.000-08:00

Perfecting the look of your application is challenging, and incorporating ads into your application requires careful thinking. When using the AdMob SDK with Table Views in iOS, a typical challenge is that ads do not stay docked properly to a certain position on the screen. This blog post outlines a simple solution to this common problem.

Challenge

Consider a simple application in which a UITableViewController is used to handle a list mechanism. If this is the main top level view in the application, getting the ad to remain docked to the bottom or top of the view while the content scrolls is problematic. This is usually because the ad has been placed inside the Table View.

Solution

One way to dock the ad is to encompass the Table View into a container view (e.g. a UIView). This way, instead of inserting the ad into the Table View as a subview, it’s inserted into the encompassing container view (as a sibling of the Table View). Here is an example of the code snippet in the header file:


@interface AdsOutOfTableView : UIViewController  {
@private
 UITableView *tableView_;
 //Other private variables here
}

@property(nonatomic,retain) IBOutlet UITableView *tableView;
@end

As shown in this example, the GADBannerView is initialized with a frame that has an origin at the bottom of the screen.

Now when the ad is received, it should be added into the container view, and the size of the Table View should be modified accordingly. The height of the Table View's frame cannot be modified directly, but this can be done using an intermediate frame as shown below.


-(void)resizeTable
{
 CGRect tableFrame = tableView_.frame;
 tableFrame.size.height = tableFrame.size.height -
       bannerView_.frame.size.height;

 tableView_.frame = tableFrame;
}

Now, no matter how much the Table View is scrolled, the GADBannerView stays docked to the bottom of the screen.

Alternatively, keeping the ad docked to the top of the Table View is very similar to the situation shown above. The only difference is that the GADBannerView must be created and drawn at the top of the screen. The resizeTable: method now also has to to shift itself down by the height of the ad:


 CGRect tableFrame = tableView_.frame;

 tableFrame.size.height = tableFrame.size.height -
         bannerView_.frame.size.height;
 tableFrame.origin.y = bannerView_.frame.size.height;
 tableView_.frame = tableFrame;

With those minor tweaks, you will have ads set up correctly alongside your Table View! If you have any questions about this or any other SDK topics, feel free to post them in our forum.

- Raj Parameswaran, AdMob Team

A look back at mobile in 2011

2011-12-20T18:40:00.000-08:00

Editor’s note: As many of you are planning your 2012 advertisement strategy, we’d like to share with you this post from Karim Temsamani. It’s a look back on 2011 and provides a great perspective on how mobile really took a step forward in the advertising ecosystem. -- Stan Grinberg, Ads Developer Relations Team

Mobile turned a corner this year. As smartphones and tablets became a part of our everyday lives, business owners’ conversations shifted from 'Why should I advertise on mobile or build a mobile website?' to 'How do I get started?’.

Five major industry trends emerged in 2011 that will carry us into 2012, and beyond.

1 - Everyone goes mobile
Smartphones and tablets proved that they weren’t just for the geekiest - er, ‘tech savviest’ - among us. These devices are increasingly becoming the norm and they continue to change how people connect with each other, and with businesses, everywhere. According to our research with IPSOS earlier this year:

79% of smartphone consumers use their phones to help with shopping, from comparing prices, to finding more product info, to locating a retailer.
70% use their smartphones while in a store.
77% have contacted a business via mobile, with 61% calling and 59% visiting the local business.

It’s not just that more people are using smartphones and tablets (though the numbers are skyrocketing at an accelerating pace)—it’s that a huge, and fast-growing base of smartphone users, now expect to engage with businesses on mobile. The mainstream consumer got mobilized in 2011.

2 - Mobile search transforms shopping, forever
Analyzing mobile search trends helped the industry better understand how people were using their mobile devices in 2011. For starters, we learned a lot about the ‘timing’ of mobile and tablets. These devices enable us to be constantly connected to the internet, as mobile usage has proven to be complementary to the desktop. We got a clearer picture of how search is changing the ways we shop and connect with businesses. More people are looking for deals both en route to stores and within them on mobile - in the retail category, “Black Friday” related mobile queries were over 200% higher this year than in 2010. Users have also developed some mobile-specific shopping habits - for example, 44% of all searches for last minute gifts and store locator terms are projected to come from mobile devices this holiday season. For procrastinators, mobile has come to the rescue!

In October, we looked at some of the newest ways marketers can build their businesses via mobile search. But, this is only the beginning - whether people are trying to find or call a business, compare prices in a store, or visit a site or app directly from their phones, search and search ads will be the tools that shape a new shopping experience, enabling us connect with businesses, research and buy products on or offline, all via mobile.

3 - Progress with the mobile advertising pipes
As an industry, we came a long way in terms of improving the ‘pipes’ - the systems, products and technologies that advertisers use to build, serve, and measure mobile ads. It’s still early days, but the progress with standards like MRAID and the momentum behind HTML5, are helping to rally the mobile community and make it easier for marketers and customers to connect on the platform. Getting existing tools to ‘speak mobile’ has been another key to helping mobile advertising grow-up as quickly users and businesses want it to. Across search and display, the tools the industry is already familiar with are getting mobilized. There’s plenty of work still to do, but significant progress is being made - watch this space in 2012.

4 - Tablets join the mobile party
Tablets made quite a splash this year. Usage trends sharpened - we’re seeing that people people use these devices to shop, consume media, have fun, and they do so most frequently in the evenings. Tablets are a third screen to be reckoned with for marketers - we saw a 440% growth in traffic from tablets in November 2011 compared to December 2010 on the AdMob network. The business potential is tremendous: not only are users more inclined to shop and make purchases on tablets, but because campaigns can be more effective running across several screens instead of one, tablets offer an incremental opportunity for marketers. Our research with Nielsen showed that campaigns on several screens can be ‘Better Together’ - indeed, in cases like Adidas’, that proved to be true.

5 - Businesses start (actually) thinking mobile first
Smartphones and tablets aren’t small desktop computers - they’re new devices being used in entirely new ways. This year, businesses began to embrace this at scale and many saw good things happen when they built ad campaigns and websites specifically for mobile. Ticketsnow’s success with a mobile optimized site - increased site traffic, and more ticket sales - is just one example of the benefits of building for mobile. Initiatives like GoMo and platform-specific ad features will help businesses better connect with mobile customers in the coming months, and beyond.

It’s hard to believe, but as far as the industry has come in 2011, we’re still in the earliest chapters of mobile’s story. The ways people connect to businesses on their mobile devices and the tools they’re using to connect from them progressed by leaps and bounds this year and soon, we’ll see the mainstream shift that changes the way mobile connects people with brick-and-mortar storefronts as well. Mobile will be moving full speed ahead in 2012 so keep those sleeves rolled-up and those seatbelts fastened - we’ll see you then.

Posted by: Karim Temsamani, VP Mobile Ads

Animating Banner Ads in AdMob SDK for iOS

2011-12-20T14:55:00.000-08:00

Adding animations to banner ads can provide a nice touch to how the ad transitions onto the screen. This blog post will show you how to animate an AdMob banner on iOS.

We will specifically focus on block-based animation methods which were introduced in iOS 4. If you’re using an older version of iOS, you can achieve the same effect using the beginAnimations:context: and commitAnimations: class methods in UIView.

Sliding a banner up onto the screen

The key to animating banners is changing one of the animatable properties in UIView across a certain period of time. iOS will then choose how to animate the AdMob banner across this specified time using its internal logic along with any options that have been specified. Let’s look at how to animate a banner to slide up onto the application’s screen.

First, the AdMob banner is initialized with a frame outside of the bounds of the screen (specifically underneath the bottom of the screen). Once the ad is received, it can be animated upwards through its height. Since the banner is sliding up and onto the screen, only the y-coordinate will change during animation. The code for initializing the banner is shown below.


// Initialize the banner off of the screen
self.adBanner = [[[GADBannerView alloc]    
  initWithFrame:CGRectMake(0.0, 
                           self.view.frame.size.height,    
                           GAD_SIZE_320x50.width,
                           GAD_SIZE_320x50.height)] autorelease];

The next step is to implement adViewDidReceiveAd: to set the final frame for the AdMob banner and tell iOS to animate across the two values using the animateWithDuration:animations: method.


- (void)adViewDidReceiveAd:(GADBannerView *)adView {

  [UIView animateWithDuration:1.0 animations:^ {
    // Final frame of ad should be docked to bottom of screen
    adView.frame = CGRectMake(0.0,
                              self.view.frame.size.height -
                              adView.frame.size.height,
                              adView.frame.size.width,
                              adView.frame.size.height);
  
  }];
}

It’s as easy as that! Now, instead of instantly appearing on the screen, the banner ad gracefully slides up in the application using animation.

Customized animations

You can experiment with other animatable properties of UIView as well. For example, try sliding the banner onto the screen from left to right by changing the initial frame to the left of the screen instead of beneath it. If you want to get even more creative, try experimenting with the Core Animation classes. These classes give you powerful animation functionality and allow you to customize keyframe and timing functions.

Pro tip: Be thoughtful about where and how you’re going to use animations. It’s easy to go overboard.

If you have any questions about animations on iOS or about the AdMob SDK in general, feel free to post them in our forum. Have fun animating!

- Raj Parameswaran, AdMob Team

Google Analytics Enhancements for Mobile Apps

2011-12-15T11:15:00.001-08:00

Yesterday, the Google Analytics team posted some exciting new enhancements to the Google Analytics SDK:

EasyTracking Library - EasyTracker libraries for both iOS and Android enable tracking of your application down to the Activity (or UIViewController for iOS) level with almost no coding required on your part. Additionally, improved integration with the Google Analytics SDK means better responsiveness on iOS as well as automatic session management on both platforms.
Updated Google Analytics SDK - Newly released iOS version 1.4 and Android version 1.4.2 contain several bug fixes, including more reliable methods for sending hits on iOS and a fix for the Android Market referral issue.
More samples - New open source application aimed to help reduce the ramp-up time for new developers who want to track their apps. This application exercises all the Google Analytics APIs that are available to mobile application developers. You can find them at trunk/src/tracking/mobile.

To read more, check out the full post on the Google Analytics Blog.

- Jim Cotugno, Mobile Application Tracking Rockstar

Incorporating Android AdMob Ads Into A Scrollable View

2011-12-07T17:11:00.001-08:00

The Google AdMob SDK makes it easy to serve AdMob ads and monetize your mobile applications. If your app contains a ScrollView, the placement of the ad in your layout can be tricky. In this post, we will discuss the best practice for adding AdMob ads to scrollable content.

Consider the following XML snippet (XML attributes omitted for brevity):


<ScrollView>
   <LinearLayout>
    <TextView android:text="Place very long string here..."/>
      </LinearLayout>
</ScrollView>

Let’s say we want to place an ad in this layout. Defining an AdView in XML is pretty straightforward with the Google AdMob SDK:


<com.google.ads.AdView
    xmlns:ads="http://schemas.android.com/apk/lib/com.google.ads"
    android:id="@+id/adView"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    ads:adUnitId="INSERT_YOUR_AD_UNIT_ID_HERE"
    ads:adSize="BANNER"
    ads:testDevices="TEST_EMULATOR"
    ads:loadAdOnCreate="true"/>

Now we have to determine where to insert the AdView in the layout. If we were to insert the AdView inside the LinearLayout after the TextView, the ad would be displayed at the bottom of the ScrollView.

This is a poor ad placement from the user's perspective. Depending on the length of the app content, the ad either sits awkwardly somewhere in the middle of the screen or is hidden at the bottom of the ScrollView.

To improve the user experience, we can move the ad outside the ScrollView and use a RelativeLayout to pin the ad to the bottom of the screen. This is the needed XML markup:


<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <ScrollView android:id="@+id/scrollLayout"
        android:layout_height="fill_parent"
        android:layout_width="fill_parent"
        android:layout_above="@+id/adView">
        <LinearLayout android:layout_height="fill_parent"
            android:layout_width="fill_parent">
            <TextView android:layout_height="wrap_content"
                android:layout_width="wrap_content"
                android:text="Place very long string here..."/>
        </LinearLayout>
    </ScrollView>
    <com.google.ads.AdView
        xmlns:ads="http://schemas.android.com/apk/lib/com.google.ads"
        android:id="@id/adView"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentBottom="true"
        ads:adUnitId="INSERT_YOUR_AD_UNIT_ID_HERE"
        ads:adSize="BANNER"
        ads:testDevices="TEST_EMULATOR"
        ads:loadAdOnCreate="true"/>
</RelativeLayout>

The layout_alignParentBottom attribute pins the AdView to the bottom of the screen and the android:layout_above attribute sets the ScrollView above the AdView. If the ScrollView is not explicitly set to sit above the AdView, the ad will overlay the bottom of the ScrollView. Let’s see what the final result looks like.

This layout looks much cleaner! The ad is displayed at the bottom of the screen and will stay locked to the bottom as we scroll through the app content, providing a more natural user experience.

If you have questions about this post or about the AdMob SDK, feel free to ask us in the forum or join us at our upcoming office hours Hangout session. Start monetizing your mobile applications today!

- Eric Leichtenschlag, AdMob Team

Come Hangout With The AdMob SDK Team

2011-12-06T16:37:00.001-08:00

Mobile developers--let’s Hangout! We have been answering your questions on the AdMob forum, but we want to take support to another level. That’s why we are excited to announce our first Google+ Hangout Office hours on December 14th at 5pm Eastern (2pm Pacific). We are looking forward to leveraging this technology to connect with you in a way we haven’t been able to before.

With the recent upgrade to both the Android and iOS SDKs, there should be plenty to discuss. We’ll be on hand to answer any technical questions you may have or take in your feedback. If you’ve got a brain teaser of a question, please add it to this forum post ahead of time so we can make sure to get you an answer.

You will need 3 things to Hangout with us:

A Google+ account (sign up here)
The Google voice and video plugin installed on your computer
A quiet place to hangout so we can hear you

Please let us know if you’re planning on attending by clicking the “I’ll be there” button on our event page. Hangouts are limited to 10 people at a time, so if you can’t get in right away please try again later in the hour. For more information about Hangouts, visit the Google+ Help Center. We look forward to seeing you soon, but until then feel free to post any questions you may have in our forum.

- Raj Parameswaran, AdMob Team

Announcing AdWhirl v3.1.1

2011-12-06T11:52:00.000-08:00

We’re very pleased to announce the release of AdWhirl v3.1.1 for both Android and iOS platforms. This update heralds support for the Nexage ad network and includes refreshed adapters for Millennial Media, InMobi, and AdMob—ensuring support for their latest SDK versions.

Additionally, we’ve taken the opportunity to fix several bugs, specifically:

(iOS) Reachability NPE [Issue 118]
(iOS) Null dereference error [Issue 179]
(Android) Build rules for creating the AdWhirl jar
(Android) Fixes for Android 1.5/1.6 crashes [Issue 221]

Go ahead and kick the tires; you can find the zips listed on our downloads page. As always, holler at us on the forum if you encounter any issues.

- Wes Goodman, AdMob Team

Discover DFP API v201111: Mobile Targeting

2011-12-02T11:45:00.000-08:00

In the v201111 release of the DoubleClick for Publishers (DFP) API, we're bringing you the ability to target your ad units and line items specifically for the mobile platform. The following walk-through based on the CreateMobileLineItem example of the client libraries describes how to create mobile-targeted line items.

Set your Target Platform

The first step is to set the new attribute targetPlatform to MOBILE to specify that the line item is targeted towards mobile platforms rather than the default web browser platform. Please note that the target platform attribute has also been added to ad units and that attribute needs to be set to MOBILE as well for the targeting to work.

Set your Targeting

We've introduced four mobile targeting options to enable you to target the right platform:

Here is how you set up your targeting to target just Google devices:

Technology manufacturer = new Technology();
// The ID for the Google device manufacturer was fetched from the 
// Device_Manufacturer PQL table.
manufacturer.setId(40100L); 

DeviceManufacturerTargeting manufacturerTargeting = 
    new DeviceManufacturerTargeting();
manufacturerTargeting.setDeviceManufacturers(
    new Technology[] {manufacturer});
manufacturerTargeting.setIsTargeted(true);

TechnologyTargeting technologyTargeting = new TechnologyTargeting();
technologyTargeting.setDeviceManufacturerTargeting(
    manufacturerTargeting);

Targeting targeting = new Targeting();
targeting.setTechnologyTargeting(technologyTargeting);

LineItem lineItem = new LineItem();
lineItem.setTargeting(targeting);

That's it! Your line item is now set to target just Google devices.

For mobile device targeting, you can specify two lists of devices: one that is targeted and one that is excluded. This allows you to target a device manufacturer but exclude certain devices within that family. However, if a device is part of a device targeting inclusion list, another device from the same manufacturer cannot be in the exclusion list. For example, putting the Nexus S in the inclusion list and the Nexus One in the exclusion list will result in the following targeting error:

GenericTargetingError.CONFLICTING_INCLUSION_OR_EXCLUSION_OF_SIBLINGS @ targeting.deviceFamilyTargeting

Instead, we recommend targeting the Google device manufacturer and excluding the Nexus One with the device exclusion list.

As always, we value your feedback, so feel free to leave your questions or comments on our forum or join us at one of our upcoming developer Hangouts.

- Jeffrey Sham, DFP API Team

AdMob iOS SDK v5.0.5 Released: Taking Interstitials To The Next Level

2011-11-30T17:28:00.000-08:00

Today, we are releasing AdMob iOS SDK v5.0.5 (download here). This SDK contains some important improvements to how the AdMob SDK supports interstitial ads.

In this release, we have added support for additional Rich Media interstitial ad formats for the iPhone and iPad. This update will be forward-compatible with all future interstitial formats. Be sure to get this update if your app relies on interstitial ads because after March 1, 2012, interstitial ads will not be supported on older versions of the SDK.

In addition to improved support for interstitial ads, this release contains two other noteworthy improvements. First, we have increased the accuracy of impression tracking for interstitial ads. Secondly, you’ll now receive the error message didFailToReceiveWithError: if you make any additional requests (after the initial request) from a single GADInterstitial object.

If you have any questions please post them in our forum. Otherwise, check out AdMob iOS SDK v5.0.5.

- Raj Parameswaran, AdMob Team

Announcing version v201111 of the DFP API

2011-11-30T10:30:00.000-08:00

Today we’d like to introduce you to the v201111 version of the DoubleClick for Publishers API. v201111 is one of our largest versions yet; it includes some highly-requested features such as full support for mobile ad serving, new creative types including templates, video player environment targeting, reporting updates, and suggested ad units. A full list of features can be found on our release notes page.

Mobile

As part of our ongoing effort to expand our publishers’ networks to mobile platforms, we’ve made it easier than ever to create and target mobile inventory in the API. Starting in v201111, you’ll find the targetPlatform field on the AdUnit and LineItem objects. This field allows you to specify that an ad unit represents a piece of mobile inventory, or that a line item is only meant to serve to mobile ad units. If a line item is marked as mobile, you can also specify manufacturer, carrier, and device targeting. New examples for how to create mobile ad units and line items will be made available next to their web counterparts in the client library examples shortly.

Creatives

In v201111, we’ve added a few new creative types, most importantly template creatives and custom creatives. Although both allow you to create richer advertisements, they differ in how you will want to use them in your solution. While custom creatives allow you to specify an arbitrary htmlSnippet with accompanying assets, creative templates allow you to reuse creative formats that will appear on the DFP user interface. Using creative templates, you can then create template creatives in which you can set variables to an already defined html snippet by the template.

We’ve also added the ability to view creatives as they would be served. To do this, pass the web page’s URL containing the appropriate ad tags, creative ID, and line item ID to the new LineItemCreativeAssociationService.getPreviewUrl() method.

Video

Along with the new mobile support in the API, we’ve expanded our video capabilities. In v201108, we added the ability to specify that a line item will serve to a video player environment. By enabling this setting, you can associate companion ads to run alongside the video. In v201111, as a DFP video publisher with a content feed, you can target individual videos within your content management source as well as positions within those videos.

Inventory

We’ve also added the SuggestedAdUnit service. This premium-only service enables you to add a new ad unit to an ad tag before defining it in DFP. This allows you to run forecasts for it before traffickers can start targeting line items to it; this functionality is similar to auto-created zones in DART for Publishers. If the ad server receives at least 10 requests for an undefined ad unit, the SuggestedAdUnitService.getSuggestedAdUnitsByStatement method will return that suggested ad unit. The suggested ad units can then be approved using the ApproveSuggestedAdUnits action. You can find an example of how to do this in our client libraries. Please also make sure that you are a premium user and that you have enabled this feature in your account through the User Interface. For more information, see the premium inventory help page.

Reporting

For v201111, we’ve added new columns and the feature to break down reports by dimension attributes. Whereas in the past you would have to manually correlate reports with objects fetched from services, this new feature allows you to include information such as a line item’s start time, an order’s trafficker, or an order’s external ID directly in the report to better integrate DFP reports with your system.

Follow-up posts in the discover series

Over the next few weeks, you’ll have the chance to get to know all of the features a bit more in the Discover DFP v201111 series starting first with the updated features for the mobile platform. And as a final note, if you haven’t signed up for our first ever hangout yet, we’d love to see you there!

- Adam Rogal, DFP API Team

Migrating to v4.3.1 of AdMob SDK for Android

2011-11-22T10:28:00.000-08:00

We’ve seen a lot of forum activity about how to migrate from v4.1.1 to v4.3.1 of the Google AdMob Ads SDK for Android, so we’d like to share three easy steps to get you up and running with the latest version.

The first step to migrating is downloading the AdMob SDK and adding it to your build path.

You will need to have an Android SDK of 3.2 or higher. Once you have a compatible version, set target=android-13 or higher in your project.properties file of your application to compile against the version you just downloaded.
Don’t worry, you can still build your apps on all Android devices down to Android 1.5! Just set <uses-sdk android:minSdkVersion="3"/> in your AndroidManifest.xml file. You can read more about the uses-sdk element to help you configure the appropriate devices for your app.

Finally, replace the old com.google.ads.AdActivity element in your manifest with this new definition:

<activity android:name="com.google.ads.AdActivity"
android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize"/>

That’s it! You should now be able to run your application using the latest SDK without any errors. Please post to our forum if you have any questions about the migration.

- Eric Leichtenschlag, Mobile Ads Developer Relations Team

Welcome to the new Google Ads Developer blog!

2011-11-21T05:27:00.001-08:00

Welcome to the new Google Ads Developer blog, your one-stop shop for all ads developer related news, tips, and tricks. We've combined several blogs to create this central hub, so you can find information on AdWords, AdSense, DoubleClick and AdMob APIs and SDKs.

If you prefer to subscribe to a particular label, you can do so by clicking on the following feeds: adwords_api, adsense_api, dfp_api, dfa_api, admob_sdk, and mobile. Thanks for stopping by, and please check back frequently for all ads developer news.

-- Stan Grinberg, Ads Developer Relations Team