Cenové modely - co vytváří "dobrou cenu" za elektronické informační produkty?
Sjoerd Vogt, The Dialog Corporation, Whitney, Velká Británie
The Dialog Corporation offers a wide spectrum of pricing options – from purely transactional pricing, through to different subscription pricing plans. On what basis should transactional pricing be calculated – and how should the level of the subscription pricing be set so that it is fair to users and producers alike? How have the pricing models that Dialog uses changed over the years, and how are they likely to evolve in the future?


In the “old days” - meaning the 70s and 80s - charging for online throughout the industry was transaction-based only. There was no subscription pricing from anyone. Taking Dialog as our example, we see how the pricing changed as technology evolved:

1970-80:   Online time + offline print charges. NO online “type” charges
1980-90:   Online “type” charges introduced. Annual price increases concentrated on these “types”
1987: Subscription pricing available for OnDisc product range
1990-00:   Flat Fee pricing plans become increasingly popular. Controlled-growth plans + cap
1998:  Dialunits introduced.
00-        :   Subscription pricing for online databases introduced: controlled by concurrent user.

The introduction of DialUnits was a major change from the traditional charging for time. Dialunits represent a mechanism whereby the user is charged for “amount of processing” and depends only for a very small part on the time taken. The initial “rounding-up” of Dialunits made them uncompetitive for short searches and was not surprisingly badly received by the information community.  However - within six months of introduction, the rounding up was eliminated, and from that point onwards, Dialunits have represented an extremely competitive and fair way of charging for online searching. There’s no penalty for a slower communications connection; or for thinking; or for language difficulties - for example. However - there is STILL a charge for mistakes!

Charging for mistakes and end-user searching don’t go together.  For searching by end-users in the academic environment or on the corporate intranet, then charging has to be truly unlimited use for fixed cost - often simply called AYCE (All You Can Eat).

Dialog has had AYCE charging for its OnDisc range of products since 1987; however it has not had true AYCE for its online databases until this year.

It is the internet and dialunits have made online AYCE on Dialog possible. Previously, we could not have taken the risk of compromising our all-important corporate users paying per second by opening the AYCE floodgates.  However - on the internet each search is treated as a separate transaction. Therefore the system can support many more concurrent users without any noticeable degradation in service or speed. If there IS any degradation - either due to the internet itself or due to a heavier load on the system, then the DialUnits method of charging ensures that users are not penalised.

We now look in more detail at the different ways in which subscriptions can be charged.


To have subscription pricing that’s perceived as fair by IPs, by Dialog, and by customers.

And that’s it! Perceived as fair by customers = competitive. Perceived as fair by IPs = solid . Perceived as fair by Dialog = sensible.

 “Per Seat” vs Site License vs Concurrent

Database subscriptions are sold throughout the industry using variations of  just three network pricing models: These are:

1.Per Seat (eg FTE) Charging by number of occupants
2.Site License  Charging by number of houses
3.Concurrent Charging by number of TVs

Each model (of course) charges more if there are more TV channels (ie more databases). That’s self-evident. (and PAYG is like charging for each minute of watching).

Each of the three models DOES have its merits; but also weaknesses. We need to have pricing that brings together the best of each.

Per Seat: “You charge by number of occupants? How unfair! Five of us don’t watch TV - and two others are blind….”   . Per seat pricing is subjective - and not controllable. There MAY be a relationship between the number of people & the usage- or there may not.

Site License: “You charge by number of houses? How unfair! We’re two old people on our own in a tiny little house - & we’re paying as much as that family in that big mansion with its army of staff & servants! Per SITE pricing does not distinguish between large & small. It MAY be fair in particular cases - or it may not.

Concurrent: “You charge by number of TVs ? Hmmmmm, that’s interesting……  BUT - charging by concurrent alone would mean that a single house with FIVE TVS pays as much as five houses each with only one TV. That’s unfair.

Of the three models, charging by concurrent user is certainly the most objective - by far.

"Companies in our business are finally coming round to the inevitable conclusion that simultaneous user charging is the only model that makes sense. It's measurable, controllable, and completely objective."
.     CEO of Netlibrary (a US eBooks company) - Oct99

“I couldn't agree more.”
    Sjoerd Vogt - Jan2000

And if we control by concurrent, therefore we should also charge by concurrent.

OK - We’re Agreed about Concurrent. But “Per Site” pricing puts a value on multiple sites…..  That’s GOOD - isn’t it?

“In this new era of WWW, charging for sites is no longer meaningful or relevant. You only need to charge for concurrent users”
commonly held viewpoint


Three reasons:

1. Site-License pricing assumes that if there are more sites - there should be a greater cost. The consensus is that this IS fair.
2. 2ndary databases are typically replacing printed equivalents. Many sites means many printed equivalents being replaced.
3. We need to differentiate between a small outfit of ten people requiring one concurrent user, and large organisation covering many sites also requiring only one concurrent user.

So - we MUST also build in “number of sites” element in our pricing.

What is one “Site”   ?

One town? One City? One Municipal Area? One clump of buildings? They’re all subjective & open to misinterpretation and argument.

Single site: All the members of the single organisation accessing the service from within a circle of 10km diameter, or from within an unbroken space of equivalent area.

Base Price

Each separate database has a separate BASE price. This covers one concurrent user on one site (10km= 6 miles) .

How do we ensure that the BASE price is competitive, solid & sensible?

Many of the must-have databases are already available on subscription via a number of different channels. Dialog’s BASE price is set by comparing with existing pricing for the same database.

The policy is NOT to have the lowest price (we would lose this battle when competing with IPs-direct & with academic networks). The policy is to sell on VALUE (depth/breadth of coverage; strength of interface). However - in many cases we WILL be able to support a lower base price that our aggregator competitors - because our costs will be lower.

For those smaller databases that are NOT available on subscription via other aggregators, then there are no market guidelines to set a base price.

Subscription base prices are  related to the VALUE of the data, and the number of records. We already have DIALUNIT pricing for every online database - which is clearly also linkned directly to the VALUE of the data.

The following rule of thumb is useful:


…. With Base prices typically falling between $500 and $3000 .

Example: The Architecture database is 150,000 records and costs $2.35/dialunit. Therefore the BASE price will be 150 x 2.35 =  $495  .

This rule of thumb gives you as good a starting point as any.

Network Pricing Model

The network supplement (the charge that is in addition to the BASE price) should depend on the number of concurrent users and the number of sites. As agreed above.

It should allow for different values for different databases; it should be easy to calculate and to administer.

It should work in such as way as to give comparable pricing to alternative models (per-seat and site-license).

Each database carries a BASE price and a netunit (NETUNIT) price. Each netunit buys a certain networking bandwidth - according to the following table:

Max #Users Maximum Number of Sites
           1 Site   2     3     5     7     10     11+
1User  0         1     2     3     4     5     Call
2         1          2     3     4     5     6
3         2          3     4     5     6     7
        3          4     5     6     7     8
7         4          5     6     7     8     9
10       5          6     7     8     9     10
15       6          7     8     9     10    Call
20       7          8     9     10    Call
21+     Call

Example: - if a customer wishes to network a product across three sites and for seven concurrent users, then this will cost them SIX netunits.

Example: For Compendex the BASE price is $5420, and the NETUNIT price is $1250 . Therefore - for 3 sites/7 users, the total cost is 5420 + (6x1250) = $12,920 .

Each netunit sold is treated as a separate product. This makes the administration of upgrading mid-subscription year extremely easy.

What would be the typical cost of a NETUNIT?
It will be 25% of the product price. BUT - it can be anything that represents a fair networking value for that particular product! From zero (medline) to whatever…. There can also be multiple NETUNIT prices for the same database (one for academics, a second for corporates.)

Will IPs like NETUNITS ?
Yes - because it gives them the flexibility to apply a unique value to the networking of their product. However - most will be comfortable with the default of NETUNIT/BASE=0.25 .

What about those Information Provider and Customers who insist that “per-seat” pricing is a better measure?

There ARE IPs who may already have network pricing based either on FTEs or on “relevant users”. They may need persuading to accept the NETUNIT model. It helps to see that there is a useful conversion rule:

For academics:     #Concurrent users = square root of  #relevant users/50
For corporates: #Concurrent users = square root of #relevant users/10

Academic Example:   450 relevant users = 3 concurrent users
    1250 relevant users = 5 concurrent users
    5000 relevant users = 10 concurrent users

Corporate Example:  500 relevant = 7 concurrent
    1000 relevant =  10 concurrent

On this basis, it then becomes straightforward to choose the appropriate cost of one netunit for their product so that there is approximate parity.

Consortium Pricing Model

The underlying principle of consortium pricing is that every quoted price is conditional upon IP approval.

Nonetheless, Dialog will apply the following structure as a starting point:

1. Each member of the consortium earns a discount of (number of members x 2)% on the stand-alone subscription, up to a maximum of 20%.
2. Only the HUB pays the appropriate network supplement (NETUNITS), covering ALL the members. This network supplement also earns the same discount as calculated in point one.


Trying to find a simple subscription pricing model that fits the varying needs of 180 information providers is clearly a challenge. However - by using BASE and NetUnits, we can make the network pricing graph virtually any shape we want - from flat through to a gradient of ten to one. We no lnoger need to force round pegs into square holes. This same principle can be applied to any networked electronic information product.