Click stats tracker requirements

Use case

 * compare actual usage of various features on the edit toolbar, sidebar, etc ... potentially in various variants

End-user workflow example
A given user is editing a wiki page. He/she has either the old-style toolbar or the new-style toolbar. We want to record:
 * which toolbar variant they're using
 * We at least need to handle the plain vs advanced preference. In the future we should consider bucket testing where folks might have one of several variants, in which case that info needs to be tied to their session or user ID or something.
 * which buttons they push during their edit session

Things we might also want to record? Are these useful/needed/etc?
 * whether the edit gets saved or not
 * "experience level" (anon? logged-in? sysop? tiered edit count?)
 * track undos?

API for saving
Proposed usage
 * Not using separate parameters for buttons because:
 * Parameter overkill
 * Inflexible when more buttons are added
 * Stuff like ilink=0 can be left out, shortens POST data
 * No need to pass user data, API module can grab that from $wgUser
 * Token to discourage tampering? (see also below)
 * Any other relevant data to pass?

Performance characteristics?
 * Roan notes that recording every toolbar click might be prohibitive. Consider options for batching multiple clicks in a session or sampling sessions so we're not recording a firehose of info.
 * Keep an object counting clicks and submit it to the API at submit or unload time
 * My main concern w/ doing it at unload time is that it'll delay navigation away, which might feel weird. An asynchronous save batched in the background after X seconds of inactivity, maybe? Or that might be overkill. ;) --brion

Tampering?
 * Impossible to guard against; even if it's somehow hard to make your own POST requests to the API module, people can still use Firebug to manipulate the internal click counter that's submitted by our script.