[ic] A new User Tacking - RFC

Paul Jordan paul at gishnetwork.com
Fri Mar 10 12:33:10 EST 2006


Hello List

I recently had a client express interest in traffic reports, knowing how
many visitors they had compared to orders, and such. I turned on usertrack
and used [traffic-report]. It is great for basic tracking and I am sure
could be extended to do much more. However, maybe it is just me, but the
logging in logs/usertrack seems frought with badness. First, its another log
file that grows large. Secondly, it tracks usage in my custom admin, plus
the stadnard admin, throwing the numbers it generates way off.

So I was thinking, a much more elegant way to achieve this is a sql table. I
wanted some opinions on the best way to go about this.

	Not track developers, admin and custom admin users
	Track visits to sales
	Track payment processor errors (i.e., billing mismatch, etc)
	Track where the vistors are from (geo)

I was thinking, I'd base things on the 'session_id_MMYY', which takes care
of uniquness and "visits". As for page access (which I am not even sure I
need) I can do an UPDATE with the query tag on each page (of my choosing) to
increment the existing value by one. I can adjust the cart items the same
way.

This so far is all that is necessary to achieve what is currently output by
[traffic-report] and usertrack. My question so far is this: Is doing a
UPDATE query on most every page a bad idea? If it is, then is it better or
worse than the logging going on on most pages with the current "usertrack"
method.  My alternative to this is to have a cron once a night go through
the new files in orders/session/* and grab the treasure trove of information
there. 

Another thing I wanted to track in this table are payment failure errors,
for easier follow up.

One of the benefits of this new tracking are I'd be able to exclude
directories and pages I don't want tracked.

Now, doing this all seems fairly easy, which makes me think someone has
already done this, or tried it. I am looking for your experience and to
point out if this might be a bad idea. I know it will work, I just don't
know if it's a bad idea :-)

Also, does anyone have any ideas for me? Something else that might be good
to record? I suppose the [env] tag would be good to find something out about
your market... What else?

It seems with this tracking table, and the existing tables that already
track session-id, you could generate pretty much any report that any fancy
tracking suite could do.



Paul Jordan




More information about the interchange-users mailing list