Two misconceptions about paid user acquisition

The data-driven nature of the freemium model changes the way certain functional groups interact with each other during the product design and development process. Because analytics is a revenue driver and not a cost center in freemium, it isn’t implemented after a product launch as a means to reduce losses. Rather, the initialization of analytics should coincide with the launch of the MVP and run in parallel with product iterations as a means of optimizing the user experience and increasing revenue.

This paradigm shift could be (understandably) seen as an intrusion into the creative process of designing software by measurement and analysis. And if this truly is the case, then software design is in good company: the same can be said about picking players for baseball teams and predicting the outcomes of presidential elections.

But enmity for the freemium design process – which some see as supplanting the role of creativity in software development – is misplaced when applied to paid user acquisition. Paid user acquisition has nothing to do with the creative vs. wholly data-driven design debate; paid user acquisition occurs outside of freemium and should always be dictated by economic parameters in pursuit of an optimal revenue outcome. In any given situation, paid user acquisition either makes sense (i.e. will be profitable) or it doesn’t. There is no nuance.

That said, below I offer rebuttals to two of the most common misconceptions about paid user acquisition in freemium.

Misconception 1: Great products don’t require paid user acquisition because they’re viral by nature.

I’ve heard this shibboleth from producers on a number of occasions, and there exists a large enough number of hit mobile products that succeeded without engaging in paid user acquisition to support the point. But highly viral products still require an initial seed of users to achieve virality with – and the larger that initial seed is, the faster and more widespread the viral effects will propagate.

Every virality model is predicated on the same basic set of inputs: number of invites and average conversion rate of an invitation. The total number of virally-acquired users increases with the number of invites sent out; the number of invites sent out increases with user base size. If a product is truly viral – that is, its k-factor is greater than 1 – the virality compounds user base growth by facilitating higher N-order viral conversions. The diagram below illustrates this point.

Thus, truly viral products are the best candidates for paid user acquisition: not only does virality serve as a supplement to an acquisition budget (as it reduces the effective cost per acquisition of a user), but it increases the size of the viral invitation pool and creates a compounding dynamic. When the cost per acquisition of a user is less than that user’s expected lifetime value (ignoring carrying costs), buying users when a product is viral speeds up user base growth and delivers revenue. When the LCV / CPA spread is positive, virality doesn’t negate the revenue benefit of paid user acquisition or somehow render it unnecessary, it amplifies its positive impact on revenues.

Misconception 2: The money spent on paid user acquisition would always be put to better use funding additional product development.

A less absolute version of the above statement wouldn’t be contestable. But as written, this belief contrasts with the core tenet of agile software development (and especially freemium software development): that resources should always be allocated to the initiative of highest return. In some cases, that could be further product development. But to say that product development is always the most economic recipient of resources is to ignore that these decisions should be justified by quantifiable support and not simply a bias for product development.

And by what objective criterion should that decision be made? Revenue.

Measuring the revenue effects of product development versus paid acquisition (given an equivalent budget for both) requires two things. The first is a quantitative framework for predicting revenue from a freemium product.  And the second is a reasonable assessment of how the marketplace for a given product will evolve over the proposed development timeline.

[pardot-dynamic-content id=”266″ default=”%3Cdiv+style%3D%22background%3A%23fff%3Bpadding%3A20px%3Bborder%3Asolid+1px+%23ddd%3Bmargin-top%3A10px%3Bmargin-bottom%3A10px%3B%22%3E%0A%3Ch2%3ETrack+aquisition+with+GameAnalytics%3C%2Fh2%3E%0A%0A%3Cp%3EUse+GameAnalytics+to+assess+player+acquisition+cost+and+fine-tune+your+investment+strategy.%26nbsp%3BThere+are+no+trial+periods+or+hidden+fees.%26nbsp%3B%3C%2Fp%3E%0A%0A%3Cdiv+class%3D%22orange-button%22+style%3D%22text-align%3Aleft%3B%22%3E%3Ca+href%3D%22http%3A%2F%2Fbit.ly%2F1bOhH8D%22%3E%3Cb%3ESign+up+for+FREE%21%3C%2Fb%3E+%3C%2Fa%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E”]

A quantitative framework for revenue prediction is something most businesses put together before undertaking any projects and therefore shouldn’t be onerous to acquire. Without some framework, ROI estimates can’t be made, and thus financing projects is impossible (or is done haphazardly).

An understanding of the evolution of the marketplace in the coming weeks (or months, in some cases) is harder to come by and represents a significant risk. What if a competitor releases a new product in that time? What if cost of user acquisition rises precipitously?

While these factors are not unique to either the decision at hand or to freemium developers, they’re made more acute when deciding upon revenues now versus in the future based on incomplete information. Most developers have a reasonably concrete grasp on their product’s current metrics – they can compile a sensibly accurate lifetime customer value for users that would be acquired through paid acquisition today. But doing the same is impossible for users acquired organically (which is the assumption) in two weeks’ time.

So the decision to pursue product development over paid acquisition represents an admission that the organization believes it can extract more revenues from an improved product at some point in the future than it can from the current product, given the equal cost of product development and user acquisition and our understanding of the evolution of our product’s marketplace over the course of product development.

Put another way: user acquisition now represents a bird in the hand, product development to be launched at some future date is two in the bush, and determining which is more valuable requires an evaluation process. Product development may win out in some cases, or even in most, but to say it’s always the most ROI-effective course of action is to ignore the necessity of sober, objective analysis in project finance decision-making.