20bits: Almost Viral: A Hybrid Acquisition Strategy
John Furrier
· 8 months ago
Love this post...This is "social media porn"
Jesse Farmer
· 8 months ago
Glad you liked it!
I guess that makes me a social media pornographer?
Jens Fiederer
· 8 months ago
Oddly, the last formula displays fine on Firefox when I load your page directly, but gives "This formula does not parse" when read through GoogleReader.
Jesse Farmer
· 8 months ago
I originally published a version with a bad formula, so Google Reader probably cached that one.
jeremy liew
· 8 months ago
Your math is right, and it is definitely helpful to increase k to reduce your effective CAC due to pass along growth. Higher is better, but I don't think that it makes sense to deliberately "aim" to get k to be below 1.
If you can get k>1 you can always rate limit the speed at which you send notifications/invitations/whatever is your transport if you're crashing your servers. It's a lot harder to ratchet up k than ratchet it down.
Also, for almost all apps, there is an effectively infinite amount of advertising inventory to help you acquire customers if you can hit the market clearing rate of CPI. That very much depends on your ARPU.
As a result, you're better off focusing on lifting ARPU (or reducing churn) to increase LTV, and hence make sure that you can clear the market price for CPI
Jesse Farmer
· 8 months ago
Jeremy,
Thanks for taking the time to read my article and double-check my math! I really appreciate your insight.
Your response gave me a few thoughts.
First, fair point about market clearing price and CPI. How likely is it that you can hit that rate profitably, though? The top casual MMOGs are making like a $2 ARPU, right?
Second, throttling messages isn't always possible. On Facebook, for example, user-to-user notifications, requests, and news feed items have to be sent as soon as the sender issues them. I'm thinking of the iLike story where they drove around SF picking up servers from everyone and their uncle.
Still, you're right that this is probably the better solution for most people if they're just trying to keep the servers from starting on fire.
Third, viral growth leads can lead to demographic problems, too, which throttling doesn't address. By definition a viral process selects the users who are best at propagating, not necessarily best at monetizing. Controlling demographics with viral growth is much harder than controlling demographics with paid acquisition.
In any case it's something that needs to be understood, modeled, and tested.
Even if you don't agree that intentionally being "almost viral" is a good way to grow — and I'm really just presenting it as a distinct strategy with its own set of tradeoffs — I think it's important to understand the tradeoff and how the viral coefficient interacts
I couldn't find the formula I derived here anywhere else, so hopefully it helps someone!
Peter_Jan
· 1 month ago
You are making a good point but the risks of k>1 only aply if: - viral growth risks spreading to demographics with ARPU < cost - if viral growth exceeds the scalability of key processes
The second issue limits the number of users you can serve, so that ARPU>cost is not good enough but you also need to worry about getting ARPUnew user > ARPUn-th user, with n being the number of users you can serve (with ARPUs ranked from high to low).
Do you agree that these are the conditions for your analysis to apply?
Tyler Mayoras
· 2 weeks ago
Awesome article Jesse. I think I like the Hybrid approach better than true Viral. Thanks.
All Comments
I guess that makes me a social media pornographer?
If you can get k>1 you can always rate limit the speed at which you send notifications/invitations/whatever is your transport if you're crashing your servers. It's a lot harder to ratchet up k than ratchet it down.
Also, for almost all apps, there is an effectively infinite amount of advertising inventory to help you acquire customers if you can hit the market clearing rate of CPI. That very much depends on your ARPU.
As a result, you're better off focusing on lifting ARPU (or reducing churn) to increase LTV, and hence make sure that you can clear the market price for CPI
Thanks for taking the time to read my article and double-check my math! I really appreciate your insight.
Your response gave me a few thoughts.
First, fair point about market clearing price and CPI. How likely is it that you can hit that rate profitably, though? The top casual MMOGs are making like a $2 ARPU, right?
Second, throttling messages isn't always possible. On Facebook, for example, user-to-user notifications, requests, and news feed items have to be sent as soon as the sender issues them. I'm thinking of the iLike story where they drove around SF picking up servers from everyone and their uncle.
Still, you're right that this is probably the better solution for most people if they're just trying to keep the servers from starting on fire.
Third, viral growth leads can lead to demographic problems, too, which throttling doesn't address. By definition a viral process selects the users who are best at propagating, not necessarily best at monetizing. Controlling demographics with viral growth is much harder than controlling demographics with paid acquisition.
In any case it's something that needs to be understood, modeled, and tested.
Even if you don't agree that intentionally being "almost viral" is a good way to grow — and I'm really just presenting it as a distinct strategy with its own set of tradeoffs — I think it's important to understand the tradeoff and how the viral coefficient interacts
I couldn't find the formula I derived here anywhere else, so hopefully it helps someone!
- viral growth risks spreading to demographics with ARPU < cost
- if viral growth exceeds the scalability of key processes
The second issue limits the number of users you can serve, so that ARPU>cost is not good enough but you also need to worry about getting ARPUnew user > ARPUn-th user, with n being the number of users you can serve (with ARPUs ranked from high to low).
Do you agree that these are the conditions for your analysis to apply?