Yesterday I had a meeting, where we found pretty good idea about stats
tracking.

What we have now is a database containing the data collected from
template, that has to be included to each page, that is wanted to be
tracked.
We also have interface that allows generate some reports from this
database.

What we miss is info, about the reader and some optimalization, that
allows to speedup the generation of stats.

I suggest to push tracker forward and the only way I can do that is to
help with specification. Therefore here is my part:

1) think about the conception
- I suggest to use the database only for "current" records. The current
time period should be possible to change on demand without need of
reconfiguring.
- The stats should be part of campsite so it might be shared with other
campsite tables, not separate one. But that is not a clue. It only
simplifies the access to the database (campsite already has config files
with access codes and the instalation would be simplier)
- The stats should be installed for each instance and should be
generated for each instance automatically with the preset config and
reports

2) Think about the way to fill the database
- The current way is fine, except I suggest to hide it from template
designer and simply let parser to insert the code to each parsed page.
- By the way, I would collect info which user requested the page and
that can be done simply by using parser commands inside this code.

3) Think about the way how to administer the stats
- in my opinion this should be part of admin interface
- tracker administrator shall be able to set the time period, for which
data are kept in database. Data older than the number of days are
dropped
- tracker administrator shall be able to get list of reports you wish to
generate and periode to generate.
- tracker administrator / subscription manager shall have a chance to
list all subscribers and check those, who shall be tracked

4) Think about the presentation of stats
- reports should be separated to two groups.
a) reports generated on actual contant of database
b) reports generated periodically in webalizer style
- reports from group b) should be stored on some defined folder and
should be accessible through admin interface
- It might be usefull for subscriber to get access to his "usage" stats
without need to receive numbers from marketing team.

-------------------------

And now how the thing in my eyes should work:
piece of code in template (or inserted by parser) [combination of
PHP/javascript and template language] inserts proper values to tracker
table.
There is a cron job scheduled for each 1 hour checking, if there are
some periodicaly generated reports to be generated. I believe this is
enough. There is also cleaning part of this job, that checks for records
older than preset value and deletes all older records.
That is backend of the tracker.

The fields in tracker table should be:
numbers of: language, publication, issue, section, article, topic
string: user (value returned from )
date: timestamp of the request
other: IP of the reader - not so sure it is neaded

I believe all info like browser used and others is not that important
and values, that you get from running webalizer are sufficient, but if
you wish, you can put them there too.

----------------------------

The major thing is how to define reports. In my opinion it is not neaded
for business people to define their own reports. I believe the choosing
the report from the list is much better for them.
As I am not very good coder, I cannot write more than think properly
prior you start to design this, because we need to have 2 types of
reports. The online generated and incrementaly collected ones.
I believe the definition of these reports should be the same, the way to
handle them should make the difference.

Ondra