Support/MetricsDashboardPRD

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
  • Flexible framework where new metrics can easily be added via new SQL queries
    • Properties of an individual metrics object would include title, display format (%, number, etc), category, and period length (e.g. day, week, month)
  • 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.
  • 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 -- not entirely clear what this means (needs discussion)
  • 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)

Future ideas (not formal requirements)

  • 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.

Needs decision or investigation

  • 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?
  • Are we aiming for TikiWiki integration, or are we making the dashboard separate?
    • What about productization of SUMO? Having this integrated would make it easy for other installations of SUMO (e.g. Fennec, Thunderbird) to use the same features.
    • 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