Monthly Archives: September 2011

Ad supported vs $.99 – My experience

Posted by on September 11, 2011 1 comment

I love football, and I can’t tell you how excited I am that it is back on this week. I love playing fantasy football even more, and have even made an iPhone app for fantasy football drafts the past few years.

This isn’t my day job, and I know I’ll never get rich doing it. My main goals are to get some more experience developing for iOS, earn back my expenses, and help pay for NFL Sunday Ticket.

Last year, my app was sold for $.99, and I made a small, but reasonable amount of money (something between $400-$500). This year, I decided to see what the results would be like if I offered it for free, but monetized it using advertising. At the last minute, I decided to make another version that cost $.99, but was identical except for the fact that it lacked ads – ads are sometimes kind of annoying, and as a user I’ll often opt to pay $.99 rather than deal with them.

Now that the fantasy football draft season is over, I thought it would be kind of interesting to take a look at the results. The limited shelf-life of this app (drafting season is at most 2 months long, and the average user won’t use it more than a few hours per year) makes a less than ideal case study for ad-supported vs paid, but I think there is some interesting data anyway. So, here is some stuff I learned from this:

1) Free apps get downloaded way, way more than even $.99 apps

This is obvious, of course, but the magnitude of the difference is worth pointing out. The free version of my app was downloaded 11,450 times, whereas the $.99 version was downloaded only 239 times.

My takeaway from this is, if you’re going to try to sell an app that is going to have free competitors, you’re really going to have to work hard to differentiate yourself from the free versions. Free apps are simply going to eat up the lion’s share of the market.

2) But they don’t make nearly as much, per-user

Those 11,450 downloads translated into several hundred thousand ad views, resulting in total revenue of $111.25 for me. This is very slightly less than $.01 per download. The paid version brought in $167.34 from its 239 downloads – despite having roughly 1/50th of the downloads, it actually out-earned the ad-supported version by ~$55.

I almost certainly made a lot less money this year by offering a free version supported by ads – if even 2% of the users who downloaded my free version would have shelled out $.99 for the paid version had it been the only option, I would have come out ahead.

Had this app been something people would use year-round, it might have worked out a little better.

Lessons for next time

Despite this not being the ideal outcome, I learned a few lessons from this. Your app has to be immensely popular to make any sort of worthwhile revenue from advertising. I don’t think niche apps or apps with limited lifespans are good candidates for ad-supported versions. Also, I think there are probably better ways to utilize a free app than just throwing ads on it.

Probably the best use of an ad-supported app is to use it to promote additional, paid functionality. You could do this through In-App Purchase or by selling a different version of the app altogehter. The important thing is to differentiate the two beyond just advertising – the paid version should also offer more features. I would have done something like this, but I given the short life-span of these apps and my late decision to offer both versions, I didn’t have time.

Going this route gives you a chance to use your likely more popular free download as an opportunity to promote the paid functionality. Just be careful to offer enough functionality in the free version to make it worth downloading – free apps that are utterly useless platforms to promote paid functionality get (rightly) harsh reviews in the app store.

HTTP Message basics, and POSTing form data in Graphical HTTP Client

Posted by on September 4, 2011 No comments

“The POST body isn’t working correctly! I add in something like name=spencer&age=29, but the server doesn’t get the parameters. Please fix your program!”

After a few support requests and 1 one-star review related to this issue, I figured it was at the very least worth a deeper explanation. If you’ve googled this and are just looking for the answer here it is:

You need to set the Content-Type header to ‘application/x-www-form-urlencoded’.

That said, I think it is worth spending a few minutes to learn about HTTP messages and why this is required. Removing levels of abstraction and learning more about what is going on underneath makes you a better developer and is usually a lot of fun, too. This is a big part of the reason I’m giving up my evenings and weekends to go back to school for a CS degree.

Anyway, here is a quick primer on HTTP messages and why you have to add the header above…

The HTTP message

When you make an HTTP request, you’re connecting to an HTTP server at a given IP on a certain port and sending it a message. It then processes that message and gives you some sort of response.

What does that message look like? It consists of 3 parts:

Request Line. This tells the server what resource you’re looking for and what HTTP method (ie, one of GET, POST, PUT, DELETE, etc..) you are using. It also specifies the version of the HTTP protocol to use.
Headers. These give metadata about the message, such as the Content-Type, the Host, what type of content you’ll accept, and a whole bunch of other things.
[CRLF]
Optional message body.

So, for example, if you came to the homepage of my blog, your browser sent a message to my server that looked something like this:

GET / HTTP/1.1
Host: www.spenceruresk.com
[CRLF]

Pretty simple, right? Let’s look at a slightly more complex example. Let’s say I was hosting a Twitter-like service that allowed you to post status updates with simple HTTP POSTs. A request you’d send might look something like this:

POST /twitterClone/updateStatus HTTP/1.1
Host: www.spenceruresk.com
Content-Type: text/plain
[CRLF]
Check out this crappy cellphone pic I took at a concert!

In this case, we’re POSTing some data and telling the server what kind of content it is – in this case, it is just plain text. Pretty simple, right?

Content-Type and message bodies

One header in particular – Content-Type – is relevant to the issue and is worth talking about. When you send a message body, it can represent any number of types of data. For example, it could be plain text, a GIF, form data, or a JSON document. In order for the server to properly decode the body, you have to tell it what it is you’re sending it. The Content-Type header is how you do this. For a list of common MIME types, this Wikipedia article is useful.

Submitting forms

So, what HTTP message is generated and sent to the server when a user submits a form in their browser? The answer is that it depends. If the form is submitted via GET request, the message would look something like this:

GET /signupform?name=Spencer&age=29 HTTP/1.1
Host: www.spenceruresk.com
[CRLF]

Your web framework will then take the key/value pairs in the query string and make them available as request parameters.

What if it is a POST?

POST /signupform HTTP/1.1
Host: www.spenceruresk.com
Content-Type: application/x-www-form-urlencoded
[CRLF]
name=Spencer&age=29

The Content-Type line is critical – it tells the server “I’m sending you URL-encoded form data in the message body.” Most/All web frameworks see that, then decode the body and make each key/value pair available as request parameters.

If you don’t tell it that you are sending URL-encoded form data, it doesn’t decode the body and make the parameters available.

Conclusion

Hope that helps make it at least a little bit clearer. In the next version of the app, I’m thinking about adding some sort of Content-Type autodetection (that you can turn off) to help avoid people getting confused and frustrated in situations like this.