[Trevalen]

A big part of running a professional quality text game is adhering to professional methods and procedures on "the back end," in the design and maintentance of systems that players never see.

One very common "back end" system for commercial endeavors is data tracking; automatically and systematically tracking data about your customers, about how your product is used, when it is used, and where users come from,.

This applies to MUDs in some obvious ways. You can track referrers for new visitors to your website, you can track the "online time" of players, the rate (and locations) that coins enter the economy, you can log when valuable items are destroyed or when player killings occur.

My questions are, what have other MUD administrators chosen to track? What situations have come up where data tracking was unexpectedly useful? What do you wish you had tracked from the beginning but did not? How do you store your data and for how long do you keep it? Or any other interesting tidbits related to this topic.

-T

[the_logos]

Originally Posted by (Trevalen @ May 11 2006,18:08) My questions are, what have other MUD administrators chosen to track? What situations have come up where data tracking was unexpectedly useful? What do you wish you had tracked from the beginning but did not? How do you store your data and for how long do you keep it? Or any other interesting tidbits related to this topic.

As much as we think to track, pretty much. Everything from avatar deaths (broken down by source) per hour to the total number of avatar moves made per hour to data on gold generation, gold movement, lesson use, credit use, mob deaths, position on TMS, character creations, fish caught per hour, etc etc etc. You're not tracking enough until you simply cannot support the storage requirements of your logs.

Presently, we keep most data logs forever, but there are some exceptions in which a data point is only kept for a finite period of time due to the sheer amount of data in those types of logs.

Of course, just logging things isn't enough. If you don't do analyse them and react to the data presented, your logs are fairly useless. The way I look at it is that you may as well log whatever comes to mind. Some of the logs may turn out to be relatively useless, but others will be used on a near-daily basis.

--matt

[ScourgeX]

I log help file access, mainly to find out what helpfiles are missing. The tricky part is trying to guess what players are really looking for when they look up a term I never thought of

[Baram]

I hadn't thought of help files, but that's a really good idea.

*Steals idea*

[Kelvin]

We log basically every econ action in the game since our beginnings a few years ago. Initially these were flatfiles, later on we added in-game SQL support so we now use that instead. Things we track:
<ul>[*]Econ Actions (Buy/Sell Mechs and Other Things)[*]Skill Advancements[*]Every single kill and who was involved[*]The winners of scenarios[*]Player login/logout dates and usage stats[*]Tallies for capturing objectives on a per-player basis[*]XP Gains and stat totals[*]Staff/Administrative command usage[*]Objective States[/list]
This is all done via SQL and is minimal overhead, so we really try to go out of our way to track stats and make a lot of them publicly available.