Monetization: the next frontier of SaaS / S+S architecture

Over the week end, I was looking at AMZN DevPay announcement and I started thinking in more general terms about the architectural impact of different monetization schemes. At a high level, software / service monetization can be put into 4 main categories:

• perpetual license (e.g. one time charge of $85 and you get unlimited access to the software)
• subscription (e.g. $20 per user per month)
• usage based also known as transaction based (e.g. $0.05 per text/SMS sent)
• and ad-funded (the service is free for the user and is paid for by someone interested in getting your attention while you are using the service/software)

Each scheme has an implication on the overall architecture of the service, and even further, some scheme cannot be used unless some architectural elements are part of the solution. Let me explain this in taking these 4 schemes one by one.

 

Perpetual license

Selling software through a perpetual license is a very attractive in many ways (for the seller);  the money is received up front, reducing the impact of churn (even the user stops using the service, it was paid for already) and it is good for the treasury. From the buyer perspective it is often less attractive as by paying up front, most of the risk is on the buyer side.

From an architecture perspective, perpetual license can mostly be performed "out of band"; meaning that the software itself does not need to know, who is using it, how much it's been used... in other words, there is no real need to meter the usage. A perpetual license gives "all you can eat" access, forever. In other words, in a perpetual license scheme, the architecture does not need to be 'monetization-aware' (a part from any anti-piracy aspects)

But, as we all know, forever is quite a long time :) which means that if you are hosting the service on behalf of your customers (saas model) you are incurring an hypothetical infinite hosting cost with this model. This is not the case in the more traditional "on premise" model where the software is deployed on customer data centers and/or desktops. Architecturally then, you are better off not having to host what you sell on a perpetual basis. Unless of course, (a) you believe the up front charge can cover all the hosting cost (unlikely) (b) you know that the service will be time bound and therefore your perpetual license is not that perpetual after all (c) you can attach some additional monetization schemes after the perpetual license is sold (e.g. maintenance fee).

Summary: Good for the treasury, no need to do much from an architecture perspective to support this model, but watch out for hosting cost if you are in a saas model.

 

Subscription

The "per user, per month" scheme is, at least currently, the most popular option in the saas space. Akin to the perpetual license, it can be supported from an architecture perspective mostly "out of band". Meaning that here again, the billing/invoicing can be mostly separated from the application itself. A business contract can be established for say 50 users "out of band" of the application itself, and a monthly bill of 50 x cost per month is sent to the buyer.

The most important aspect that your architecture needs to do to support this monetization scheme is to verify that the user is 'current' on his monthly payment (as the license is to perpetual). In a hosted model, this can be done without having the application itself being aware of whether the caller is 'current' or not. The hosting infrastructure could check that 'out of band' by looking up into the payment database and restrict access to the application endpoint(s) (e.g. taking down the web site, modifying DNS entries, place site in read only...) for all customers not paying their bills.

From an architecture perspective, one could think of subscriptions as renewable time-bound perpetual licenses. This said, there are multiple areas where a provider could benefit from a tighter linkage between the order system and the application. Automatic/self provisioning comes to mind. But as mentioned, not strictly required by the monetization model.

This model also removes the problem of having to host 'forever' the customer; as it is a renewable monthly contract that is in place. Every month a new injection of cash is received from the buyer.

The issue for the seller here are more around customer acquisition costs and churn. Since there is no up front payment in this scheme, it usually takes multiple billing cycles (i.e. multiple months) for recovering the customer acquisition costs. So. if churn is high, customers might not stick around long enough to recover the acquisition costs. Although customer acquisition costs are mainly marketing related (awareness campaigns, introductory prices, free trials, referral fees...) good architecture as always can help :).

A typical example is to architect for self service and automation. An architecture that reduces any type of human intervention, reduces the operating cost. So, if you are giving away free trials, you'd better off if these free trials do not require (expensive) humans having to touch the system, run scripts, provision resources etc.

Another example is to architect for high density, i.e. trying to 'pack' as many free trial customers as possible in a single unit of infrastructure. Multi-tenancy here can come handy as well as virtualization technologies.  

Summary: subscription base monetization is architecturally similar to the perpetual license in the sense that it can mostly be done "out of band", customer acquisition costs and churn are the elements to watch out for, architecting for self service, automation and high density can greatly help.

 

Usage based a.k.a. transaction based

In a usage based model, you cannot rely on a "out of band" model for monetization anymore; the architecture has to be able to meter the actual consumption of the service. This consumption can be captured either by the application business logic itself or by the hosting environment. It is often the case that if the monetization at the resource level (bandwidth, CPU, storage...) the hosting environment meters it; if the monetization is at the business transaction level ('check credit score', 'apply for open position') the business logic meters it.

In addition to metering that is now mandatory, another architectural aspects related to usage-based is the potential need of 'non repudiation of usage' systems. Trust between the service provider and service consumer is often enough to cover this, but in case of litigation or limited trust, there should be a way of getting to 'the truth'. There are multiple ways to handle this, one being using a 3rd party 'mutually trusted' auditor, another one is to emit billing events to the service consumers as they happen so they can capture them in their systems and correlate at each billing cycles whether the numbers match. It is a little bit like taking your own meter in a taxi and at the end of the trip comparing the taxi meter with yours (not sure what happens when there is a discrepancy).

There are other elements, but one can quickly see that implementing a usage/transaction based system is heavier on the architectural side than the "out of band" monetization schemes possible with the previous models.

On the plus side, usage based pricing is very low risk from the buyer perspective as the buyer only pays for what is actually used. The lower risk of usage means that service provider might be able to attract more companies to use their service(s). Zero cost of usage when the service is not used is a quite appealing proposition (compare that to your gym membership that you keep paying monthly although you never go there:). Free trials in the subscription model are of course low risk, but in the free trial model, the service provider incur an actual cost (part of the customer acquisition cost).

A good analogy here is the “pay as you go phones" vs. "phones with monthly plans”. My understanding is that pay as you go phones are marginally profitable and the strategy (hope?!) is to convert "pay as you go" customers into more long term profitable "with a plan" customers. Alternatively, once a consumers start using the service (and hopefully like it) the usage could go up and a “all you can eat” user/month model or hybrid model (N transaction included in your plan + $x per transaction after that) can be offered.

In other words, enabling an usage based monetization could be a good way to de-risk the trial of service without incurring potentially large customer acquisition costs while retaining an up sell opportunities once consumers increase their usage of the service. 

Summary: this model has explicit architectural requirements: metering for sure, non repudiation... it can be a good way to offer a low risk access to buyers without exposing itself to the customer acquisition cost / churn problem.

 

ad-funded

The premise of this model is simple, consumers access software or a service for free and someone interested in their attention sponsors it. This model has been recently talked about as the 'ultimate disruption'; I am not 100% about that, so for now I'll stick to the architectural impact.

Most of the ad funded software I see, is monetized "around" the application. That is to say, the application or service has the central area of the screen and banners, links, sponsorships are placed around the application (think of search as a perfect example of that). In more complex application, there is a clear opportunity to modify the architecture of ad-funded software to allow 'in application' ad placement (as opposed to around); one can think of this as similar to 'in game' ad placement we are seeing in the latest console games.

Another aspect is that these 'around' ads are selected based on various level of assumptions about the user. The better the assumptions, the better the selection; the better the selection (a.k.a targeting), the more likely it is that the ad placement is effective (of course, other elements such as size and richness of inventory plays a role but let's leave these aside for the moment). A second opportunity for ad-funded software architecture is therefore to better capture the 'user context' that could lead to better capturing 'intent' that could lead to (more) accurate targeting.

At this stage I do not know, what sort of APIs should be exposed by ad-funded software to allow 'in application' ad placement and even less about how 'intent' can be better captured, but be reassured that these are topics that are being investigated.

Summary: ad-funded software has proved to worked in certain areas of the software industry, we are still in the infancy of how to architect for ad-funded optimization.

 

As we have seen (albeit only superficially), monetization has many impacts on software architecture, some are known (e.g. metering) others are new (e.g. 'in application' ad placement). There is a clear need in better understanding these models and extract best practices in all of these. So, expect more in depth entries from myself and members of my team on this topic soon.

As always, comment/feedback welcome.