Just a few comments.
Writing your own log analyzer is (a) harder than you think and (b)
re-inventing the wheel. There are thousands of them out there (really)
ranging from perl scripts that will last until your site reaches 100
requests a day to distributed data mining tools that can work with
traffic volumes like Yahoo!'s.
Writing scripts or small helper programs that analyze the logs for
specific data is different. Those are achievable and possibly very
useful. In many cases much easier (especially when you know exactly
what the data will look like) that an "all purpose" solution. You can
also, often, use Analog in these scripts to filter, alias and
summarize the data before post-processing it (or re-processing in
subsequent Analog runs).
The assumptions you are making about the ANI is the same that many
people did for hosts. This is an old issue. Even the PABX issue is the
same as a proxy. Years ago, web analytics stopped assigning one user
to a host. The ANI -> person correlation sounds about as vacuous. But
if that's the metric that you are using and that is accepted in your
industry, you should use it.
It has been my (unfortunate) experience that all really interesting
project require more than one tool. Go figure.
--
Jeremy Wadsack
Wadsack-Allen Digital Group
Eric Paschoalick Chaves ([EMAIL PROTECTED]; Tuesday, January 07, 2003
11:26 AM):
> Jeremy,
>> There are many, many, many threads in the archives (see the
>> bottom of the email) covering the topic of sessions. There
>> are pro- and con-arguments. There are some strongly differing
>> opinions out there.
> I haven't search the archives. Ok, I was lazzy about that. :}
> Anyway this small discussion is being very produtive for me. For what
> you have pointed, I'm really moving my opinion from using some log
> analyzer to writing my own, in certain cases. I'm still considering to
> use log analyzer to get some statistic values of content access. Also, I
> found that having the opinion from people that already has discussed the
> topic is very good since this always come as a "summary" of more
> extended discussions. I wish to say too that I'm not looking for a
> *how-to* or *step-by-step* stuff. What I need for now is find out *what
> kind* of report I can or cannot get with Analog, even if I use some
> trick's that is not usually covered on read-me's. Once I understand what
> I can do or not, and choose for this or that particular tool, I think
> that is my duty to study the tool and learn how to use it. However, at
> this moment I need to indicate one or two tools to be picked, and as you
> can imagine, this work would be impossible if I had to learn in deep all
> tools resources.
> For this, I really thank you for taking some time to point out
> my doubts about Analog.
>> As for finding customers who access only one type of
>> information, that is a more complicated problem. You would
>> need to define what requests constitute "sports content" and
>> then tally all sessions that that include only this. That
>> could be very memory intensive, but again, a separate script
>> or process might be useful.
> This is relative easy. The directory structure reflect this,
> plus the files names. This is a convention that we use in order to
> allow us to gather those statistics. For example, all sport contents is
> named SPORTS_*.wav
>> Now, I am still not convinced that you have definite sessions
>> in your system. You have only two hosts, so that's not a
>> valid session identifier. Each host can handle up to 30
>> concurrent sessions. What identifies the sessions? You said a
>> cookie or a URL key, but what does it reference? If it only
>> relates to the modem, then all you really have is a proxy.
>> Can you define it to create a new, unique session ID when the
>> user calls and expire that ID when the user hangs up?
> Yes. The most common information that I have is the caller's
> number (we call this ANI). We consider that each ANI correspond to a
> user, since in telephony business we threat a number as a "client" (in
> sense of person, not client like web-client). The only exception occurs
> if you call from a PABX, where more then one person call at the same
> time under the same ANI. But in this case, we still consider them all as
> one person (one client) wich is the enterprise that owns the PABX. Also
> I have a call ID, asp session's ID that I can use to generate unique Ids
> and even if needed I can generate GUIDs (keys generate tby an algorithm
> that are guarntee to be unique) for each call by myself and use them.
> That was the aproach that I was planning to use, generate on GUID for
> each call, save them in a cookie/url param and use that for path's
> report.
>> How do you plan to persist these across sessions (e.g. for
>> discounts to the top 100 longest sessions)? If you use the
>> incoming telephone number, you cannot be sure that the phone
>> number is always the same user. Most phones are shared. What
>> about public phones (pay phones or concierge services)?
> As said earlier, we do assume that each ANI correspond to one
> user. This point was where my doubt started. I wish to save them as
> cookies or URL parameters and hope that Analog could gather those
> reports based *only* with those informations, or those info AND (boolean
> and) page name. But this seems not to be the case.
>> While Analog won't produce the reports you want, there may be
>> other options. If you are able to create an accurate session
>> identifier (or are comfortable with the approximation) I can
>> think of a handful of commercial applications that will
>> produce reports including visit-length and path-analysis.
>> These are marketing-oriented applications whereas Analog is a
>> log-analysis tool. There may be a place for both in your enterprise.
> I'm sure that still can use Analog here. I wish I could focus
> only on one tool, since this should be easy to learn and operate then
> having various tools. Also, If I wasn't be able to do just the path's
> report (wich I can do with scripts and other stuffs, as you suggest) and
> do all other reports with analog this will be just great.
> Regards,
> Eric.
+------------------------------------------------------------------------
| This is the analog-help mailing list. To unsubscribe from this
| mailing list, go to
| http://lists.isite.net/listgate/analog-help/unsubscribe.html
|
| List archives are available at
| http://www.mail-archive.com/[email protected]/
| http://lists.isite.net/listgate/analog-help/archives/
| http://www.tallylist.com/archives/index.cfm/mlist.7
+------------------------------------------------------------------------
