New monetization option for app developers launches
Today, my friend Noah Kagan launched a new payments service called Gambit which you can check out here. The focus is on virtual currency-based Facebook/OpenSocial applications, and supports credit cards, mobile payments, and offers-based monetization. He also has a blog and twitter account.
Given the proliferation of these services, I wanted to spend a couple minutes talking through the new monetization funnel for apps and some of the metrics that are being thrown around.
Spreadsheet model
First off, I wanted to quickly share a very simple spreadsheet model which you can download here.
Funnel steps
At a high level, the key issues to track for an offers-driven monetization looks something like this:
- total installs / registered users
- monthly active uniques
- daily active uniques
- daily paypage uniques – how many users go page where you can pay or fill out offers?
- daily lead clickthroughs
- daily net lead completions (lead completions – chargebacks)
- daily revenue
- monthly revenue
From top to bottom, you can see that the focus is around uniques, and how many of them translate to completed offers and ultimately revenue. Of course, many of these transactions will actually end up as direct payment via credit card or mobile, and that is trivial to add to this model – I won’t cover those just for simplicity.
One quick note on leadgen though, for those who are unfamiliar – essentially, leads are opt-in forms that users can fill out in order to generate virtual currency. This might be subscribing to a Netflix offer, for example, or giving out a real address to get a direct mailing from a university. More about the leadgen industry here. As a result of this construct, users may not have to use credit cards in get money to the publisher, which can be great.
As a result of this offer-based monetization, it becomes important to track not only how many people click through to begin filling out a lead, but also how many folks complete leads, and ultimately how much revenue each lead is worth. Different demographics, geographical areas, and lead types generate different kinds of revenue. There’s also chargebacks that happen when the leads are rejected for being complete or incorrect.
Example numbers
If you plug this into a monetization table, then you can see the flow.
Here are some example numbers derived from games that Noah’s company Kickflip had previously developed and operated – he was comfortable sharing the data that came out of his own apps. The numbers below would represent a large and successful app with millions of actives per month:
total installs | 15,000,000 |
monthly active uniques | 3,000,000 |
daily active uniques | 450,000 |
daily paypage uniques | 45,000 |
daily lead clickthroughs | 13,500 |
daily net lead completions | 1,890 |
daily revenue | $5,670.00 |
monthly revenue | $172,935.00 |
and of course these numbers are driven by all the percentages of how much dropoff there is at each step. For quick reference, the percentages are listed below and drive the numbers in the table above.
% of monthly actives | 20.00% |
% daily active users of MAU | 15.00% |
% of DAUs that visit payments | 10.00% |
% that clickthrough to leads | 30.00% |
% that complete leads | 15.00% |
revenue per lead | $3.00 |
% chargeback | 1.00% |
Now that we have these metrics, we can start to calculate to other metrics.
Let’s define a new term, “ACPM” which stands for “App CPM”
As someone from the online ad industry, I was saddened to hear that the term “CPM” had been co-opted by these app monetization companies to mean something entirely different and weird.
In the app monetization world, this is the definition:
App CPM = (daily revenue / daily uniques to the paypage) * 1000
Recall that this is very different than the standard definition:
Online ad CPM = (daily revenue / daily ad impressions) * 1000
They are certainly not apples-to-apples, even though they are represented in some literature as such. And unfortunately, now that some of the market leaders are using these misguided terms, everyone is following suit. Yuck!
So as you can see, the “app CPM” (which I’ll refer as ACPM) is defined by uniques to the payments/offer page, rather than by pageviews or impressions. Using the above numbers, we’d get:
ACPM = ($5,670 / 45,000) * 1000 = $126
I’ve been told by multiple people that numbers from $50-$200 are all possible here.
Measuring ARPU
You’ll notice that the ACPM has no relation to the overall usage of the product – in fact, you might have $300-$400 app ACPMs but still have low revenue, since the ACPM is only defined once the users hit the payments page. Maybe you have a small number of users who do so, or maybe you only have a small % of users who are active at any given time.
To measure how the numbers fit together from top to bottom, instead we’ll have to calculate the ARPU:
ARPU = revenue / total actives
This means that this would include any and all actives, regardless of whether or not they visited the payments page. For the numbers above, they’d translate to:
Monthly ARPU = $172,935 / 3,000,000 = $0.058
On Facebook, I’ve been told from multiple sources that numbers from $0.01 to $0.25 are all reasonable, and that off of the social platforms you’ll find more niche destinations that generate closer to $1 ARPU.
Conclusion
Ultimately, it’s very exciting that multiple monetization platforms are getting created in the industry, and that competition will be great for everyone. Gambit is certainly one of many new creative companies that will come out with great stuff.
At the same time, it’ll be up to publishers to figure out how to squeeze as much monetization they can from their properties, but without compromising the user experience. By looking at the numbers above, it’s clear how you can increase both ARPU and ACPM in very systematic ways, but it’s potentially at the cost of retention or engagement within the product.
Ideas or questions? Leave me a comment.
Want more?
If you liked this post, please subscribe or follow me on Twitter.
UPDATE: thanks to Jared Fliesler for correcting a silly mistake in my arithmetic ;-)