The main idea is that right now monetization through “offers” is through a complete separate “offerwall.” An offerwall, like Superewards and OfferPal, is a separate page in the app that shows offers. The user decides which offer to complete and then eventually they will be awarded the offer currency.
This is very convenient and easy to integrate, which is why it was adopted so widely, so quickly. The problem with the offerwall? It lacks context. It’s a daunting wall of random offers, many of which are not interesting and the user has seen before. A simple solution is to use context-awareness improve both the usability and overall effectiveness of the offerwall:
- Amount of offer currency: For example, if I have 4 favor points and I need 16 to get the 20 point platinum hunting rifle, I should be presented with offers in the 10-20 range, not a wall of offers from 1 to 200 pts.
- Timing of the offers: If the game popped up an offer for just the right amount, right at the moment when the user desire for the item is most acute.
- Look and feel: The offerwalls use the offer providers chrome (or “look and feel”). So game designers don’t have a way of customizing the look and feel of the offers presented. As a result, we quarantine the offerwall off in a corner of our application, so we don’t break the overall aesthetic feel of our games.
To do these things, the offer providers need to give us an API into their offer system. Then we can decide which offers to present to a user at which times. If we can have an offer presented in our apps look and feel, that is timely and relevant to the user, we’ll look for opportunities to show the offers more often, and our players will get offers they’re more likely to accept. Seems like a win for everybody.