I'm one of the involved with the new statistics work for OJS. I will try to better describe what's new.
The current statistics structure is based only in plugins. So now we have a plugin that will produce usage information when some usage events are completed. This usage info will be available for any other plugin that's interested in usage statistics. So, for example, if a file is downloaded, this plugin will provide the usage event information to any other plugin that's registered to receive it. This usage event has similar type of data that we might found in apache access logs. So, that's the first change: plugins that wants to handle statistics don't have to worry anymore about the common usage events. If they have one particular case they can still implement it, but the common usage events information can now be easily retrieved.
To consolidate the current ojs views and the timed views and counter plugins we also developed a new plugin. This new usage statistics plugin counts everything that is counted now and also follow as much as possible (we didn't get it verified by COUNTER yet) the guidelines from COUNTER project. So we actually already have a time limit between requests from the same origin to consider an usage event as a valid one (this policy is done just inside this new usage statistics plugin, the usage event plugin doesn't apply policies, it only builds usage events information). But the time is not user defined, it's the one that COUNTER defines (30 seconds for file downloads and 10 seconds for html).
If someone wants a different set of policies to produce usage statistics, than one can create a new plugin, use the usage event plugin to receive usage event information and implement a new metric type. The metric type is a concept that we use to distinguish usage statistics that implements different counting policies. The default OJS metric type wil be implemented by the plugin described above, the usage statistics plugin, so every place that presents usage statistics in OJS will be using this metric type, called OJS/COUNTER. But if a new plugin implements a different metric type, than the user will be able to define which metric type will be the default (on a site and/or journal level). This setting doesn't deactivate the other plugins that implements different metric types, it only defines the metric type that will be used as default to present usage statistics to users.
Another point is that the usage statistics plugin can use apache log access files or it's own log files to produce usage statistics. So, as long as users keep the log files archived, they can reprocess them with any other plugin to match any change in policy. We've already build a tool to control the log file processing that can be reused. For more technical details about how the statistics are stored, and more about metrics in general, see http://pkp.sfu.ca/wiki/index.php/OJSdeS ... .2F_III.29
It's working in progress, so some topics are still under development.