Website Metrics

You get what you measure. And one way to influence behaviour is to provide an easy metric that is aligned to the behaviours you want to encourage.

This is as true in software as anywhere else, and is one of the reasons why software metrication is an important aspect of software quality.

In a post How to Misuse Google Analytics, Seth Godin points out that Google Analytics measures the success of a website from Google's perspective. Google's commercial objectives involve things like maximizing advertising revenue.

But as Seth points out, the quest for traffic can cause a website designer to make bad decisions. While many websites may benefit from advertising revenue, most non-spam websites have other objectives as well - for example, disseminating and championing new ideas. Google Analytics does not provide metrics relevant to these objectives.

Thanks to Google Analytics and related mechanisms, Google provides a positive feedback loop that reinforces its own commercial agenda. Systems thinker Donella Meadows identified the provision of such positive feedback loops as one of the ways of exerting power and influence over a complex system. (Wikipedia summary, original paper), and anyone who wishes to counteract this kind of power and influence should study her paper carefully.

SalesForce adoption

Howard Smith (CTO of CSC) has done an analysis of SalesForce.com, provocatively called SalesForce Dot Bomb, in which he uses what he calls Dilution Ratio (the average number of users per customer) as an adoption metric. He suggests that the dilution ratio is a reasonable measure of whether Salesforce is penetrating larger firms. 

I think this means individual users per user organization (although I'm not sure whether this is what his figures actually represent). I think it would make more sense to call this a concentration ratio - the more individuals using SalesForce within a given organization, the higher the concentration. To my ears, the word dilution suggests the exact opposite - spreading a given number of users more thinly across a larger population of non-users. 

Howard's figures show a fairly slow increase of concentration, and he interprets this as problematic for the commercial success of SalesForce in providing services to large enterprise. I am not convinced by this interpretation. User volumes are increasing and concentration is increasing. Isn't this a good thing? 

Technology adoption can be mapped against two axes - individual adoption and collective adoption. Traditional enterprise software vendors have always tried to increase concentration, because this reduces the cost of sales. You don't make money selling one copy of your product to Megacorp Enterprises Inc for a pilot project that requires loads of unpaid customer support. You start to make serious money when Megacorp integrates your product/service into its architecture/standards, and buys a thousand copies for distribution around the organization. That's when the salesman takes a well-earned cruise around the world. Clearly a thousand copies to Megacorp, even at a significant discount, is going to be more profitable (at least in the short term) than a thousand sales to a thousand separate pilot projects.

But traditional software vendors have also paid a lot of attention to "new name" business. You cannot sustain growth indefinitely by increasing the concentration (penetration) within existing customer organizations. Thus in very crude terms, significant growth comes ultimately from new name customers, while profit comes from better concentration in existing customers. In some sectors of the software industry, the vendors with the best concentration are the ones with mature products and trapped customers. (Sometimes it seems as if it's not the products that are treated as cash cows but the customers.) 

Howard is now raising a very interesting question - to what extent is this business model relevant to the new breed of software-as-a-service vendors such as Salesforce? Given that the economics of scale are different in the SaaS world, does this mean that concentration/dilution no longer has such a significant impact on a software company's profitability and commercial viability? Or perhaps concentration/dilution are still relevant, but these concepts now need to be understood differently, against a different kind of reference model? 

Remember that we are talking here about a CRM solution. Let's say that Megacorp Enterprises Inc adopts the Salesforce.com solution for all its customer data. Let's say that Megacorp has 1,500,000 customers, with 250,000 new customers per year. That seems like a much more interesting adoption metric than the number of Megacorp employees who are registered users of the Salesforce service - particularly if some of the "users" of the Salesforce services are lumps of software rather than human beings.  

 

via Barry Briggs

Software Pricing

A few weeks ago, an article in the Economist (July 14th 2005) set the software industry buzzing about new business models for software, and given new impetus to discussions of Software as a Service (SaaS).

I did a short piece on service economics for the CBDI Forum (July 20th). Other industry analysts who have commented on this include Britton Manasco (July 15th, August 5th), Phil Wainewright (July 21st) and Sadagopan (August 7th).

The Economist article has been widely read by senior management in the software industry, and there have already been some high-level responses. Jonathan Schwartz of Sun Microsystems sees this argument as a further justification for Open Source – which is of course merely a more sophisticated form of Input-Based Pricing. He looks forward to a world in which software is free. This business model obviously suits those software companies (such as IBM) that make significant amounts of revenue from hardware and/or services.

Meanwhile, Oracle is drawing attention to its experiments in Output-Based Pricing. In a recent interview published in News.Com (July 22nd), Oracle President Charles (Chuck) Phillips stated that "We'd love to get to a mode where we're looking at the number of employees served, the number of checks processed – you name it, some business metric – and take it out of the technology realm and tie our success to their success in terms of business."

In these statements, there is a certain amount of confusion about input-based, output-based and value-based pricing. Even in the software industry, it's hard to imagine that business success is measured by the number of checks processed. (Does Phillips know how many checks the Oracle accounts department processed last month? Does he care?)

Specialist service provider LeCayla offers software companies a managed way of converting to output-based pricing. Software producers embed some coded service calls into the software, which securely pass a defined set of usage statistics from the customer's computer to the LeCayla server. Essentially, this allows a software producer to implement a software meter – which can be based on either input measures or output measures. It also supports policy-based charging, and allows software management on the consumer side to set rules for the utilization of the software. (Rules and policies are written in a LISP-like language, which provides some scope for complexity in their composition.) Although LeCayla has a long-term vision of value-based pricing, it is currently supporting Output-Based Pricing as a step in the right direction.

When I spoke to Conor Halpin of LeCayla about the benefits of metered software, he was eloquent about the possibilities of cost containment and increased control offered to the consumer side. At present, however, LeCayla itself charges the software producer side for its services.

The trouble is that from the software producer side of the fence there may be no compelling reason to switch from input-based pricing to output-based pricing, and there is undoubtedly going to be continued resistance from those software producers who see their traditional revenues threatened by thinking of Software as a Service. Just as many software producers appear to have succumbed to Open Source only after concerted pressure from large institutional users, so we may expect much of the push towards Software as a Service to come from the same quarters.


Related posts Value-Based Pricing (August 2005), Software Pricing at CA (September 2005)