Platform Monetization: Dealing with High Adoption Barriers
Platforms face unique constraints that make them very sensitive to friction — this limits their monetization options to just 3 out of the 6 models used by other types of networks
Platforms share many characteristics with marketplaces. They create value by connecting demand with supply — specifically, they connect users with app developers. So it is natural to assume that platforms have the same monetization options available to them as marketplaces do. But in reality, platforms are far more constrained in the ways they can monetize.
Before going further, let me recap what I mean by the term “platform” — it refers to a combination of an underlying product, a software development framework, a way to “match” users with apps, and an economic benefit for developers. The last two elements overlap with the characteristics of marketplaces. The first two, on the other hand, account for the biggest differences between marketplaces and platforms.
First, the need for a software development framework creates a much higher barrier to supply adoption. Marketplaces typically acquire units of supply that already exist in some capacity, but have little to no access to demand. For example, Airbnb converted existing homes into short-term rentals — these homes already existed, they were just rarely, or never, rented out that way until Airbnb showed up. On the other hand, platforms need developers to create new units of supply — by either building new apps or creating extensions to existing apps. This means that developers need to invest in a platform before benefiting from it. In other words, developers face a financial hurdle to adopt a platform. This makes platforms much more sensitive to friction as compared to marketplaces.
Second, platforms also require an underlying product — this can be a hardware or software product that offers some value to end-users without the presence of developers. In fact, creating a platform is only viable when this underlying product has achieved scale. For example, Shopify was launched in 2004 as a tool to help retailers and other sellers create online stores. It only launched its app store and developer program in 2009, when the underlying product had a critical mass of users. Marketplaces, on the other hand, can certainly benefit from standalone SaaS products, but they are not a requirement in every case. In addition, marketplaces also have more flexibility in sequencing. While a standalone product can help build liquidity in the early days, it can also be introduced later to enhance stickiness.
These similarities and contrasts have a significant impact on platform monetization. Specifically, they reinforce some monetization models and invalidate others. Let’s take a deeper look at the dynamics that influence platform monetization.
Commissions (or Interaction Taxes)
Much like marketplaces, platforms that aim to help developers generate revenue have an obvious monetization option available to them — taxing each transaction with a commission (or interaction tax). Since a commission only helps the platform monetize at the completion of a transaction, it aligns the incentives of all players. The platform only generates revenue when it generates a sale for developers and customers have found something worth paying for.
This is usually the most effective monetization model for platforms until developers become too large and less reliant on the platform. Up until that point, developers are happy because the platform helps them reach new customers and generate revenue. But when a platform becomes just one of many ways for a developer to reach customers, charging a commission can create conflicts. This is also the reason why platforms that are heavily reliant on integrations with existing products (e.g. Slack’s integrations with Asana) cannot charge a commission.
iOS is the quintessential example of monetizing with a commission. Apple allows developers to build and distribute apps to its customer base — device owners — via the iOS app store. It then takes a 15-30% commission on purchases of all digital goods within those apps (incl. paid downloads and in-app purchases). Similarly, Shopify takes a 20% commission on all one-time purchases and recurring subscriptions (incl. upgrades) made through the Shopify app store. Other examples include Android/Google Play and Salesforce. Even Roku falls under this category as it keeps 20% of all subscriptions (and 30% of ad inventory) from all channels distributed through its channel store.
Advertising also works the same way on platforms as it does on marketplaces — the platform can charge developers to promote their products to users. This can be a high-margin revenue stream, but can also interfere with supply curation, i.e. helping users find the best app for their needs. As a result, this is best implemented after liquidity has stabilized and the platform has evolved past the “hyper-growth stage”.
For instance, Shopify launched its platform and app store in 2009, but it only launched app store ads in 2020. By this time, more than 87% of Shopify merchants were using apps leading to over $280M in developer revenue. Similarly, the iOS app store was launched in 2008, but app store search ads were only launched in 2016 — a year in which app store developers earned $20B in revenue from digital goods. Similarly, Google Play’s precursor, Android Market, was launched in 2008 but Google Play search ads only became available in 2015.
This is where things become tricky. As I have explained previously, a complementary product is a standalone offering that improves the platform’s value proposition for users. On marketplaces, complementary products are often SaaS tools to help build liquidity and monetize in the process. However, platforms already have an underlying product that pre-dates them. This underlying product is certainly enhanced by the presence of the platform. So the platform could be viewed as a complementary product of the underlying product, but not vice versa.
Rather, on platforms, complementary products as a form of monetization are restricted to in-house, standalone apps distributed to their users. In other words, this form of monetization puts platforms in competition with their own developers. This is not always a bad thing — platforms can use this approach to build liquidity on the supply side — e.g. Google Maps, Chrome, and YouTube in the early days of Android. But as platforms scale, conflicts inevitably emerge between larger developers and these complementary products. This creates risks related to disintermediation, multi-tenanting, and in some cases, anti-trust concerns. As a result, this is best used as a secondary or tertiary monetization model.
The Roku Channel is a great example of a complementary product. Roku launched its first product in 2008 — a set-top box that allowed viewers to watch on-demand streaming channels like Netflix on their TV screen. As adoption increased, it attracted more media companies (small and large) who wanted to reach Roku’s user base via its channel store. Then in 2017, Roku launched its own free, ad-supported streaming destination — the Roku Channel. This gave Roku more attention and ad inventory to monetize but also led to conflicts with partners like HBO and NBC. Other examples include Apple Music on iOS, which has led to conflicts with Spotify — a major developer on iOS.
Monetization Models Unavailable to Platforms
So far, I have listed three monetization options available to platforms — commissions, advertising, and complementary products. In contrast, other types of networks can use up to six monetization models. So let’s take a look at the constraints that prevent platforms from using the remaining three.
Paywalled marketplaces require at least one set of participants to pay before they can interact with other participants. If you think about it, every platform is in essence a paywalled marketplace already. Customers need to adopt (and often pay for) the underlying product first. For example, iOS users (consumers) need to buy an Apple device, Appexchange users (enterprises) need to subscribe to Salesforce, Shopify app store users (online retailers) need to subscribe to Shopify, etc. Therefore, it is unviable to ask them to pay again to access an app store. In addition, attempting that can limit the potential market for developers, making it more difficult to reach liquidity.
Charging developers for access to the platform’s customers is unviable as well. Since developers need to make a financial investment to create an app or integration, that added paywall can kill any hope of achieving liquidity. Some platforms do charge a nominal license fee, but this is more of a quality control mechanism than a monetization model.
Premium Network Tiers
A premium network tier limits interactions for at least one type of participant until they upgrade to a paid tier. This is also unviable for platforms for the same reasons as paywalls — limiting interaction opportunities restricts the potential market for developers. This would reduce the probability of a developer investing in the platform, making it harder to reach liquidity.
A derived product leverages interactions between participants to generate an asset that can be productized and monetized directly — usually in the form of a data or market intelligence product. Much like marketplaces, platforms cannot monetize this data directly as it is better used to improve platform quality.
To summarize, platforms are far more constrained in the ways they can monetize as compared to other types of networks. In addition, the monetization models in question are primarily applicable to platforms that unlock new capabilities (Type B platforms, e.g. iOS, Shopify) as opposed to those that merely integrate with existing products (Type A platforms, e.g. Slack, Zoom). However, they can also be used by “borderline” platforms that fall between these extremes, including Atlassian, Xero, and Roku.
Other types of networks — specifically, interaction networks, marketplaces, and data networks — can always overcome their monetization constraints by layering on new types of network effects. Platforms, however, sit on top of other products (e.g. Shopify) or networks (e.g. Slack) which makes it difficult to layer additional network effects on top. Instead, platforms are best viewed as the final layer to add on top of your network effects stack, after the monetization roadmap has been clearly defined.