A friend of mine, Curtis Herbert, has been writing a series of articles (1, 2, 3) he calls Slopes Diaries about the development and pricing of version 2 of his app Slopes. Although I’ve found Slopes Diaries to be interesting, and while I agree with a lot of what he’s written, a few things that he wrote in his most recent installment of the series struck me as wrong.
Curtis begins Slopes Diaries #3 by quoting himself from Slopes Diaries #1, “Lesson learned: Charge more. Then double it.” He then continues:
After that lesson you might expect I’d announce I’ll be raising my price to $49.99 with v2.
Nope.
I’m going free up front with Slopes 2.
Why would Curtis make Slopes free after earlier citing “charge more” as one of his lessons learned? He gives three reasons in his post:
- The first reason, he refers to as “The Acquisition Barrier”: “One of the biggest barriers to entry for someone to try my app is having a price on it.”
- The second reason, he refers to as “The Churn Barrier”: “Eventually, I’m going to saturate the market of people willing to pay up front for my app.”
- And the third reason, he refers to as the “The Survival Barrier”: “Here’s the thing: if I want any kind of serious chance to grow this into a business and do more for my users I need to find a way to charge more. My current price of $7.99 would be considered by many a premium price point, but even at that I have practically no money for user acquisition through advertising or customer support.”
While I completely agree with his third reason—he does need to increase his revenue per user if he wants to grow his business—his first two reasons for going free are almost certainly wrong. But he’s not the only one that believes them. I’ve seen these same justifications trotted out by other independent developers as well, so I want to take a moment to refute them.
The Acquisition Barrier
Let’s start with the first reason, “The Acquisition Barrier.” Curtis claims that an up-front price is the biggest barrier to entry for his app. I don’t think it is.
According to the SnowSports Industries America (a snow sports trade association), there are an estimated 13,000,000 adults in the United States who ski or snowboard in 2015.1 According to the Pew Research Center, 64% of American adults own a smartphone.2 According to Forbes, the iPhone accounts for 36.5% of smartphones in the U.S.3 Multiply those together and you end up with an estimate of the number of adult skiers in the United States who own an iPhone: Over 3,000,000.
Compare that figure with Slopes sales last year. According to Curtis, Slopes had about $10,000 in sales last year.4 Since Slopes sells for $7.99, that means Slopes sold about 1,250 copies last year.
It’s clear that Slopes has a lot of fans, but there is a lot of room for growth. Slopes’ 1,250 sales last year mean that it has penetrated only four ten-thousandths of the addressable market. There are millions of adult skiers in the U.S. that haven’t purchased, and have probably never even heard of, Slopes. This leads me to believe that up-front pricing is not, in fact, Slopes biggest barrier to entry. Customer awareness is.
The Churn Barrier
Now let’s talk about Curtis’ second reason for going free, “The Churn Barrier,” in which he fears that he will eventually saturate his market of customers. While I concede that is mathematically inevitable, I don’t think that’s the issue Curtis should be most concerned about at this point. Slopes sold 1,250 copies last year. At that rate it would take 2,400 years to saturate his addressable market. Even if Slopes experienced 10x growth next year and started selling 12,500 copies per year, it would still take 240 years for Slopes to saturate its addressable market. Simply put, even if Slopes experiences a sharp uptick in sales, its developer will be dead and in the ground before market saturation becomes an issue.
The Survival Barrier
What I find most interesting about Slopes Diaries #3 is that Curtis’ third reason for going free, “The Survival Barrier,” gives tacit acknowledgement to the fact that the root problem of Slopes’ sustainability is not in fact the two reasons that are explicitly stated, but rather that Slopes can’t effectively reach its target market to acquire new customers.
Inability to reach the target market is a real problem and one that many indies, myself included, struggle with. Charging even a relatively high price (by App Store standards) of $7.99 ($5.60 after Apple’s cut) doesn’t make it worthwhile to advertise, market, and generally do the things that need to be done in order to attract customers. The cost of customer acquisition is simply too high compared to the revenue per user.
The solution to this, as Curtis acknowledges, is to increase the average revenue per user. There are many ways to do this, and Curtis has apparently chosen to go with some variation on a freemium or subscription model. Those can certainly work (I use them myself) and it very well might be the best solution for Slopes, but I’d like to close with a look at a strategy that Curtis acknowledged, but dismissed: paid up-front premium pricing.
Charge More. Then Double It.
In Slopes Diaries #3, Curtis quickly considers increasing his paid up-front price, but just as quickly dismisses it:
I know the value of my app: at the end of the day Slopes is considered entertainment. Fairly so as I’m not making my users money with it. If I raised my price to say $50 to increase my revenue per user I’d lose so many sales that I’d have less revenue coming in monthly.
I’m not so sure. Curtis knows his customers better than I do, but I think the $50 price point he mentioned is interesting, at least, as a thought experiment.
First let’s consider the feasibility of a $50 price point. Skiing is an expensive hobby. Doubly so for those serious about it. Skiers have to pay for transportation, lift tickets, equipment, special clothing and more. But the fact that they’re skiing is proof that they’re willing and able to pay those costs. Skiers are a self-selected affluent market.
According to SnowSports Industries America, skiers spent over $4.5 billion5 on clothing, equipment, and accessories last year. That’s a lot of money. I bet there’s a lot of people who would consider $50 to be a reasonable investment to permanently document their day skiing and have tangible evidence of their bragging rights.
So now let’s imagine how re-styling Slopes as an app for “prosumer” skiers at a $50 price point might change Slopes’ business model. Most obviously, with no other changes, Curtis could almost certainly expect fewer sales. But as long as sales were more than one one-sixth their previous level, Slopes would still be making more money than at the lower level. But who says that nothing else must change? At $50 per download ($35 after Apple’s cut), that gives much more room for user acquisition. How might Curtis make use of that extra revenue per user? Google ads? Facebook ads? Podcast ads? Physical signage at ski resorts? Ads in ski-related newsletters? All of these seem like real possibilities when each sale brings in at least $35 in revenue.
Charging a higher price could provide a solution to the biggest problem that Slopes (and most indie apps) face—customer awareness. It could give Curtis a way to reach a larger, more valuable audience, and help him overcome the “survival barrier” that he identified.
Wrapping Up
To be clear, I don’t take issue with Curtis’ stated intention to take Slopes free with version 2. I have no insight into his business, or his plans. It very well might be that going free with Slopes (presumably with some sort of in-app purchase or subscription), is the best course of action. What I do take issue with are his stated reasons for going free. I take issue with them not to belittle Curtis or his app Slopes (it’s a well made app that’s functional and stylish), but rather to hopefully counter some misguided business thinking that seems to be common among indie developers.
I wish Curtis nothing but the best of luck with Slopes. I hope he find success, and is able to find a market that is willing to pay for the clear value that he’s providing. If you’re a skier and you’ve read this all the way to the end, you might consider supporting a fellow indie by buying his app.
Snow Sports Fact Sheet Note: I assumed that 50% of snowboarders, freeskiers, and cross country skiers were double counted, since no total numbers were provided. ↩
Apple’s iPhone Continues To Lose Market share Month to Month ↩
Since posting My Delivery Truck, I’ve gotten a lot of responses, both on Twitter and (in the best tradition of blogging) reply posts. Although many were supportive of my post, some developers took me to task. A lot of the same objections were raised repeatedly, so I’m going to concentrate on a blog post from Aleksandar Vacić titled Store your Love which nicely summarizes many of the objections that were raised.
Aleksandar writes:
The iOS App Store is not just a delivery truck. For starters, it is the delivery truck, the only one out there.
The App Store is the only marketplace where you can compete as indie iOS developer. As such, the way it works and behaves strongly influences everyone’s business on it.
The App Store is also your storefront which, for some time now, strongly favors early comers and big-budget apps not interested in earning money.
The App Store is also a dominant discovery truck where it fails spectacularly due to its abysmal catalog search.
The fact that there’s no viable way to re-monetize your existing customer base [such as upgrade pricing] severely limits available business options.
All of these things are true. In many respects, the App Store is hostile to individual developers. Unfortunately, we have to deal with the App Store the way that it is, not as we would like it to be. In the end we have two choices: compete in the App Store despite its hostility, or get out.
Yes, we should recognize the limitations of the App Store and suggest improvements, but we can’t count on those improvements being implemented. Most of the complaints that Aleksandar raises above have been pointed out time and time again over a span of years. And yet these limitations remain.
And yes, we should study the App Store so that we can better understand its behavior. Understanding the quirks of, for instance, the App Store’s broken search algorithm can help us optimize our App Store presence. But what happens when Apple changes that search algorithm? What would happen to all the apps with keyword optimized titles if Apple decided tomorrow to penalize apps with “spammy” titles in search results? Building your business based on the quirks of the App Store is like building on sand. You’ll never have a strong foundation beneath you.
So if the App Store has all these problems that Apple has shown no interest in fixing, and if it’s not safe to build our business based on the quirks that the App Store happens to have today, then what’s left?
What’s left are the fundamentals of running a business. Carefully choose a market that will pay for the value you provide. Plan from the beginning to market your app outside the App Store. Use the permissible payment methods to engineer recurring revenue into your app. What’s left is building your business on only those aspects of the App Store that you can rely on – payment processing and software delivery. Essentially, what’s left is treating the App Store as merely your delivery truck.
As tends to happen in regular cycles in our community, there has recently been another bout of handwringing over the difficulty of making it as an indie. Brent Simmons kicked this one off in his well written piece titled Love. And I don’t mean to make light of his piece. If you haven’t done so, I encourage you to read it. It encapsulates well a lot of the emotional angst that many independent developers are feeling about their businesses right now. Things aren’t as easy as they once were – especially in the App Store. As everyone in this business knows, supply is up (there are hundreds of thousands more apps in the App Store than there were just a few years ago), and prices are down. The App Store is no longer the land of milk and honey that it once was. As a result, we complain about it. A lot.
“The App Store is hostile to indie developers.”
“People won’t pay money for apps on the App Store.”
“The App Store should do more to help customers discover my app.”
But you know what? We developers need to get over it and stop blaming the App Store for our business troubles, because when it comes down to it, the App Store has only two purposes: credit card processing and software delivery. That’s it. Yeah, I know the App Store was originally sold to developers as a marketing channel, but it hasn’t been that for many years.
Today, the App Store is basically your delivery truck that takes cash on delivery. We wouldn’t blame a delivery truck for our business failure. It doesn’t make any sense. It’s not a delivery truck’s responsibility to ensure that there’s a market for our products. That’s what market research is for. It’s not a delivery truck’s responsibility to advertise our products or introduce them to customers. That’s what marketing is for. And it’s not a delivery truck’s responsibility to prop up prices in the market place. That’s just not it’s role.
So the next time you hear a developer complaining about the App Store, mentally replace “the App Store” with “my delivery truck” before evaluating the reasonableness of the complaint. As I think you’ll see, most complaints about the App Store just don’t hold water.
“My delivery truck is hostile to my business.”
“People won’t pay for apps on my delivery truck.”
“My delivery truck should do more to help customers discover my app.”
Instead of blaming the delivery truck for our business problems, we need to double down on the business side of our software businesses. We need evaluate the market for an app before building it. We need to go to where our customers are and market our products outside the App Store. We need to research whether customers would actually pay a sustainable price for our app – before we even open Xcode. We need to take responsibility for our own success and our own failure and stop blaming the delivery truck for our problems.
Note: I’ve posted a follow-up to this article titled, My Delivery Truck (2nd Delivery Attempt).
If you had asked me yesterday which Swift would be the topic of conversation among iOS and Mac developers today, I would have put money on it being the programming language and not the music star. And I would have been wrong, because Taylor Swift set the world of Apple watchers abuzz today by airing complaints about Apple’s new Apple Music service on her blog. In her post she lays out a well-reasoned argument that Apple Music’s payment policy is unfair to artists since creators aren’t compensated for listens by Apple’s customers during a three month trial period. As a result, she explains, she will not be releasing her newest album on the service. After reading Swift’s post and the resulting banter on the Internet, it’s tempting to dismiss the entire argument with some handwaving. “Of course Apple’s payments are unfair to creators. The entire music industry is built on exploiting creators. So get over it, because it’s a better deal than you’ll get from anyone else.” But forward thinking developers should take notice, because this controversy may hit closer to home than they expect.
First, no one is saying that Apple is doing anything legally wrong. They negotiated a contract with terms that are favorable to them. That’s what big companies do. And Apple will have every legal right to stream most artists’ music without compensation during that three month trial. So no one – not even Taylor Swift – is saying that Apple is breaking any laws. What Swift is saying, and what I agree with, is that it’s a bad deal for artists. Creators should be compensated for the use of their creations.
This debate is important to app developers because, whether we like it or not, digital music has been devalued – just as our digital creations have been. In just a few short years people have gone from paying tens of dollars for an album, to paying 99 cents for a single track, to paying pennies or even nothing to stream an entire library of music. This parallels in a rather frightening way the history of the App Store where, in an even shorter amount of time, mobile software that once sold for tens of dollars now is lucky to sell for 99 cents. Just as the music industry, now including Apple, has moved to an “all-you-can-eat” subscription model to bring down the per title cost of music below that 99 cent threshold, it now doesn’t seem unreasonable that a similar all-you-can-eat subscription model might be used to allow per title pricing of apps to fall below 99 cents as well1.
I think that such an all-you-can-eat subscription deal would be disastrous for indie developers, but a full explanation of my reasons for that belief is more than I want to tackle today. Today what I want to point out is that this fight for fair compensation is not just a fight for musicians. It’s a fight for software developers as well. Apple is a great negotiator, and the company will take everything that it thinks it can get away with. Our problem as developers is that we’re in an even worse position than a lot of musicians. Musicians at least have alternate channels for their work. iOS developers only have one – the App Store. Mac developers who distribute solely through the App Store are in a similar position. If you don’t think that Apple would impose similarly unfavorable terms upon its developers when it’s Apple that holds all the cards, you’re fooling yourself.
So if you are a developer who thinks that apps may one day be subject to a similar all-you-can-eat pricing model, it’s in your interest to lend your voice in support of Swift’s argument, because the terms under which musicians work may one day be the model for the terms under which you work as well. Tweet about it. Tell your friends. Lend your voice in support of the notion that digital creations have value for which their creators should be compensated. And after you’ve done that, start investigating ways to strengthen your own position. If you’re an iOS developer, start looking at ways to take your app to Android. If you’re a Mac developer, investigate Windows. And everyone should probably be looking at web-based software as a service. Start making plans now for a day when you might have to bravely say “No” to a bad deal, just as Taylor Swift has done.
Credit to Dave Wiskus for first putting this idea in my head. https://twitter.com/dwiskus/status/607977149560033281 ↩
I was reminded recently of episode #216: The Hustle of David Smith’s excellent Developing Perspective podcast. “Reminded” isn’t really the right word, though. It’s more that it’s stuck with me since I originally listened to it in April. In that episode, David talks (among other things) about the importance of hustle for an indie developer. And he’s right. Hustle is an essential part of indie life.
As an indie, you have to always be on the look out for the next opportunity. When you find it, you have to grasp it. And when you don’t, you have to manufacture it. You’ve always got to be looking for the next client, the next line of business, the next marketing opportunity. You’ve got to hustle. You’ve got to recognize and exploit any advantage you have over often larger competitors. And even when you don’t find opportunity or advantage – especially when you don’t find opportunity or advantage – you’ve got to take steps to create it.
Indies need to create those opportunities and advantages because they don’t have a lot of room for error. Pick the wrong product at the wrong time, and you’ll soon find yourself looking for work. Pick the wrong client or the wrong rate, and you’ll find your contracting business in peril. Hustle is a force multiplier. It gives you wiggle room to recover from a mistake. It gives you another path to pursue when a door shuts in your face.
I didn’t use to think that I had hustle. If you had asked me 10 years ago, “hustle” wouldn’t have been a word that I would have used to describe myself. But, as it turns out, I was wrong. Over the last several years, particularly since I started my business, I’ve discovered that I hustle pretty well. But if you don’t, don’t worry – it’s a learnable skill. Keep an eye out for areas of expertise that you have access to, and then brainstorm products that might come from them. Look for an audience for your product or service, and then approach that audience. Find resources you have access to, and then use those resources. In short, find your advantage and then take action. Today.
If you’re a U.S. taxpayer with apps on the iOS or Mac App Store, you may have received from Apple a Form 1099-K, Payment Card and Third Party Network Transactions, which reports to the IRS your gross revenue from App Store sales. You may have also noticed that the amount reported on your Form 1099-K doesn’t bear much resemblance to the payments actually received from Apple.
There are a couple different reasons the amount Apple reported might not match the amount you received. First, the payments that are reported on From 1099-K are gross payments that you received before taxes, fees, and (notably) Apple’s 30% cut. Second, the amount on your Form 1099-K may not represent your worldwide revenue. Apple only reports revenue on Form 1099-K for regions that have more than 200 payments and more than $20,000 in total gross payments in the year. Because the thresholds are reached on a region-by-region basis, you may exceed those thresholds (and thus have your revenue reported on a Form 1099-K) for the U.S. and Euro Zone, for example, but not in India or Russia.
As you can see, it all gets very complicated, very quickly. In theory, the amounts reported by Apple on Form 1099-K should be able to be reconciled to payments received from Apple using the financial reports available in iTunesConnect (since those reports list every sale, its region, fees, currency conversions, and more), but in practice this is a task that is beyond most developers. Most independent developers I know look at the Form 1099-K when it arrives, scratch their heads a bit, and then move on.
The problem with that, of course, is that Form 1099-K is an official tax document that is sent to the IRS, and when the IRS sees an amount of revenue reported, it expects to receive tax on that amount. So if you find yourself in the situation where the amount reported to the IRS on Form 1099-K is more than the amount you reported on your income tax return, you can expect that some questions will be asked. You might even find yourself with an extra tax bill.
Apple only began issuing Form 1099-K to App Store sellers starting with the 2013 tax year. (Affected developers would have received their first Form 1099-K in January 2014.) So until recently, any problems that developers may have faced because of discrepancies between amounts reported to the IRS by Apple and those self-reported by the developer were only theoretical. That may be starting to change, though:
So what’s a confused developer to do? How should you deal with a Form 1099-K that doesn’t seem to match your payments from Apple? Well, first of all, get yourself a good accountant if you don’t already have one. I recommend finding a Certified Public Accountant that deals regularly with small businesses. You might also want to start reporting your revenue gross with an offsetting expense, instead of net. In other words, instead of recording a $7,000 payment in your books, you might want to record $10,000 in revenue with a $3,000 expense that represents Apple’s 30%. This should prevent the troublesome situation where Apple reports more revenue to the IRS than you do. As always, though, don’t take my word for it. Ask your accountant.
For more information about Form 1099-K, see the IRS’s 1099-K FAQ or the Instructions for Form 1099-K. For more information about Apple’s policies regarding From 1099-K, see the Banking and Tax FAQ in iTunesConnect.
Since publishing my piece on revenue distribution in the App Store yesterday, I’ve gotten some feedback from readers asking how valid my extrapolated data is. Some have pointed out that I’m working with a limited data set from only one app that might not hold for all apps. Others have pointed out that the daily revenue data that Marco Arment provided did not include any data from the period when Overcast was at the top of the U.S. Top Grossing list, so it’s possible that the curve isn’t really a strict power curve all the way up the charts.
These are valid criticisms. So let me respond by releasing more data; the only other useful data that I have available. In response to Marco’s post, William Wilkinson published financial data from his own app, Manual. Manual is a photography app that did well on the U.S. Top Grossing list (reaching as high as number 104) in September 2014, so the Manual revenue data is both contemporaneous with Overcasts’s and useful for examining the upper reaches of the App Store. The problem with the data Wilkinson released is that the daily revenue graph has a very low resolution. In reading the graph, I could estimate daily revenue to only ±$133. That’s not such a big deal at the high end, where daily revenue is measured in the tens of thousands of dollars, but in the long tail where revenue is measured in the hundreds of dollars, a $133 error is quite significant. With this limitation in mind, below is the graph of Manual’s data overlaid onto Overcast’s.
As you can see from the graph, the revenue curve for Manual breaks upwards a little before Overcast’s does, but overall they are very similar curves. In particular, notice that the “head” end of these graphs (U.S. Top Grossing #1 to about #1000) follow similar paths. It seems likely to me that the differences between the graphs can be accounted for by the daily fluctuations of the App Store, differing ratios of U.S. to global sales, and the inherent inaccuracy that comes with estimation.
So what does this mean? Well, it makes me think that I was on the right track with my original post. While the the exact revenue figures that I cited in The Shape of the App Store may be off little, it seems likely that they are at least in the right ballpark. They may even be somewhat conservative estimates if Manual’s revenue figures are to be believed. Whatever the exact figures, one thing is clear: Revenue is heavily skewed towards the top of the charts, to a much higher degree than I, at least, expected.
Every developer knows how tough it can be to make a living on the App Store. There’s a lot of money being made there, but it’s not spread very evenly. Those at the top of the charts make the lion’s share of revenue, while the vast majority are left to fight over the scraps. But exactly how lopsided is it? And how does that affect an indie developer’s chances of finding success? For a long time, I was resigned to never really knowing the answers to these questions, because although there’s wide consensus that the distribution of revenue in the App Store is best represented by a power law, I had no way of knowing how sharply or gently the graph of that power law curved. My own apps haven’t spent enough time on the Top Grossing list to collect the data I would need to make a prediction, and Apple sure isn’t sharing it.
And then on January 15, Marco Arment gave me (well, all of us) a belated Christmas present. In his piece titled Overcast’s 2014 Sales Numbers, Marco shared the financial performance of his podcast player, Overcast, through a series of statistics and graphs. Because the information he shared was so detailed, and because Overcast has been so successful, I realized that Marco’s post could provide some insight into how an app’s rank on the U.S. Top Grossing list correlates with its daily revenue.
Before we get to the results, it’s important to first discuss their limitations. The figures that Marco provided for Overcast were very detailed, including daily revenue information, but they weren’t complete. Of particular importance, the revenue figures that Marco published were for global revenue. There was no breakdown of the revenue provided by nation. This means that it’s possible only to compare rank in the U.S. App Store to global revenue. It’s not a perfect apples to apples comparison, but since the U.S. App Store is the largest national App Store both by downloads and by revenue, I think it’s a reasonable comparison to make.
To provide some context to the results, you may be familiar with the Pareto distribution. It’s the origin of the classic “80-20 rule” that’s used to explain so many phenomena that obey a power law. “Twenty percent of the people in an organization do eighty percent of the work.” “Twenty percent of the population control eighty percent of the wealth.” You hear these types of statistics a lot, but they’re usually not very accurate. Often, they are useful as a first estimate at best. So I didn’t actually expect App Store revenue to obey the 80-20 rule. In fact, I expected it to be a much sharper curve, representing even greater disparity in the distribution of revenue than the 80-20 rule would suggest – maybe a 90-10 split, or even a 95-5 split. As it turns out, the revenue distribution curve of the App Store is even sharper than I imagined.
I expected a “hockey stick” curve that’s characteristic of power law models, but I didn’t expect one like this. The hockey stick breaks upwards at around position 870 on the U.S. Top Grossing list. With about 1.2 million apps in the App Store at the time the data was collected, that arguably puts 99.93% of apps in the “long tail” of the App Store. The “head” of the App Store, those 870 top grossing apps that make up 0.07% of the App Store population, collect over 40% of the App Store revenue that’s paid out.
Luckily, there’s a lot of money to be made in that long tail. At the top of the long tail, in position 871 on the U.S. Top Grossing list, an app still makes over $700 in revenue per day. That’s almost $260,000 per year. Even number 1,908 on the U.S. Top Grossing list makes over $100,000 per year. In fact all apps above number 3,175 on the U.S. Top Grossing list produce enough revenue to at least make its developer the United States household median income for 2014 ($53,891). And this is just for a single app. Most indies I know develop more than one app simultaneously. Developers who can put together a collection of apps that rank at about 6000 on the U.S. Top Grossing list (about $25,000 in revenue per year) stand a good chance of building an app business that can sustain them and their families.
Now, all of that is not to suggest that it’s easy to build a sustainable app business. It’s not. But, by doing some basic business things right – like finding a profitable niche, solving a painful problem, effectively marketing apps, and generally doing the things that have been suggested time and again at conferences and on podcasts – a developer can dramatically increase his odds of out performing the multitudes that just slap any old thing up on the App Store and hope for the best.
So, with even fewer people than I expected making “yacht and helicopter money” in the App Store, I remain hopeful for my fellow developers. There’s a lot money circulating in the ecosystem, and a developer operating at indie scale only needs a little bit of it. It seems that even with the revenue curve tilted so heavily towards the big hits, the shape of the App Store still allows room for sustainable businesses to develop in the long tail. It seems that developers who work hard, mind the details, and treat their business like a business have a real chance of making it.
Note: I’ve posted a follow-up to this article titled, The Shape of the App Store, Redux that responds to some valid criticism that’s been received regarding the data set used here.
Update Jan (20° 20°)15: This post was updated to clarify that an app’s rank in the U.S. Top Grossing list is being compared to its global revenue.