This was a guest post by Matt McAllister and Jaini Shah of Offerpal Media on Inside Social Games. The article addresses issues that developers should consider when implementing virtual currencies. It focuses on the tradeoffs of how to manage two types of currencies within a game.
You can download the full white paper here: Monetizing Dual Currency Economies in Online Games – October, 2009
Virtual economies are quickly becoming as complex as real ones. As more and more developers monetize their games by selling virtual goods and services, they face many of the same issues and challenges that leaders of real-world economies must deal with every day—inflation and deflation, balance and disparity, supply and demand, security and fraud prevention—plus other challenges that are unique to the online environment.
Some game and virtual world developers, such as Gaia Online, have gone so far as to hire full-time, professional economists to help them navigate the murky waters of creating a virtual economy, so important is it to their monetization numbers and overall revenue.
One common way many developers have chosen to deal with these issues is to implement a dual-currency system. In these cases, one type of currency is typically earned within the game by completing tasks or missions, and another currency can be purchased directly, either with real money or by completing advertising offers. We refer to the former type of currency as “in-game” currency, and the latter as “Real Money Transfer” (RMT) currency.
Why Two Currencies?
When implemented correctly, there are a number of advantages to creating a dual-currency system: it can help you balance the game economy and manage inflation, track and reduce fraudulent behavior, create a more level playing field for your users, and so on.
But the primary reason to adopt a dual-currency system is to engage and monetize the two distinct sets of users: paying and non-paying. Paying users are willing to fork over a few bucks, cents, or in the case of completing ad offers, a few minutes of their time in order to get premium items within the game. These typically make up between 5 to 15% of your overall user base. The non-paying users, on the other hand, just want to play your game for free. Paying users are valuable for obvious reasons. However, even though non-paying users might not generate direct revenue for your company, they can often be equally valuable, because:
* their mere participation creates value for paying customers
* they contribute to your word of mouth growth
* their visits and page views create advertising opportunities
* they might eventually turn into paying customers.
RMT currency is for users who are willing to pay real money for virtual currency instead of spending a lot of time in the game trying to earn it, whereas the in-game currency is for non-paying users who are willing to spend time playing the game in order to earn virtual currency but are not willing to spend real money on it. Having multiple currencies in a virtual economy thus helps maximize revenue and engagement across both sets of users.
4 Likely Scenarios
Two important questions that must be asked when first considering a dual currency economy are (1) whether you want to allow your currency to be converted from one type to the other (RMT to in-game currency and vice versa), and (2) whether players should be allowed to trade or transfer currency with one another. Allowing conversions and transfers opens up a slew of challenges that make it more difficult to balance your economy and prevent fraud, so many developers tend to go the safer, easier route of prohibiting both conversions and transfers. Let’s therefore begin by examining this type of economy first.
Scenario 1: Prohibiting Conversions and Transfers
Overall, this model is the least risky of the four because the game economy is completely under the control of the developer. The major advantage of this model is that it allows the developer to focus their efforts on one type of user – paying vs. non-paying – or the other depending on where they stand in the user lifecycle. For example, in order to motivate non-paying users to pay, developers may introduce a premium item that can only be purchased through RMT currency. In contrast they may also introduce certain items that can only be bought with in-game currency in order to motivate users to engage more deeply and spend more time in the game. The downside of this model is that you must give up potential virality and monetization, as we’ll see in the other scenarios.
Scenario 2: Prohibiting Conversions, Allowing Transfers
This scenario is commonly found in poker and other card-playing games, where the function of players transferring their “chips” to other players creates a powerful viral channel, such as when one poker player invites several friends and offers a few “chips” to get them started. However, this scenario creates many loopholes that can easily lead to crippling amounts of fraud if the economy isn’t closely monitored and managed, and most developers decide that the risk isn’t worth the reward.
Scenario 3: Allowing Conversions, Prohibiting Transfers
This scenario is mostly found in Role Playing Games, where many developers prohibit transfers but allow users to gain in-game currency in exchange for RMT currency at a fixed exchange rate. They may also let the paying users earn the in-game currency faster as compared to non-paying users when they use RMT currency. This model is less risky than scenario 2, since it helps keep the currency flow in check and also keep the developers in control of the game economy. It also supports monetization efforts by creating more reasons to purchase RMT currency.
Scenario 4: Allowing Conversions and Transfers
When player-to-player currency transfer is enabled, users can transfer either of the currencies (in-game or RMT) from one player to another, whether in a developer-controlled marketplace or through external methods like eBay. Found in applications such as Fish Wrangler, Fallen Sword, and Mouse Hunt, this type of system can often increase monetization by driving up demand for your RMT currency. Currency trading is specifically useful if the sinks (uses) for both currencies are different. For example, if there are certain premium items or special features that can be unlocked only through RMT currency, and there are certain activities or items which require in-game currency, then both types of users can benefit through currency trading. However, allowing player-to-player currency transfer can be risky and may lead to issues such as fraud and gold farming.
Tips for Implementing a Dual Currency System
Okay, so you’re ready to build a dual-currency system into your game. Here are a few tips to keep in mind as you do so:
1. Engage first, monetize second
Promote your currencies based on the users’ life-cycle. First engage them in the game through some in-game features and currency before promoting the RMT currency and driving them to the payments page. If you push RMT items before the users are fully hooked, you risk turning them off and losing them for good.
2. Balance your sinks
Maintaining a balance between the sinks for both currencies is very important. If there are a lot of sinks for in-game currency but very limited sinks for RMT currency, then it might affect the value of the RMT currency. In the same way, if there are limited sinks for in-game currency, then users may get stuck at some point and not engage in the game at all. Try to balance the RMT-only sinks with an equivalent number and type of in-game-only sinks to appeal to both types of users.
3. Offer multiple sources
For in-game currency, make sure there’s more than just one or two ways to earn the currency, or your users will quickly grow bored. For RMT currency, make sure you offer enough payment options – not just credit cards and PayPal but mobile billing methods, offline stored-value cards, and offer-based payment methods – to effectively monetize a broad set of users across different genders, age ranges and other demographic profiles.
4. Spell it out
Dual currency systems, by their very nature, are more complicated than single-currency systems, and therefore must be explained more thoroughly. Use all of the tools at your disposal – FAQs, customer support, in-game feedback and notifications, etc. – to explain the differences between your two types of currency and erase any confusion that might occur for your users.
5. Test, Measure & Optimize
As with everything in your game, you should be testing and re-testing all variables affecting your engagement and monetization. Test your exchange rate. Test your price points. Test anything and everything involving your virtual economy. Keep in mind that small fluctuations can often have a large impact on your overall revenue. At the same time, keep an eye out for inflation, imbalance, fraud and other factors that could be detrimental to your efforts, and quickly squash these before they have a chance to grow.
Conclusions
Dual currency systems aren’t for all games and all developers, but as virtual economies continue to evolve, many developers are finding that the rewards of having two currencies far outweigh the risks. If you’re thinking of implementing a dual currency system, take a look at your game and the types of users it attracts, and decide how you want to handle conversions and transfers. Do transfers make sense given the game dynamics? Do conversions make sense given your users’ willingness to pay, or would they simply rely on conversions to gain large amounts of in-game currency without actually engaging in the game (which might actually cheat non-paying users)?
Facebook yesterday for the first time revealed their 6 month 
Here is an article on 
The
We are thrilled to announce that Anu Shukla, CEO and founder, of 
Justin Smith serves as co-editor of 
Offerpal 
