Re: General question on charging for data access
From: Frnak McKenney (frnak_at_far.from.the.madding.crowd.com)
Date: 12/16/04
- Next message: Frnak McKenney: "Re: General question on charging for data access"
- Previous message: Frnak McKenney: "Re: General question on charging for data access"
- In reply to: Gordon Burditt: "Re: General question on charging for data access"
- Next in thread: Colin McKinnon: "Re: General question on charging for data access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 16 Dec 2004 17:04:01 GMT
Gordon,
Thanks for responding.
On 16 Dec 2004 05:21:20 GMT, Gordon Burditt <gordonb.iv3ps@burditt.org> wrote:
>>by being disconnected). Connection time was easy to measure, and it
>>made sense to both the customer and the service provider as a rough
>>metric for value received by a customer.
>
>Connection time no longer provides a good metric (if it ever did),
>as it used to be limited mostly by bandwidth, and now it is not.
Yup. Also it generally involved an "authorization" step when the
connection was being established and a "disconnection", both of
which aren't explicitly available for HTTP transactions.
>>Things have changed. The stateless design of HTTP makes this kind
>>of simple "time = value" approach to charging for services much more
>>difficult to implement, since there seems to be no way of easily
>>defining a "session" in its older sense. The term "session ID" used
>>by PHP and other HTTP support environments is somewhat misleading,
>>since, while it has a distinct beginning where authorization can be
>>tested, there is no event corresponding to a "session ending".
>
>Consider this possibility: a HTTP transaction *IS* a session. (Not
>in the PHP sense.) Charge for them, or at least some of them, like
>submitting an order or getting query results. Time is not a good
>metric here (the slower your server is, the WORSE service the user
>got). Consider a charge per query or a charge per unit of data.
That's certainly _possible_, but it increases the complexity of the
billing process (currently a fixed fee for one user for K months) by
the proverbial order-of-magnitude. I'm hoping for an approach that
would be easy to understand, easy to implement, and easy to bill.
(Oh, and can I get fries with that? <grin>)
--snip--
>That sounds a lot like "one page, one session, one charge". Remember,
>if the users are taught to log out IMMEDIATELY (after saving the
>results) to keep the number of simultaneous sessions down, they can
>get a *LOT* of mileage out of one allowed simultaneous connection.
>This suggests that the billing method isn't in touch with reality
>and doesn't reflect value received.
Well... after working in this industry for three decades I'm not
sure I'd claim that billing methods need to be "in touch with
reality" to work <grin>, but I'll agree that, within broad limits,
any method for charging needs to reflect the perceived value
received by the user/customer. It also has to produce sufficient
revenue to cover the costs of the site, its administration, and some
measure of profit.
Human beings prefer predictability, not just in billing but in most
things in life. It reduces stress. If I've paid a fixed fee for
database access -- or for operating my automobile -- I can use it
or not use it without worrying about whether my use is affecting my
wallet. I've "chunked" the decision process into a simple Yes/No
to the question "Am I getting $Y out of this?".
>From the site's point of view, of course, it would like some way of
distinguishing levels of use. As long as the end users are
generally scattered, flat-rate billing on a per-userID, per-month or
per-year basis is simple and makes sense to both parties. What's
tricky here is coming up with a "site-wide access license" in a way
that doesn't overstretch the current billing paradigm -- it's the
kind of shift that generates mythical billing constructs like "user
equivalents" <grin?>.
>>My customer would like some way of limiting access so that no more
>>than N (initially one) of this customer's individual users is/are
>>"accessing the database" at one time, so that usage past a certain
>>limit will cost the customer more. Unfortunately, this idea of
>>"only N simultaneous users" seems extremely difficult to implement
>>cleanly in the HTTP environment.
>
>Not only is it difficult to implement, it's difficult to even DEFINE
>what a "simultaneous user" is.
I think a definition can be _created_, but in order for the
definition to be acceptable it has to be recognized by all parties
as a workable measure of service.
> ... Consider charging per query. Or charge per significant
>query (if it takes getting through 3 pages to do a query, charge
>for the final one that gives useful results).
This is certainly possible, but doing this makes billing more
complex.
>>Limiting the number of simultaneous "sessions" (in the PHP sense)
>>from a given IP is tricky. What defines when one browser's PHP
>>"session" ends so the server can let another one be initiated? Do
>
>Nothing. Maybe you should consider whether it is APPROPRIATE to
>generate a large bill for someone who forgets to log out over a
>weekend, but generates no activity during that time. And is it
>really approprate to generate an even larger bill if one browser
>does a few queries one year, the employee retires, and when it's
>reactivated 3 years later, it still has the session open, so that's
>three years of continuous connect time?
Exactly. Or, as I explained to my customer, it "represents certain
technical difficulties". <grin>
>>you attempt to require that each end-user go through a "logout" page
>>when they are done, something at odds with the user's experience
>>with every other 'web site? (And do you set up a switchboard ot
>>handle the complaints when half the end users go to lunch without
>>bothering to "log out"? <grin>)
>
>Why should going to lunch and forgetting to log out cost a lot?
It would be reasonable if (as in the olden days) forgetting to log
out blocked access by other users. That doesn't apply here.
>>I came up with one promising approach using server-side persistent
>>non-session storage (an SQL table, say) and a fixed "expiration
>>time" (say 15 minutes).
--snip--
>>Am I spending too much time and effort studying trees instead of the
>>forest?
>
>Yes. You're trying to charge for man-hours in the forest when the
>value received is how much they remove in logs to be turned into lumber.
>Professional loggers get a bargain and the Cub Scouts get charged
>a huge amount for one tree.
Ah! Nice analogy.
Up until now, my customer (the site) has been charging forest access
on (say) an annual per-person basis, and the number of trees removed
has been limited by the needs of each individual. Now a local co-op
is asking for an annual permit to cover all of its members who have
fireplaces and is asking what we'd charge for this.
And the site and I are trying to figure out how to word the permit
so that (a) we don't feel that we're "giving the access away" if
we charge the same amount we would for (say) three per-person
licenses, and that (b) we can enforce the terms of the permit.
Is this any clearer?
>>Is there some other way (or ways) of looking at the problem
>>of charging for access that would be a better fit for data access
>>through HTTP?
>
>Pay-per-query. Either a fixed amount, some measure of how much
>data is returned, or a combination of both. For example, the
>subscription says that for $x a month, they get 500 queries per
>month, after that it costs $y per additional query. Or make it a
>per-day or per-week limit. No need to count individual users (only
>what subscription they have access under) at all.
FWIW, at this point most subscribers are "onesies" (which, of
course, is why we've managed to dodge this particular bullet for so
long <grin>).
>Think: what kind of behavior do you wish to ENCOURAGE? Don't
>charge extra for that. What kind of behavior do you wish to
>DISCOURAGE? Charge extra for that. What kind of behavior gives
>the customer value? Charge for that. Assume the customer will (or
>at least may) modify his behavior to reduce his bill.
Thank you for putting that into words. Again, the site would prefer
to work at a much coarser level than "transaction", but your
principles still apply.
Time to go fix some lunch and (ig!) think some more.
Frank McKenney
--
If you're riding' ahead of the herd, take a look back every now
and then to make sure it's still there. -- Will Rogers
--
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut minds pring dawt cahm (y'all)
- Next message: Frnak McKenney: "Re: General question on charging for data access"
- Previous message: Frnak McKenney: "Re: General question on charging for data access"
- In reply to: Gordon Burditt: "Re: General question on charging for data access"
- Next in thread: Colin McKinnon: "Re: General question on charging for data access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
