Pricing Experimentation, a Game We All Must Play

Maximizing revenue on the AppStore is the goal of every developer. Setting the right price and changing it at the right time (increase or sale) is truly an art. Many variables are at play, but if you experiment carefully, you can find the sweet spot for revenue. This sweet spot may surprise you, so it's important to experiment, or you'll miss out on your revenue potential. Of course, when a competitor comes into the mix, you may have to adjust. It's very important to monitor things regularly, so you are not caught unawares. This post will reiterate a few things from a previous post of mine on pricing, and share some of our experiences with iOS price experimentation.

My education includes a BS in mechanical engineering and an MBA, which is valuable when combined with the application of real-world experience. I worked toward my degree while a Program Manager for a major seatbelt supplier, so I was managing multiple million dollar programs while attending grad school. Therefore, my class projects could be applied directly to my work, greatly enhancing the whole experience. My technical background is based on physical widgets, rather than software, so I was accustomed to higher Cost Of Goods Sold, during production. Software, on the other hand, after the design process, has a lot less incremental cost to produce. So applying what I learned in pricing using Cost Plus (cost to produce + profit desired) in automotive was a challenge in a Market Cost (what the consumer is willing to pay) type of pricing environment.

As stated, the goal of any businessperson is to generate the highest possible revenue. This goal is accomplished by either selling a lot, or at a higher price, since Price x Volume = Revenue. In basic economics, if the price goes down, the demand will generally go up, but in practice, it doesn't always happen that way. As covered in my previous post, starting price should be established by investigating the market, looking at competitors (substitutions to your product), and related applications. Lucky developers without much competition will have more flexibility on setting the initial price. If the competition is fierce, the price necessary will be very obvious and may have become commodity priced (consumer perceives all products as essentially the same, no matter who develops them). Games tend to fall into this commodity pricing.

When and how long to experiment?

Using data over a longer period of time might give you a better indication how that price affects revenue, but it also could include some outlying data, which will skew your results. For example, doing a price experiment at Christmas time is not a good idea—volumes are generally increased. Experiments right at release are also not good, as your exposure is much greater, affecting sales volumes. You want to find out how many sales you can get when people are finding you only on search, which is the normal scenario for a productivity app.

Date Wheel date calculator

While games, due to the brisk competition, almost require a 99c price, productivity apps tend to appear cheap when their standard price is 99c. They might sell well for a while because they are a low risk buy to most consumers. If you don't like it, you can delete it. However, since productivity apps are not huge overall sellers, revenue is very limited at 99c. Plus, since your customer has no investment in your app, they will tend to give up easier and ratings will be lower. Date Wheel was our first iOS app. We started with an initial price of $1.99. (On PalmOS, we charged $14.95, FWIW.) After the sales settled, we did our price experiment. We feel Date Wheel is a premium date calculator, but $4.99 was too high, as compared to the features offered by other $4.99 apps. So we wanted to find out if $1.99, $2.99, or $3.99 was the right price. We were a bit wary of $3.99, as many apps are not priced here, so the customer might get a mixed message with that price—such as why didn't we just go up to $4.99? Many of the stats reported by other sources indicated the same feeling on that price point.

Our results

Our sales at $3.99 were 160% lower per day in quantity, but only 31% lower per day in revenue as compared at $1.99, so $1.99 generated more revenue. In addition, at $1.99, more people had our app in their hands, so although not measurable, greater potential for word-of-mouth exists in the long term.

Next we tried $2.99. This price is where the surprise came in. Our sales at $2.99 were 39% lower in volume per day, but our revenue per day was 7% higher. These results told us that $2.99 was the sweet spot for our application.

Cooking Apps on the iPad

We have an iPad cooking app, Serving Sizer Pro Recipe Cards for iPad. The iPad is a different market; users will expect and accept higher prices in general. (Perhaps it's the screen size quandary—the bigger the screen, the higher the price for software?) Serving Sizer launched on Day One of the iPad at a $2.99 price, the same price as its iPhone counterpart. We kept this price until the launch mania settled and we could do a proper price experiment. (We had a nice Apple feature in "In the Spotlight" at iPad launch.) We had some competition, some direct (recipe apps for keeping your personal recipes), some indirect (mobile versions of the big recipe collections—like Epicurious). Our app's competitive advantage is the serving size scaling we call SmartScaling™. We have an algorithm that will not only resize the amounts, but refactor and optimize them for realistic use. (Example: instead of reporting 17 Tablespoons, our app will report 1 cup & 1 Tbsp. when resized.)

Our results

We opted to test $4.99 and $2.99 prices, skipping the $3.99 oddity. At $4.99, sales were 30% lower per day than at $2.99, but 20% higher per day in revenue. $4.99 was the right price for us!

Competition comes in: side by side feature

The price experiment rings true until something happens, like new competition, changes in feature sets, and Apple features. We discovered pricing changes were necessary as things changed. Serving Sizer was featured during a Summertime feature of cooking apps. We were ecstatic, since this was the first feature since the iPad launch feature. However, by this time, new competition had emerged, and they had done their homework. They included a few more features than we had (except for SmartScaling™) and were priced at $2.99, so on the surface, they appeared to be a better deal. Two counts against us. We were both featured, side by side, in the Summertime feature. So what happened? Day one of the feature—zero sales!! Wow, that threw us for a loop. Time for panic experimentation. We lowered our price to $1.99. Whew, sales back to normal, but not increased (lower price, right?). This result told us that the feature set was important, but really out of our control, since we were knee-deep in new app development. So, we met their price, to see what happened. Sales at $2.99 remained the same as at $1.99, so we kept the matching price until the feature ended. We couldn't garner increased revenue through sales, so we went for increased revenue through price. On a side note, I believe this is why games must lower prices to 99c when featured, and because they have a lot of competition. The price is the winning factor on the sale.

Competition lowers prices

After the Summertime feature, a couple more competing apps appeared. They all got their Apple features (Apple likes cooking apps on its iPad) and pricing was varied. The $2.99 app is still the best seller, then a $9.99 premium app came in. We were priced at $4.99. We released an update, matching much of the competition's feature set. People can choose our app, based on what's important to them, not just on price. We have some features others don't; they have some features we don't. (Eventually we'll update to release more features, but as a small developer, again, we're knee-deep in new app development.) Our $4.99 middle price was a sweet spot, because our feature set was also in the middle, and while some people went for the cheap, and others went for the premium app, others couldn't justify the increased features for the increased price of our competitor. I believe all three apps were winners. But, in came app#4. They also did their homework, almost copying verbatim the premium app's features. And they priced their app $3 cheaper. Their Apple feature got them a good bump and the premium app suffered. (I know this because I watch constantly.) Premium App countered by lowering his price to $4.99, which didn't affect New App as much, but it did boost Premium App. However, OUR sales were very effected! Premium App had matched our price. We all come up in the same search terms, so it's an easy choice on the surface—increased features at a lower price. Premium App decided to permanently lower his price. Plus he added some new features. New App countered with a sale to $3.99. I watched both apps go up and down and our sales go mostly down, unfortunately.

I did some quick calculations to determine our breakeven point in sales, if we were to lower the price. How much of an increase in sales would we need to maintain revenue (or increase it)? We lowered our price to $2.99 temporarily. Our sales shot up. Revenue actually increased as well. Our sale ended, sales plummeted. We quickly reset the price again and we regained our ground. In the end, $2.99 is our new sweet spot. Once we finish all versions of Trip Boss, our development focus as travel season starts, we will tackle Serving Sizer on the iPad again. We have a ton of ideas for improvements and are confident we will blow away our competition on features. Then we can begin to bring up the price again and search for that new sweet spot.

In conclusion, pricing experimentation is important, since more revenue is the goal, and no other method exists right now to find the right price. In addition, your sweet spot will change; you must continually monitor the market, especially watching what your competition is doing. In some cases, they won't affect your sales, but you need to be agile and adjust accordingly if they do. It's a game, but works best when you actually play it.