Second Take Bug Fixed and Lessons Learned on In App Purchases

Second Take v.1.0.1 just was released, and I have to say that I am pretty happy with how this app looks (especially on the iPad).  I really think that the iPad has an opportunity to be the go to device for party games (a la Catchphrase and Taboo) in the future and feel that Second Take makes good use of this functionality.  I thought I would spend this time to update on some of the lessons learned from the initial v.1.0 releaste for either (1) non technical people making games and (2) novice programmers when it comes to integrating ads and an In App Purchases.

First off, I made a pretty big error when it came to implementing an ad into the game.  I wanted to have a full page ad prior to displaying the final score like you see in Words With Friends (Free) which is pretty easy to do with the Greystripe SDK.  However, I wanted to begin serving up my ads with AdMob because of the ability to have “House Ads” (ads that I can define to cross promote my own apps or friends apps).

Well, upon launch, I soon found out that the full page ad was freezing up in the Second Take app!  My devs couldn’t understand why this was happening because it was working just find in the test environment.  After a little research, they found out that with Admob you have to sign up to do the full page advertisements.

So in my opinion, here are the pros and cons of each service:

• AdMob lets you have “House Ads” but makes it extremely difficult to get the full page ads; I have also had a lot of “unfilled” requests for advertisements.
• Greystripe does a great job of loading full page ads but does not allow “House Ads”

I have to say that if I don’t get a whole lot of action off the “House Ads” I am probably going to strip out AdMob and replace it back with Greystripe’s SDK.

The other lesson I learned was how you should label your In App Purchases.  I did not know where you should put the verbiage about what the user is going to purchase and I put as my display name “Confirm Your In App Purchase”.  This was extremely foolish because that text is the default when a user clicks to buy an In App Purchase, and your display name is supposed to tell the user what they are about to purchase.  This costly error made my In App Purchases VERY confusing.

Instead, you should place what they are buying as the display name.  This is the text that will show up when the user chooses to buy your In App Purchase.

Place the text that you want to appear in the alert for the In App Purchase as the Displayed Name.

You see that the text for the display name will feed to the In App Purchase alert.

I really wish that I knew this beforehand, because, Apple must approve any changes to the display name for In App Purchases.  Naturally, this can take some time.  In my case, it took an additional week to get this changed and also to upload v1.0.1 to correct the app from freezing on the ad.

The old adage of time is money was particularly true here.  Somehow, I was featured again as a New and Noteworthy Role Playing Game (I had entered Second Take into that category thinking that you act out a role with a different accent; I completely forgot that Role Playing Game = RPG!), and while I was getting some good downloads (almost 1,000 in just 3 days), users were confused as to what they got from the In App Purchase and were frustrated by having the app freeze.  I think this could affect my possibility of being featured at a higher level, which makes this an even more costly mistake.

At any rate, I fixed the problems and am back to the races again.  I know that many of you probably already knew about this, but for those who have yet to install an In App Purchase to your app, I hope that this article can help.

(PS: If you are a indie dev with an app and would like to make a “House Ad” swap, I am interested in doing it for both BarCards Lite and Second Take; just drop me a comment and let’s talk.)