I’m currently limited to getting real-time information from what King County provides – the stops are all pre-defined. I’m working with the folks at King County Metro to try and get something together to improve the resolution of the stops (it would be nice to have *all* the stops in the application) as well as to arrange for a more stable data feed of updates. Currently I’m reverse engineering everything I need to know to provide this information.

We are currently experimenting with a $9.99 price point on an application that has lower-quality competitors for cheap or free. The first day we received a number of reviews complaining about the price.

But we also got a normal “FIRST!” five star review. Meanwhile we had someone else come in with a decent review that also suggests the app is a bit overpriced.

We’re considering an adjustment but are going to wait and collect some data. It seems that once the initial bump of being a recently released application is over you may be somewhat limited to people looking for your application.

I would think that you could get some decent data by fluctuating the price in these conditions.

Either way, the dollars could certainly be higher given the amount of effort that goes into creating the applications. I think a lot of people don’t realize the complexity that goes into performing anything of sophistication with the device. They just see things to tap.

Some useful links on pricing here:
http://discuss.joelonsoftware.com/default.asp?W1341

If there was a way to try before I paid, I might have been happy to pay $14.99, of course, I might also have decided it wasn’t worth it.

Price points are ridiculously tricky things to determine. Unfortunately Apple’s removed the number of downloads from its AppStore website, or I would’ve used that data to put together a yield curve – obviously a lower-priced application sells more copies than a higher-priced application but revenue per user is lower, so the challenge is to find the price which maximizes the product of audience x revenue per user.

The Seattle Bus application sounds extremely useful for people in its area – the type of application they might use every day for a very long time. Because of this, one possible alternative is advertising – if it’s done right, and if it’s done in a way that’s respectful of the user experience. At Pinch Media, we’re experimenting a bit with this, but we’re being careful, because it has to economically benefit the developer – if a developer replaces a paid application with a free application with ads, and the developer ends up making less money, then we’re worse than useless.

To determine whether an ad-supported application makes more sense, a lot of data’s necessary, and it does involve some guesswork:

* how often are my users using my application?
* how many ‘pages’ within my application are users looking at?
* is my application ’sticky’, or do downloaders stop using it?
* what advertising rate can I get (for ads that won’t drive away my users)?
* how much will my userbase multiply if I begin giving the application away?

Tricky questions to answer. We built a free analytics suite to help developers answer a few of them, among other things, but the last two questions are still getting worked out – I’m watching the market pretty closely and talking to a lot of advertising partners to help determine this. I can tell you right now that advertising isn’t likely to deliver the same revenue per user as a $9.99 download, but if the audience grew large enough, the product of audience size x revenue per user might very well be higher. It’s early – we’ll see.