Yield management is a pertinent topic within the context of freemium mobile app distribution, monetization, and user acquisition, as it corresponds closely with the fundamental components of freemium success:
- demand management;
- scale;
- insight;
- and monetization.
Sheryl Kines, one of the most prominent academics conducting research in the field of yield management defines the concept as such:
Yield management is the application of information systems and pricing strategies to allocate the right capacity to the right customer at the right place at the right time.
In her seminal paper on the topic, The basics of yield management, Kines identified six defining characteristics of an industry which might benefit from the application of yield management:
- The existence of clear market segments, each of which possesses a different sensitivity to price.
- Fixed capacity at the firm level, with the addition of capacity in the short term either infeasible or economically untenable.
- A component of time sensitivity in the delivery of the product or service, past which the opportunity for a sale is lost.
- Low marginal unit costs of production and distribution.
- Price flexibility.
- Observable and measurable yet not wholly predictable demand volatility.
The freemium business model, at least in digital products and services, satisfies all conditions except number 2; the developers of digital freemium products are not restricted in their ability to scale capacity (eg. sell another app on a platform app store) in the short term.
When this set of conditions is examined from the perspective of a freemium mobile app developer, a few obvious idiosyncratic characteristics of the freemium mobile app ecosystem beg consideration:
Distinct market segments: Freemium mobile apps certainly exhibit a stratified spectrum of user segments, mostly demarcated by monetization behavior: non-paying users (NPUs), minnows, dolphins, whales, etc. This behavior is captured on a per-user level by the LTV metric.
Fixed short-term capacity: An instance of a freemium mobile app — in other words, a session — is momentary but, for most products, not fixed (ie. a user will only play a game for a limited amount of time, but knowing that amount of time with certainty ex ante isn’t possible).
Low marginal production and distribution costs: The marginal cost of both serving an instance of a freemium app and of delivering a download of a freemium app is effectively $0.
Price flexibility: The potential for price flexibility in freemium exists — that is, exposing different sets of prices to different price points — but is not widely utilized. The concept can be abstracted as the ability of the user to monetize to whatever degree they want across a continuous monetization curve. If this can be considered a form of price flexibility, or different groups of users monetizing to different extents, then freemium mobile apps certainly meet this condition.
Demand volatility: Demand in freemium mobile apps is not typically volatile when the monetization mechanic is strictly defined as in-app purchases; in fact, for most freemium products, demand is fairly stable and predictable. But when freemium mobile apps monetize through in-product ads, the definition of demand evolves into a two-stream, competing system: advertisers exert demand upon the user base, and users exert demand upon the app’s internal economy. Advertising demand is volatile and highly susceptible to price spikes. In the case of an app that both sells IAPs and monetizes through display advertising, this condition is satisfied.
Given that a freemium mobile app, at a conceptual level, meets the conditions for which yield optimization can increase revenue, the goal of implementing a yield management model into a freemium mobile app should be defined. In this case, for the sake of simplicity, revenue will be considered as being generated exclusively from ads and in-app purchases, with ads taking the form of install ads from user acquisition networks (and not rotating display ads).
Model definitions
For the purposes of this model — and, again, for the sake of simplicity — ads and future in-app purchases will be thought of as mutually exclusive. That is, when a user clicks on an install ad for another product, that user churns from the source app forever and will never again make an in-app purchase.
Each instance (session) of an app represents a unit of what can be considered inventory; that is, a time-limited (although the amount of time cannot be predicted with total accuracy) occasion on which the user is capable of generating one or the other forms of revenue (or none). The chronology of this instance — first session, second, third, etc. — is not important for the purposes of the model.
The value of future in-app purchases is the estimated value of all revenue generated, directly and indirectly, from this user, from the start of this instance projected through the point at which the user churns. The value of past purchases is irrelevant at the start of the instance, except to inform the revenue estimation algorithm.
Any user-level revenue projection – especially indirect projections, eg. revenue attributed to this user as a result of virality — is susceptible to error; the revenue estimate, therefore, should be adjusted by some error margin. The model assumes the value of future revenue contributions for the user is calculated and discounted for error at the start of the instance.
The value of the ad is whatever a user acquisition network will pay for this user’s click on a real-time bidding exchange.
The real-time bidding exchange
A user acquisition exchange operating under real-time bidding conditions — such as Flurry’s Marketplace — is designed to facilitate the near-instantaneous sale of advertising inventory as a component of a six-party model. The parties are as follows:
1) User – the person over whom the model makes revenue determinations. The instance begins when the user opens the app.
2) Application – the application being used.
3) Server-side Platform (SSP) – a server-side platform is a technology platform that aids app developers primarily in pricing strategy, inventory management, and channel evaluation through data integration and analytics tools. The Rubicon Project and AdMeld are examples of two large SSPs.
4) Ad Exchange – An ad exchange is a technology platform that matches advertising inventory to advertisers in real time.
5) Demand-side Platform (DSP) – A demand-side platform is a technology platform that aims to integrate multiple sources of advertising inventory (ad exchanges) with various data sources and analytics mechanics to optimize campaign management and targeting. Trademob, MDotM, and Gradient X are three examples of large DSPs.
6) Advertiser – the entity attempting to purchase advertising inventory for the purposes of acquiring a user.
The process of serving an ad begins when a user starts an instance of the app. The app gathers various demographic data points about the user and submits these, along with the specifics of the ad placement (size, content restrictions, etc.) and a minimum bid amount to a Supply-Side Platform. The SSP makes various determinations about the particular piece of inventory and submits this inventory listing to the ad exchange.
The ad exchange makes this information available in an open marketplace from which various Demand-Side Platforms evaluate the quality and appropriateness of the piece of inventory for their clients, advertisers. The DSP collects blind bids as well as ad content from its advertisers for the piece of inventory and submits those to the exchange. The exchange picks the highest bid, submits the content to the SSP (which passes it along to the app), and handles the bookkeeping process on the back-end.
Conceptualizing the yield management model
The yield management model exerts agency at the beginning of the ad transaction process, when the user instantiates the app. The model must determine at each instance, based on the user’s estimated future revenue and the expected value of the ad impression, whether or not to attempt to sell a user to an acquisition network.
Balseiro et al proposed a decision model within the context of display advertising for determining when to fill an impression from a fixed, forward-contract basis with an advertiser and when to fill an impression from AdX:
This model informs the mobile advertising yield management model but is not entirely comparable, as two fundamental differences exist between the two sets of circumstances.
The first is that display advertising and product feature-related streams of revenue are not mutually exclusive; that is, display ads are presented alongside the product and don’t necessarily preclude future use. In the mobile ad yield management model, however, that a user clicks on a user acquisition ad placement is considered to preclude all future reveues from in-game purchases (even though, in reality, this is not always the case).
And the second difference is that user acquisition advertising is not generally undertaken on a forward-contract basis (that is, an advertiser secures a fixed amount of impressions for a pre-determined price), as it is in display advertising.
While this type of contract may be employed by some app developers, especially in “traffic trades” (where one app sends another a fixed amount of users and has the same amount returned in kind at a later date), the majority of paid user acquisition takes place on a CPI or CPM basis; traffic trade transactions are not accommodated for in the model.
The model thus emerges as a set of decision points, beginning at (1) when the user instantiates the app:
The locations in the process at which yield management mechanics may constitute a viable revenue optimization strategy are decision point 1 and action points d and f.
At decision point 1, the app is making a determination about the monetary value of the user’s future revenue contributions. These revenue contributions may not be direct, as NPUs have monetary value: a user exhibiting high virality cannot be evaluated solely through their expected in-app purchases. Thus the yield management mechanic must capably attach a value to both the user’s direct and indirect revenue contributions in order for the process to capture the true estimated value of the user.
Action points d and f relate to the quality of both the impression and the ad submitted through bid. Low-quality ads (poor ad copy, unappealing imagery, etc.) or highly niche or inappropriate products being advertised (poor demographic fit) reduce the likelihood of an ad being clicked.
The minimum bid requirement sent by the product to the ad exchange must account for some probability of the ad being clicked, as that probability affects the expected value of the ad revenue. At action points d and f, the app has miscalculated that probability; at d, by overestimating the appeal of the impression, and at f, by overestimating the appeal of the ad.
Yield management in the mobile advertising space is a nascent concern but one that will likely grow prominent in the near- and medium-term future as freemium apps reach ever larger audiences. The opportunity for yield management services to optimize total app revenues is a large one, but it presents unique, sophisticated challenges in data management and analytics that are probably beyond the scope of most developers.
Given the resource and expertise requirements in developing a yield management tool to quickly and reliably make the decisions identified in the model at scale, it seems unlikely that many developers will even attempt to implement such a framework into their revenue strategies. Instead, this market segment will likely be captured by well-funded SSPs with legacy experience in display advertising operating Yield-management-as-a-Service platforms.
Photo by chuttersnap on Unsplash
Recent