Updated November 7, 2014 11:56 pm - One key question some Windows Phone developers struggle with when putting an app on sale is: how much should I charge?
The Windows Phone Dev Center gives developers more control over pricing because Dev Center now lets developers set a unique price (from available price tiers) for every country or region where paid apps can be sold. This capability, not found in all major app stores, provides an exciting new way to fine-tune your sales strategy. Furthermore, market-specific pricing applies not only to apps and games, but also to in-app items offered through apps built for Windows Phone 8.
I know something about the pricing dilemma because in addition to working on the Windows Phone Store business team, I’ve published more than 20 apps in the Store myself, many of them paid. In this post I’ll explore some of the things I consider when trying to determine the best price for my own apps, and share some suggestions on how to take advantage of Dev Center’s pricing and analysis features.
One price or more?
Since custom pricing requires time and effort, the first question you might be asking yourself is: Is it worth the trouble?
My take is that the single-price strategy is useful when your app revenue is small, since it’s very simple to execute and easy to manage. Simply set a single app price in Dev Center and Microsoft will use that price as reference to calculate the prices for all markets and regions. Once your app revenue is enough that it’s worth spending a few hours optimizing price, it’s time to explore setting your own price per country or region.
The price is right: The Windows Phone Dev Center now allows for market-specific pricing
Even if you plan to set a single worldwide price, there are a few factors worth considering to help decide on a price point, including what your competition is charging for similar apps in the Windows Phone Store and what people are charging for comparable apps or games on competing platforms such as iPhone and Android. (I’ll get back to this in a moment.)
Zeroing in on the right price
As I mentioned, there are really two big questions that need to be answered when it comes to pricing an app. The first is whether to charge a single price or by market. The second basic question is: what to charge? To answer that, it can be worthwhile to first do a pricing analysis to help identify markets where a differentiated price makes the most economic sense. Here is a checklist I go through when trying to assess this for my own apps:
Step 1: Understand the competition
Investigate how competitors are pricing similar apps, both on Windows Phone and on other platforms. If similar apps are priced at a certain price point in a country or region, it probably won’t be effective to charge a higher price unless the app has features that competitors don’t offer.
Step 2: Analyze app data to understand regional trends
In Dev Center, use the Reports function to get all the relevant info about the app: total downloads by type (free, paid, trial) and downloads by country or region. Also, analyze downloads by time of day. Note which markets have a higher number of paid apps and which apps are driving the majority of purchases. This info helps to determine the markets in which it might be worth customizing the app price.
Step 3: Determine whether to raise or lower prices
Are there markets in which consumers might be willing to pay more for the app than what is currently being charged? Here are a few scenarios that might warrant raising the price in a specific market:
- The app has a unique value in that market. For example, a map app for Paris.
- The app is localized for the market. A book app in Spanish, for example, might sell better in Spain or Mexico than in Iceland.
- The app is sold in a place where the cost of living is higher. In such places, consumers might be used to paying more for goods and services.
- The app becomes more relevant at certain times of year. An app might sell better and for a higher price at certain times of the year. For example, an app centered on a religious holiday might be worth more to consumers around specific dates, in specific countries or regions.
By the way, in some cases the better option might be to lower the price of the app, or make the app free and focus on revenue through ads or in-app purchases (enabled in Windows Phone 8 apps). This might hold true, for example, in markets where consumer purchasing power is lower, or where consumers show a preference for free apps over paid ones. Ultimately each developer needs to analyze his or her own app data to know.
Step 4: Spot-test price changes
After I’ve identified markets that might benefit from differentiated pricing, I use Dev Center to experiment with pricing in those markets. One good way to do this is to set different price points for various markets, test them for a week—to factor in purchases made across all the days of the week—and then evaluate the results.
This allows for calculation of what economists call demand elasticity: the extent to which consumers are price sensitive in specific markets. With this data in hand, developers can better determine the best prices for their apps.
Step 5: Monitor customer feedback and adjust pricing as needed
Monitoring customer feedback provides valuable information that can be used to fine-tune pricing strategy. There’s a new feature in Dev Center that developers can use to quickly access all app ratings, from all countries or regions (Dev Center>App Details>Reviews>All). Closely monitor feedback after a pricing change to understand customer response. Using Dev Center reports, developers can monitor sales over time as one way to determine if new pricing is having a negative effect on sales at any point.
Let’s finish with an example. Let’s say my game Foo is currently priced at $2.99 in my home market and I’m trying to decide what to charge in other regions. The prices I’m considering are $1.49, $2.49, $2.99, and $3.99.
To start, I test each of these prices for seven days in markets I’ve identified as good candidates for differentiated pricing. The chart below shows the results.
As expected, the number of paid units goes down as the price goes up. At the lowest price ($1.49), 11 percent of all downloads are paid versions. At the highest price ($3.99), there are 1,300 downloads, but only 40 of these, or 3 percent, are paid. Depending on the price, my weekly revenue for Foo ranges from $160 to $224.
The bottom line, as the chart shows, is that by reducing the price to $2.49, I’m able to grow my revenue from $8,551 to $11,653—or 36 percent more a year!
This same exercise can be applied to other countries or regions. Typically I do this only for markets that have high download numbers and therefore a more significant impact on income from the app.
Share your own tips
In the last weeks I’ve been conducting experiments on several of my apps using the new custom pricing option in Dev Center. For example, I bumped up the price for the Spanish-language version of one of my apps by 50 cents in Spanish-speaking markets. For another app, I raised the price by the same amount in two countries where download data suggested users found that app especially useful. The results so far are encouraging: no decrease in paid downloads. (I did try a much higher increase for one of the apps— from $0.99 to $4.99—but that didn’t work out too well; paid downloads dropped to almost zero.)
Product pricing is a fascinating and complex subject that fills entire books. I hope you’ve found this post helpful and would love to hear about your own experiments and tips in comments.