This PRD is just a draft.

Absolute must-haves

Metrics should be able to be categorized so that they don't just all pile up on a single page
Individual metrics may have different date ranges (e.g. last week, last month, etc.) and should be clearly labeled as such
- For example, we might want to look at the traffic of the site on weekly basis, while we would want to look at CSAT trends on a monthly basis.
Flexible framework where new metrics can easily be added. Ideally, there would be an admin panel where all metrics can be added/edited/removed dynamically
- Properties of an individual metrics object would include title, display format (%, number, etc), category, and period length (e.g. day, week, month)
Historic storage of metrics -- similar to how we're saving metrics over time on the Weekly Metrics spreadsheet
- The data needs to be stored in a way that allows us plot the data (piecharts, histograms) in the future. E.g. stored in the db or in xml files or similar.

Should be considered for inclusion

TikiWiki integration -- a lot of the data is coming straight from the TikiWiki db. Then there is a portion of data coming from site analytics software (in our case Omniture). Having the dashboard integrated in TikiWiki would simplify portability to other SUMO installations.
(Firefox Support specific) Automatic import of data from Omniture -- there is an API to pull data from Omniture, so this should be possible. Alternatively, Omniture might be able to export/send data.
Dynamic reporting -- i.e. specify what you want and what time period and have it generate just that report rather than only showing static reports
Tabbed/folded interface (because otherwise it'd be very cluttered, or the page of stats will be very long)

Graphing of data over time -- piecharts, histograms, etc.
Access to individual results (specific pages or specific locales or specific users -- may need restrictions).
- This means that you can say, click on "Firefox crashes when you open it" and see how many people get there via search vs from forums vs from front page vs Google and also what the CSAT data for that page was like and also how these things trended over time
- Or see how CSAT data is in /fr/ vs /de/ or something. Tracking by users is necessary for karma anyway so setting up a way to track it here would give us a head start on that.

Do we have any similar dashboard projects done in the past?
- Any code we can reuse?
- Any previous work on scope/implementation or good practices we can apply here?
Static or dynamic data?
- Do we store the data we periodically gather in a way that enables us to select date ranges for the data we're collecting?
- Or are we just going for a list of SQL queries that are cron-jobbed daily/weekly/monthly and just stored statically?
TikiWiki integration?
- Having this integrated would make it easy for other installations of SUMO (e.g. Fennec, Thunderbird) to use the same features. Also, a lot of the data is coming from TikiWiki (although we probably should be using the db copy of the sumotools server for performance reasons; however that could be a pref for other SUMO installations).
- Other SUMO installations might not have Omniture -- we would need an interface between website metrics and TikiWiki metrics so Omniture can easily be replaced with e.g. Urchin, Google Analytics, or whatever other sites might be using