Once iOS publishers have developed their application, paid $100 for having it distributed on the Apple App Store, gone through the long approval process, they finally have to chose a price.
But before chosing a price, they could ask themselves:
This is really important. If 99% of the competitors priced above $4.99, you might set your price at $3.99, and potential buyers would be happy to buy from you (for the time being, we do not take quality in consideration.)
The ubiquitous Gaussian, bell-shaped curve is of no use in the realm of prices: There is nothing like a bell shaped price distribution. The chart below shows how the prices of 172,083 applications sold on the Apple App Store are distributed (if you wonder how to scrape this information from iTunes, have a look at this article):
About 85,000 applications are priced at $0.99. The number of applications priced $1.99 is approximately 1/4 of those priced $0.99. The ones at $2.99 are approximately 1/9, and so on. In other words, the number of applications sold at a certain price looks inversely proportional to the price squared. If you want to know more about power law distributions, see the Pareto-Zipf-Mandelbrot distribution on Wikipedia. Enough to know that the measured average changes when there are more data –in our case the average price of applications is $3.5.
Power law distributions are better displayed on a logarithm-logarithm scale*, i.e. plotting the logarithm of the number of applications versus the logarithm of their price. The logarithmic-logarithmic plot of the distribution of prices on the Apple App Store looks like this:
A few points are placed close to a straight line: These points correspond to the number of applications sold at 1$ and multiples of 5$ (one cent is almost always subtracted to the round price: actual prices are 0.99$, 4.99$, 9.99$ etc). Interestingly, the number of application selling for odd prices, like, for example, $7.00, is much lower then the number of application selling for $4.99 or $9.99. Therefore the point corresponding to $6.99 lies well below the straight line.Although prices can be freely chosen, most sellers price their application at multiple of $5 (minus 1 cent).
Let us imagine a publisher of a very innovative application, which, at launch, has no competitors. The marketing manager tries different prices, and notices that two prices generate the highest revenues: $3.99 and $4.99. When the price is $3.99, the publisher sells 50 units a day, while 40 units are sold if the price is $4.99. The total revenue is $200 a day in both cases. So, if there is no competition, both prices will do.
As we know, competition is alert and after a few months, other publishers enter the market with similar applications, which are also priced at $3.99 or $4.99. A few months later, the publisher discovers that 90% of the competitors prefer, for some reason, to price their application at $4.99, and only 10% at $3.99. By setting the price to $3.99, our publisher can price-differentiate its product and confront less competition.
The take-home message is the following: By analyzing the distribution of prices, it is possible to spot price regions that are relatively empty, that’s what we call “price-gaps”. Price gaps offer the possibility to diversify a product by setting its price in an uncommon range. In a market where competition is hard, a handful of cents can make the difference. Our simple analysis provides a reference pricing on which to base marketing decisions.
iOS developers would profit from the historical rating, reviews, and rank information that iTunes provides and so should be able to easily download and store such information. Unfortunately, Apple is a tad paranoid with regard to the information it provides on the App Store data. We think that a app distributor (including Apple) should provide programmatic (API) to access its store’s data. If you want to build your own “App Store Scraper”, you will find below a few hints.
Developers normally access the App Store via Apple iTunes. iTunes behaves like a specialized browser that sends HTTP queries to a web-server. The web-server replies in different ways depending on whether it identifies the caller is iTunes or a web browser. If you want to see all reviews in the UK for the application with id=xxxxxxxxx (look for a real id starting from here)., you should request the file:
If you paste this URL into your browser, you won’t be able to see the same amount of information you would see on iTunes. It might also be that you cannot see anything at all, and your browser will ask to open iTunes. Still, the URL above is the same visited by iTunes –the only difference being in the way iTunes sends the request. Fortunately, you can cheat Apple’s server into believing you are using iTunes when you’re actually not, by making a request via cURL, an common application on most GNU/Linux distributions, that has been ported also to Windows.
2. Open a terminal window (META+R, digit CMD);
Once you have cURL installed, both on Windows and *nix, cut and paste in your terminal:
curl -H ‘Host: itunes.apple.com’ -H ‘Accept-Language: en-us, en;q=0.50’ -H ‘X-Apple-Store-Front: 143444,5’ -H ‘X-Apple-Tz: 3600’-U ‘iTunes/9.2.1 (Macintosh; Intel Mac OS X 10.5.8) AppleWebKit/533.16”http://itunes.apple.com/WebObjects/MZStore.woa/wa/customerReviews?s=143444&id=xxxxxxxxx&displayable-kind=11’
If you are prompted for a password, just type enter. You should see now the actual XML file seen by iTunes, with all reviews.