In this post we start out with a brief discussion of a simple taxonomy of service delivery models for Internet-based applications and then go on to discuss different business models that can be used to support these services. Finally, we put these together to discuss how the different kinds of Internet services may be monetized. The goal is to present several examples to drive the points home and make the discussion useful in a practical, real-world, setting.
Classes of Services
Services may be classified in different ways using different criteria. Here, we explore a couple of simple ones, and use these as a basis for building ideas that follow.
By Underlying Protocol or "Connectedness"
Different services have different characteristics and rely on different protocols. Looking at things from a protocol perspective... Some use best-effort routing underneath, with the UDP protocol where the loss of a small number of packets does not significantly degrade the user experience. Others utilize a protocol (TCP) that layers timers, packet sequencing, and a re-transmit mechanism on top of the underlying pipes, to ensure higher quality of the user experience, albeit with greater overheads. ... and new protocols are constantly in the works, crafted over time by hard-working engineers at the IETF and the IRTF.
"Sessions"?
From a more pedestrian standpoint, we may classify services in simpler ways - those that require a "session" vs. those that do not. For instance, voice and video calls require a session over which to transmit and receive data, while a simple web download does not (though strictly speaking, this latter service is provided over a TCP "connection" which we distinguish from the notion of session in this case). However, websites may utilize other mechanisms like cookies, web bugs etc to track different interactions between a user and a website, and construct a session context from these.
Modes of Interaction
Some services follow the "client server" paradigm. A user, sitting at a client machine, makes a request that his browser connects to a server on the Internet to fulfil, downloading data onto the user's screen in the process.
Sometimes, the user (and his client) may be in a sheltered network like his company's intranet, at work, and the server may be in a different company network so there are intermediate "intelligent" nodes the user's request, and the server response must transit between the two endpoints.
Other services, such as the file-sharing ones hosted by Torrents, are "peer-to-peer" services where computers are treated somewhat more democratically as equals, and these "equal" nodes are able to connect and communicate once they find each other using a network provided "directory".
Yet other services follow the "interception" or "intermediation" paradigm. In these cases, the server providing the service interjects service related information into the communication stream. This can be done effectively at the boundary between two domains at a server that all packets must transit, assuming the communication between end-points is not encrypted (if it is, there is no obvious way for interception-style services to work in those settings).
This taxonomy will be useful as we examine how we might offer, and bill for, Internet services.
How to generate revenue?
Lord Kelvin is reported to have said "[...] you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind [...]".
To bill someone for something, unless you intend to collect a flat fee for unlimited access on a per-time-period basis, you need to be able to measure use. But how does one go about doing this? This is where event logging, accounting, and security controls come into play. Let us now briefly look at these three ideas.
Event logging refers to the process by which we gather statistics for various pre-defined network occurrences or events. You may want to collect information for a wider variety of events than the set you need to bill for the service because billing models may change over time, and you never know what information you might need to validate your current billing model, or perhaps even design a new one. Having more data at hand is usually (though not always) better than having less. Of course, collecting more data puts more of a burden on the service and might impact performance adversely. So there is a trade-off here (so typical in engineering).
Accounting or billing (not strictly synonymous, though we use them inter-changeably here) is the process that tells you what to do with the data you have so painstakingly collected. Collating the data together, and generating bills falls into this bucket.
Does anyone remember Second Life from Linden Labs? They even used to have their own currency (called Linden Dollars) in the Virtual World. Somehow, Second Life went from all the rage a few years ago to a somewhat more quiet existence now. Guess there is a cycle to everything - turn, turn, turn.
We note some different ways in which mobile applications are monetizing value today. The first two models are obvious ones - 1. through advertising leveraging platforms like AdMob, and 2. by selling downloads at say $0.99 each. Lately though, more and more apps are selling "usage rights" - you can play the game so many times, or read so many documents with our software each time you pay a $0.99 fee. And perhaps periodically free usage "turns" can be made available through special promotions or at first download, to gain in popularity and drum up interest.
This is similar to the "revenue sharing" model telecom equipment vendor firms sometimes use: give away the platform (hardware) for free, then have the service provider pay you a certain percentage for each transaction they bill the subscriber for. This is also similar to how Apple bills application developers. You pay a fee to sell your app via the iTunes platform, then get a percentage of the total money you make from downloads.
[This is a place-holder for a work in progress.]
Classes of Services
Services may be classified in different ways using different criteria. Here, we explore a couple of simple ones, and use these as a basis for building ideas that follow.
By Underlying Protocol or "Connectedness"
Different services have different characteristics and rely on different protocols. Looking at things from a protocol perspective... Some use best-effort routing underneath, with the UDP protocol where the loss of a small number of packets does not significantly degrade the user experience. Others utilize a protocol (TCP) that layers timers, packet sequencing, and a re-transmit mechanism on top of the underlying pipes, to ensure higher quality of the user experience, albeit with greater overheads. ... and new protocols are constantly in the works, crafted over time by hard-working engineers at the IETF and the IRTF.
"Sessions"?
From a more pedestrian standpoint, we may classify services in simpler ways - those that require a "session" vs. those that do not. For instance, voice and video calls require a session over which to transmit and receive data, while a simple web download does not (though strictly speaking, this latter service is provided over a TCP "connection" which we distinguish from the notion of session in this case). However, websites may utilize other mechanisms like cookies, web bugs etc to track different interactions between a user and a website, and construct a session context from these.
Modes of Interaction
Some services follow the "client server" paradigm. A user, sitting at a client machine, makes a request that his browser connects to a server on the Internet to fulfil, downloading data onto the user's screen in the process.
Sometimes, the user (and his client) may be in a sheltered network like his company's intranet, at work, and the server may be in a different company network so there are intermediate "intelligent" nodes the user's request, and the server response must transit between the two endpoints.
Other services, such as the file-sharing ones hosted by Torrents, are "peer-to-peer" services where computers are treated somewhat more democratically as equals, and these "equal" nodes are able to connect and communicate once they find each other using a network provided "directory".
Yet other services follow the "interception" or "intermediation" paradigm. In these cases, the server providing the service interjects service related information into the communication stream. This can be done effectively at the boundary between two domains at a server that all packets must transit, assuming the communication between end-points is not encrypted (if it is, there is no obvious way for interception-style services to work in those settings).
This taxonomy will be useful as we examine how we might offer, and bill for, Internet services.
How to generate revenue?
Lord Kelvin is reported to have said "[...] you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind [...]".
To bill someone for something, unless you intend to collect a flat fee for unlimited access on a per-time-period basis, you need to be able to measure use. But how does one go about doing this? This is where event logging, accounting, and security controls come into play. Let us now briefly look at these three ideas.
Event logging refers to the process by which we gather statistics for various pre-defined network occurrences or events. You may want to collect information for a wider variety of events than the set you need to bill for the service because billing models may change over time, and you never know what information you might need to validate your current billing model, or perhaps even design a new one. Having more data at hand is usually (though not always) better than having less. Of course, collecting more data puts more of a burden on the service and might impact performance adversely. So there is a trade-off here (so typical in engineering).
Accounting or billing (not strictly synonymous, though we use them inter-changeably here) is the process that tells you what to do with the data you have so painstakingly collected. Collating the data together, and generating bills falls into this bucket.
Security controls are needed from a billing perspective to ensure authentication, authorization and accounting functions (sometimes referred to as AAA) enable you to ensure that services are provided to parties who are who they say they are, are authorized by the parties using the service, who can then be billed with non-reputation guarantees i.e. they cannot later claim the service was delivered to someone else or that it was not delivered to them at all. These are supported in different systems in various ways.
... and the $$$ comes rolling in... (with examples)
The key to being able to generate revenue is to provide some service that adds value, and then get as large a user-base to sign up as possible, and then either bill the users themselves, or some third parties that benefits from the user population that logs into your portal (think advertising revenue), or some combination thereof. Start-ups these days tend to build a multi-platform model (sometimes also called a multi-sided market) where you first give away service for free to attract users, then attract advertisers to generate revenue, then change the provided service to a tier-ed structure where higher levels of service require payment from the user base as well. With the advent of cloud technologies, as user data gets stored more with the service provider (who can rent large amounts of storage space in the cloud from companies like Amazon), this raises user switching costs, making it more likely that users will stick with you, and you have a growing and captive user base. This last factor is a major contributor to the success of services like Facebook, Twitter, and LinkedIn.
In Social Media based services, users value the networks they build, but these are hosted on the Facebook servers and are not things the users can pick up and leave with. The same goes for media about the users that the users themselves, or others inject into the system. Twitter users cannot take their followers onto a competitor's system unless a big mass of other users moves with them as well. All these services are successful primarily because of network effects. Metcalfe's law ("the value of a network is proportional to the square of the number of users connected to the system") holds strong sway over the services here. LinkedIn is a third example of a successful service - this one focused on somewhat more serious professional networking applications. One difference between LinkedIn and Facebook is that the former is somewhat more rigid. You can "unfriend" people on Facebook, but if you allow someone into your network on LinkedIn, you cannot take them out. This may have consequences to how these two services grow over time.
Does anyone remember Second Life from Linden Labs? They even used to have their own currency (called Linden Dollars) in the Virtual World. Somehow, Second Life went from all the rage a few years ago to a somewhat more quiet existence now. Guess there is a cycle to everything - turn, turn, turn.
We note some different ways in which mobile applications are monetizing value today. The first two models are obvious ones - 1. through advertising leveraging platforms like AdMob, and 2. by selling downloads at say $0.99 each. Lately though, more and more apps are selling "usage rights" - you can play the game so many times, or read so many documents with our software each time you pay a $0.99 fee. And perhaps periodically free usage "turns" can be made available through special promotions or at first download, to gain in popularity and drum up interest.
This is similar to the "revenue sharing" model telecom equipment vendor firms sometimes use: give away the platform (hardware) for free, then have the service provider pay you a certain percentage for each transaction they bill the subscriber for. This is also similar to how Apple bills application developers. You pay a fee to sell your app via the iTunes platform, then get a percentage of the total money you make from downloads.
