Update [2013-10-04]: Google has just released a beta version for AdMob on Windows Phone 8. The blog below was posted before.
After months of putting up with the Microsoft Ad Control, I’ve finally had it with abysmal returns on ad revenue in my Windows Phone apps. At first I thought it was just me or my app – and most of the time, that is a good way to look at your apps and fix the issues. But this time it’s different. The low returns on ad-based apps is due not only to the laughable eCPMs, or cost per a thousand impressions, but to the fact that the fill rate – an actual ad being served up – is so low. Too many times I’ve launched my app only to see the ad momentarily appear and then disappear for good, not showing any ads. This is like having a bouncer at the gate that lets too many of his friends in without paying the cover charge. It’s time to fire that bouncer!
Well, what other alternatives do we have here? Well apparently, several, one of which being Google’s AdMob, which I will experiment with in this blog.
NOTE: Now that I’ve finished writing this blog, I should let you know that reading the last paragraph first could save you time.
Let’s quickly get into the action:
Click Sign up with AdMob at http://www.google.com/ads/admob.
Signing up is very straightforward:
- Sign in with a Google account
- Enter your name, address, etc.
- Select time zone and currency
- Check the “I agree” button
- Click Get Started button
When I logged in I got a message that said: “Your payments are currently on hold. Action is required to release payment”, which I believe was due to the fact that I registered as a business, but didn’t actually (get to) specify any business specific information. I suspect I will eventually have to enter it to receive any payments. When I tried to fix this, the pages under Payments settings kept erroring out with “The content you requested cannot be loaded at this time”. Oh well.
Let’s move on. When I clicked Monetize on the top bar, I was kind of surprised to see Windows Store or Windows Phone not listed as available options for automatic or manual addition of apps. Yes, Google and Microsoft are like Neo and Agent Smith, but I know of 3rd party ad controls that use AdMob in the back-end. So there must be way?
It turns out, to use AdMob with Google’s Windows Phone SDK control, all you need is your publisher ID, which is reported under Account and conveniently, also on the very top of the page. Apparently, you don’t need to specify ad format or ad unit, which is what the Monetize section would allow us to do.
Next step: Download Google AdMob Ads SDK For Windows Phone 7
When I extracted the ZIP file I just downloaded, I was pleased to see that in addition to the DLL (the reference assembly I would need for the ad control), a sample Visual Studio solution was also included. I opened the solution with Visual Studio 2012 – I don’t trust VS 2013 RC so much just yet, but still the solution had to be converted. Luckily, no issues there. I’m also using the Windows Phone SDK 8.0.
The solution opened
But sure enough, the design time XAML compiler was complaining that the google:BannerAd control didn’t exist. I suspected a broken link to the Google.AdMob.Ads.WindowsPhone7 assembly, but its path property checked out. Next, I opened the properties of the DLL file in Windows Explorer and clicked “Unblock”.
You may be forgiven if you’ve never seen this option – Windows likes to hide it for other files. Hiding is the enemy of discoverability.
I realized later on, that one of the errors listed in Visual Studio’s Error List pane actually indicated that this might be the case. Oh well. But, despite doing this and rebuilding it, the error wasn’t going away. Time to close and reopen the solution, and voila!, the error went away.
Now, let’s build it and try it on the emulator.
Denied! I got an error saying that “Could not find file blahblah\XapCacheFile.xml”. Please rebuild the solution and try again. This time somewhat wiser, I decided to follow the instructions, and clicked “Rebuild” from the build menu.
Denied! I got an error saying “Xap packaging failed. Object reference not set to an instance of an object.”
Since the error didn’t make any sense to me, I did what anyone would do: Try again. But that only works sometimes, and this time it didn’t. What would Don Draper do? Take a power nap? I didn’t have time for that it being almost 10pm, so instead I took a nice break to get my subconscious to work on the problem.
OK, so it wasn’t a short break. I ended up watching Star Trek – Into Darkness, somewhat an apt title for the current situation. Now that I got a good night’s sleep and am all refreshed, let’s tackle the problem by mentioning the error message to the hive mind that is the internet.
Quickly, I found a blog that indicates that this error happens when there’s a missing file in the solution. Normally, Solution Explorer shows missing files with a special icon, but a close inspection of all files reveals no such icons. The missing file must be referenced via another method, not by the solution itself.
I could have looked for this item manually, but why bother? A quick search in the developer forum shows that the missing file is background.png, referenced by WMAppManifest.xml. Now, I think it’s only human to get frustrated by the Google engineers who’ve pushed this “SDK” out apparently without testing, but that’s really not productive. When it comes to software development, a motto I come back to again and again is: “Keep calm and carry on.” Perhaps, I should even be grateful that they attempted to support Windows Phone, but that’s another story.
The fix is to replace background.png with ApplicationIcon.png
Once I performed the fix on both projects, it was time to build it and run it.
Good, the emulator launches!
But, without skipping a beat, I hit the “Unhandled Exception” handler, with a null reference exception on the Google ad control. Of course: we must populate the AdUnitID in MainPage.XAML with our publisher ID.
To get the publisher ID, I tried signing in to admob via the original link, which, unexpectedly, required me to complete some registration. WTH. When I tried filling in the form, I could not find United States in the list of countries. Hmm, that’s weird! A few minutes later, I realized that on the top of the page, which I skipped because it looked uninteresting, it turns out that there was a separate link for users in the US. D’oh! In retrospect, the link was kind of hidden in what appeared to be some self-serving promotional paragraph that my eyes are trained to ignore.
As I was going through the steps above, somehow I ended up on this page.
Keep calm and carry on.
Tried again and was able to log in and get my publisher ID and plug-it in the XAML. That took care of the exception, but I still wasn’t getting any ads. Waiting a while didn’t help. For generic issues like this, forums are full of what I call noise so I first try to figure out what’s wrong on my own. Hopefully, the ad control itself will help me. After enabling the Error List pane in Visual Studio for run time, I see that there is a message:
Error – Cannot determine request type. Is your ad unit id correct? (InvalidRequest)
Through simple intuition, I decided to remove the pub- prefix from my published ID in the XAML. Now I get the message:
Error – Ad Not Available (NoFill)
Which is promising as far as development is concerned, but disappointing from a user point of view. Not sure if this is an error on my side, or everything’s working as expected but no ads being served, which required some more investigation.
There is a note in one of the Windows Phone pages that says the following:
The very first time AdMob sees your publisher ID it may take up to two minutes to receive an ad. This initial two minute lag will recur every time the app goes unused for 24 hours.
OK, let’s rerun the app and check Facebook for a little bit while we wait. After 5-10 minutes, still nothing.
After some more research, I was unable to find out whether the way I specify the publisher ID is actually correct, given so little documentation. Also, pages like this one and this one have somewhat convinced me that AdMob is really not working well for Windows Phone.
According to TechCrunch, Google acquired AdMob in November 2009, and an official Google blog dated May 2010 says that the acquisition is closed. Well, it’s now September 2013, and Google “has launched a new AdMob” and appears to be still in Beta of some sort. Given 1) my less than stellar experience above using their SDK and horrible experience with the web pages and 2) that AdMob is a pay-per-click service as opposed to pay-per-impression (as I later found out), I will pass on AdMob, at least for the near future.
Goodbye AdMob, it was fun trying to get to know you. Not.