Board Thread:General Discussion/@comment-1820055-20140724161707/@comment-24928130-20140725013703

So revising that idea of dashboard statistics? =)

Anyways, I think one of the reasons why the database wasn't of much use was that, if you were like me, completely forgot the thing existed until the later stages of the event. By then, the wiki page had more or less all the info needed.

The pin idea would be limited in helpfulness I think. For sure it can be use to quickly and succinctly highlight branching rules (or whatever you want), but anything past a couple lines of notes and I think it might become unmanageable or cumbersome. Even then, you need to know what exactly to note on the pin and hope that it is actually helpful. At some point, your list for a specific node might get too long with variations of the same theory. You could, of course, put the theory list for a node on a separate page and the "note" would only highlight the top voted theory.

Drops, I think should be left to the wiki page because I don't see a whole lot of value in duplicating information. You could just pull data from the wiki and format that information to fit your needs. That information is only of interest for those who has already finished the event (or whatever their goal was) and by that time, the drop table in the wiki was already pretty comprehensive. Any rare drops like Hamakaze, Urakaze, and etc... can be easily noted in some general notes field.

Finally! Analytics! I think the main issue with this would be: a) how (easily) is data going to be reported; b) and what data you're looking for. If you require too much input, you'll probably put people off from using it and the data required should be the bare minimum. Stats can be deceiving through voluntary submissions (seeing people frustrated over LSC and development stats is already proof of that). In the end, I think people will end up looking for the following:

a) Best overkill fleet to power through the map and associated equipment

b) Cheapest fleet for farming purposes (and associated equipment)

Everything up to that point will be a clusterf*** of various data where you could report the three most used (successful) compositions. No need for percentages, that'll probably confuse people.

One thing I suggest that you could consider... you have this database built and you have KC3. Integrate the two (bi-directionally or unidirectionally). I'm not sure what Google's policies are regarding a tool that siphons data out in terms of privacy and all that jazz, but you could have people opt-in if they wish. Alternatively you could have KC3 spit out a batch file of results that people can upload to the database to be parsed, greatly simplifying the process in general.