What would you like to see on your Discourse 2.0 Admin Dashboard?

community
#74

I like the way Grytics lays it out…

  • the ability to export everything in csv to generate reports or nice pdf to bring to a quick meeting.
  • I really like the way they show the top performers so you know who your most valuable contributors are at a glance.
  • I like to see the top conversations in a specific time period so you know what content really connects with your audience
  • The number of “active members”
  • I like how they lay it out pretty simple, but allow you to click-through each metric to dive deeper.

Basically, everything they show is very helpful and informative for someone focusing on growing a community

image
image.png1793×776 251 KB

11 Likes
#75

I think a good metric would be the number of unique contributors.

#76

I’ve been working up a localhost PHP script that works with the Users CSV export file.

One thing that I think has potential wide spread usefulness is what I’m calling “longevity” or “retention”. So far it:

  • tests for the existence of created_at and last_seen_at
  • converts created_at to timestamp
  • converts last_seen_at to timestamp
  • subtracts created_at from last_seen_at
  • switch-case increments year+, year, month, week, day, hour betweens and less than hour counts

So far it is only an overall “snapshot” and isn’t intervals, but nonetheless gives interesting results.

2 Likes
#77

I may have missed a comment about this, but here goes. While I realize I can get some similar data from my analytics, the following would be great to be able to access from the admin dashboard.

Under the “Top Traffic Sources” and “Top Referrers” section, it would be great if you could click to see what topics are having the highest traffic for that given point or month. It would also be great to be able to see a longitudinal history (longer than 30 days) for those two sections as well.

#78

Any news or prototype of the dashboard? :slight_smile:

1 Like
#79

Sure. Here is a hifi prototype that @awesomerobot did of my initial design.
@joffreyjaffeux is currently working on a v1 which will be shipped with the 2.0 release.

That may mean that not everything you see here will be included in the first instance but we’ll iterate.
Also note that there will be a separate moderation dashboard in the future.

dashboard-design
dashboard-design.png2420×3798 1.08 MB

35 Likes
#80

This is a fantastic start @awesomerobot / @HAWK / @joffreyjaffeux I am assuming most of the above metrics will be available for non-hosted, except for obvious ones of course

1 Like
#81

Yup, that’s the plan. And thanks.

1 Like
#82

New dashboard looks great - I like the format for the community health metrics, as those charts show a lot more detail than just “up” or “down” from a previous period.

Including a section for data queries is also great. Does Discourse ship with any pre-loaded queries in Data Explorer? It looks like it should be a great way of helping CMs to start exploring their forum data, as I’m guessing that many people don’t venture into the plugins area very often.

6 Likes
#83

Not at the moment but I like this idea.
Impt to note that DE isn’t available on Standard hosted plans we we need to figure out how that looks.

6 Likes
#84

Is it possible to add a hook which identifies if the plugin is installed (for self-hosted) and loads it on the dashboard? In addition those preloaded queries would be great to include the queries for those graphs

4 Likes
#85

Important to note that I considered doing that while writing it, but couldn’t come up with a good list of what to pre-load.

1 Like
#86

Nice!

What I am realy missing for my self hosted instance are some hardware information, like memory, diskspace and cpu usage. That would be awesome.

#87

All good, that’s my area of expertise. Although TBH we used to measure pretty different things only a couple of years ago. The things we used to KPI ourselves on are now considered vanity metrics.

That’s outside of our scope I’m afraid. We don’t have a reliable way of providing that information across all instances.

1 Like
#88

That’s where monitoring with Icinga or Prometheus kicks in. You’d also want to ensure that Docker is running, and many other things in the background. I do understand that CPU, disk usage and memory is more easy to find out about but always consider that the application is running inside a container. Which runs isolated and may not necessarily fetch host system information that easy.

Here’s an example of which additional services I do get notifications for. One may consider adding such as a custom URL into the Discourse dashboard, maybe.

35
Screen Shot 2018-04-12 at 11.20.35.png1297×781 83.7 KB

Maybe one could collect some metrics from inside the running container, I am not that deep into the Discourse backend yet. Would be interesting though, also to have them exported via the Prometheus exporter plugin.

2 Likes
#89

Not what you’re asking for, but Digital Ocean will show that on their dashboard.

#90

That would recommend using Digital Ocean as hoster, that no solution for me.

What I dont want is complex monitoring, just the possibility to take a quick look and see that my system is or will not out of ressources. But as it is not at the scope of discourse, its ok for me. Was just an idea.

2 Likes
#91

I like that idea, some sort of self-monitoring. Do you know Graylog (for logs and event collecting) … this also has a memory usage indicator. Differs from the stack though, Java has access to these metrics. I’m toying with the idea to look what’s possible with Ruby here, but it will take some time.

1 Like
#92

I’ve seen that this is now in Git master (experimental, cannot get it to work in prod right now).

Since I’ve also read about PostgreSQL 10 as backend, I was wondering if the inner components versions could also be displayed in the admin dashboard. Like PostgreSQL 10.x.y, Redis 4.x, Ruby 2.5.0 and so on. This would allow to identify specific build versions better, and help with troubleshooting. Although I do understand that this requires queries to many backends, and likely should be cached somewhere in the database during upgrade/installation. Just an idea :slight_smile:

5 Likes
#93