Using AdMob for Windows Phone 7
Published on Saturday, March 19, 2011 12:18:00 PM UTC in Programming
A few days ago, Google has released a first beta version of an AdMob SDK for Windows Phone 7. People seem to be interested in that especially outside the U.S., because at the moment, Microsoft's own Advertising program is only available to developers based in the United States. Here is a short walk-through of how to use the AdMob SDK in your app and what you can expect from it at the moment.
**Please keep in mind that this post is based on a beta version, and that the final experience and feature set may be different from what I observe and describe here. **
To obtain and use the SDK, you first have to create an account with AdMob here:
The information you need to provide only includes basic information. All data relevant for a later payout process (like your business name, tax number, bank account etc.) can be added later and changed at any time you want. Once created, your account can be used to manage multiple apps and sites in one place.
Add your application
The next step is to add your application to your account, which can be done in the "Sites & Apps" area. Click on the link "Add Site/App" to start a new wizard for this. The first step is to select the platform. This is where you choose "Windows Phone 7 App":
Next you are requested to add some more information about your app. You can also link to the marketplace here:
The final step is to download the actual SDK:
Extract that archive to any place on your hard disk. Aside from a (very) short readme and the license, it contains the assembly needed to develop apps with the AdMob ad control:
A missing puzzle piece is the publisher ID that you need to operate the ad control in your application. Go back to the "Sites & Apps" page where now your new app should appear in the list. Click on the "Manage settings" link for your app to get to the detail page. The publisher ID is listed just below the application title:
That site allows setting various parameters for your app. One particularly interesting setting is the "Automatic refresh", which is set to "Use refresh rate set in client code" by default. I wasn't able to locate any property or possibility to set this parameter "in client code" (probably missing in the beta release), so you might probably want to use the option here to adjust it if you need to change the default value of 60 seconds to something different.
With everything at hand, you can start coding now :)
The first step to do is to add a reference to the above mentioned assembly to your application by browsing to the extracted "Google.AdMob.Ads.WindowsPhone7.dll" in the add reference dialog. When you inspect the corresponding namespace, you will see that it only contains a hand full of helper classes for error handling and to provide additional information to the ad control (like the gender and geo location of the user, see below). Curiously enough, the actual control is located in a sub namespace named "WPF":
The other components in that namespace are attributed as being "internal support classes not intended for third party use" which basically leaves you with the "BannerAd" class alone for everything meaningful you can do with the SDK.
To use the control in XAML, add the following namespace declaration:
Then you can put the ad control anywhere you want on your page:
<admob:BannerAd Name="bannerAd" />
A note on the size: Without any additional settings, the ad control content will be sized at 480x75 pixels. This is the only supported size at the moment. You can resize the control, but you will find that it will get cropped or have empty areas when you do so. This decision seems a bit odd to me; according to this thread the actual ad size is 320x50 and it gets scaled by the ad control to the full size of 480x75 which is clearly visible for bitmap ads. I think it would've been nice to be able to present the ads in their original size, but that's not possible at the moment.
When you run the control with this simple setup, you will see the following:
At the lower right, your device's unique Id is listed. Click on the ad to get more information about this:
So obviously what we have to do now is provide the AdUnitID the control expects. Don't let that confuse you, this ID is the "Publisher ID" we have received on the AdMob web site. The second thing is to add your device ID to the list of testing devices to avoid that you retrieve real ads during your tests.
Please note: The docs and the above text say that you won't receive real ads when a debugger is attached. This doesn't seem to be true. In my tests I found no difference with and without debuggers attached and the control happily did fetch real ads on the physical device even when I was debugging. To avoid triggering the fraud detection during your tests, you should use the mechanism of the TextDeviceIds to exclude your device.
<admob:BannerAd x:Name="bannerAd" AdUnitID="1234567890"> <admob:BannerAd.TestDeviceIDs> <System:String>1234567890</System:String> </admob:BannerAd.TestDeviceIDs> </admob:BannerAd>
Instead of working with XAML, you can also specify these properties on the "Misc" panel in Expression Blend. This concludes the basic setup, and when you run your app now, you should see the following:
Clicking the ad now will bring up the mobile web site of Google.
Configuring the ad control
Depending on what data you know about your user, you can provide additional information to the control to generate more tailored advertising. Here are some of the properties for that:
- Birthday: can be filled with the birthday of the user
- Gender: the gender of the user
- GpsLocation: the geo location of the user. Usually you would update this property when you receive the PositionChanged event of a GeoCoordinateWatcher in your app.
- LocationDescription: a textual description of the location that offers the possibility to specify a more general information about the position of the device. GpsLocation and this property are mutually exclusive.
Please note that you shouldn't add more features to your app just for the sake of advertising. For example, if your app is not working with geo locations, it's not advisable to add this feature to your app just to improve your advertising.
In addition to the user specific data, you can also provide general information about your app using the "Keywords" property. One thing to be aware of is that changing those properties in code will trigger a refresh of the ad control. Since you probably want to set multiple properties at once sometimes, the control offers a deferring mechanism to prevent refreshes until all values have been set:
bannerAd.BeginUpdates(); bannerAd.Birthday = new DateTime(1879, 03, 14); bannerAd.Gender = Gender.Male; bannerAd.EndUpdates();
If you want to forcefully load a new ad, you can use the "ShowNewAd" method.
The control offers various events you can handle to react to different situations. In particular:
- AdLoading: Raised when a new ad is about to being requested.
- AdReceived: Occurs when an ad has been successfully received. This can be used to switch the ad container's visibility, for example.
- AdFailed: Raised when an error occurred during the request of an ad. The documentation recommends logging these events, but I don't see how this helps with anything. Once the ad control has been configured correctly, this event should only be raised when there's a lack of ad inventory, and then there's nothing you can do about it. You can use this to e.g. switch the ad container to collapsed to hide it (there's no point in having it occupy space when there's no ad to show).
- AdLeavingApplication: Occurs when the user has clicked on an ad so another application is launched (for example the phone's market place).
- AdPresentingScreen: When this event occurs the ad is about to being presented in full-screen mode (in a browser control). You can use this to turn off/pause computational intensive things like animations.
Possible problems and glitches
When I first tested the ad control with one of my test apps, starting the app resulted in an immediate hard crash and an error like this:
An unknown error has occurred. Error: 80010108.
Not really helpful, and it took a moment to realize what the problem was. The ad control uses the web browser component to display those ads that don't lead to the marketplace. If your app does not specify that capability in the WMAppManifest the result is this crash. So make sure you have it listed, like:
A visual glitch I found was that the control apparently has a one-pixel margin or padding at the bottom. This was not apparent during testing at all, because unfortunately the control uses a transparent background by default. However, when serving real ads, they sometimes contain solid images, and that was when I realized that a one-pixel stripe of my bright background was shining through at the bottom. I was able to fix this by setting a bottom margin of -1 on the control.
Does it work?
To be honest, I don't know. There are several issues I see at the moment:
I have submitted a test app containing the ad control to the market place and I have no idea if it will pass validation. It's been stuck in the testing process for three days. I'll post an update of how this turns out here.2011-03-22: It took more than five days for the app to be certified, but it eventually showed up in the market place today. So apparently there's no problem with using the ad control regarding Microsoft's certification requirements.
- AdMob has a pay-per-click-through policy, whereas Microsoft's Advertising program pays per impression. This means that even if a million people look at your ads and nobody ever clicks on them you won't receive any money. Apparently this actually has happened in the past (pre-SDK times).
- At the moment not many ads for Windows Phone 7 are on the network. I've seen tweets of people claiming the control would not serve any ads at all; in my case I have seen exactly three different ads. According to the statistics on the AdMob site I have requested and was being served 23 ads during my tests. Only three different actual ads for 23 served requests seems a bit meager. But given the fact that AdMob for WP7 has just been launched I think it's natural that the ad inventory is almost empty. We'll have to be patient and observe when and how quickly the quantity of the available ads increases. By the way, an interesting detail was that none of my explorations produced any click-throughs in the reports.
- XNA: At the moment, AdMob does not support XNA at all. I'd say that games are an important aspect for advertising too, but currently there's no possibility to use the SDK in your XNA games.
For further information and more source code samples, you can read Google's own documentation.
Tags: AdMob · Silverlight · Windows Phone 7