Last week we looked at why real-time tracking lets you identify actual concurrent usage. This week we’re looking at the issues and benefits of “pay per X (insert your metric here) tracking.
First, let’s set some assumptions. The applications typically supporting pay per X:
Are Software as a Service (SaaS), because these can easily offer discrete bits of value
Offer API’s which allow discrete delivery and tracking of the bits
Tracking, accounting and verifying compliance for value inside an application is hard. Why is this so? There are a number of difficulties:
If the X is within the application, there is no external way to track it – like you get 1 GB data storage per user and then you pay
The X may in fact vary based on some conditions, such as the first 100 API calls are free, and then you pay
The X may vary, such as the size of video or audio files because these aren’t designed for a “standard” size
Perhaps the most troublesome issue for tracking and compliance is the only way to know your status is via reports from the vendor providing the service. There is typically no instrumentation that an organization can access to for status tracking. In addition, how does an organization create a database of items with variable value? It’s one thing to say an organization is licensed to x copies of an application like Microsoft Word. It’s another thing to say a group inside the company is licensed for 100 GB of data transfer. There may be no controls as to how many users can use the data, so long as they have a company email.
Vendors providing the pay per X are also typically smaller vendors. These firms aren’t concerned about ease of compliance. They are focused on ease of customer acquisition, ease of use, and market share growth. They don’t have incentives to “throttle” usage of their X by sending alerts to users that usage limits are about to be reached.
In addition to technical issues around tracking, SaaS applications and business models are structured to make it easier for the end customer to get access to the service. The first SaaS companies looked for ways around corporate procurement, and the user organizations were provided operating budgets to allow for rapid local decision making. The net result is it’s much more difficult for the central tracking group to identify if these applications are being used.
Lastly, SaaS applications typically start with very small usage, supporting niche needs. It isn’t cost effective administratively to try to find out all of these applications in the enterprise. The SaaS companies are keenly aware of the multiple implementations they may have in an enterprise, but this information isn’t going to make it to procurement or compliance until the SaaS vendor wants to negotiate an enterprise contract.
What are the benefits of these applications and licensing/usage models? First, the vendor is providing differentiated value to multiple user groups. If particular capabilities or data elements have more value, then why not charge more for that? By the same measure, customers don’t want to pay for capabilities or data elements they don’t need? So it’s a safe bet that the trend for pay per X is going to continue to grow.
And where does end-point tracking play in all of this? It depends on the application. If the application being monitored for compliance is user based, it’s a fairly simple manner of tracking usage by URL’s being called. If the application’s value is something like per GB of data, or per API call, the tracking instrumentation can get more expensive than the tracking benefits, and you have to hope the vendor provides a vehicle for usage reporting (and the end user organization is willing to allow another group in the company to get access to the usage reports).