That’s a really nice idea.
I modified a lot of date strings to customize not showing YYYY of something else. It would be nice to have it in the dashboard by default.
That’s a really nice idea.
I modified a lot of date strings to customize not showing YYYY of something else. It would be nice to have it in the dashboard by default.
Looking good guys!
When you drill down to a specific graph, you lose the metric. Below is the DAU/MAU graph drilled down from the dashboard - and now we don’t know the number as was displayed on the dashboard graph:
Can we get the metric for the graph displayed right next to the graph name? Essentially replicating the tooltip and metric value as on the dashboard
Sorry I don’t understand, the tooltip is displayed on the title, and what do you mean by “value” ?
On the dashboard - the graphs look like this with the tooltip and the value of the metric:
When you drill down to the graph itself so that you can customise the timetable, you get the following without the tooltip (not that big of a deal) and without the value of the metric (bigger deal) and it’s corresponding hover explanation:
Does that make sense? It would be extremely helpful to have the same info on the customisable report graph as the dashboard graph
you have the tooltip, look under DAU/MAU : “No. of members…”
Concerning the value, I don’t think we will add it on that screen, but we are probably going to add previous period trend line in the chart in 2.1.
This doesn’t really help if you have to go export the data and then do a sum function to get the result. It’s a lot of wasted effort when it could be added on that screen since the function is already created for the dashboard summary graphs.
No it’s not that simple because this page can show arbitrary ranges, when dashboard page functions are done for yesterday/seven days/thirty days ranges. Also this is not the new dashboard page, so it’s kind of off-topic for now, but not saying we don’t want to improve the single report page and we could maybe add your suggestion.
Does DAU/MAU have some sort of target number, showing that DAU/MAU health is good? E.g. should it be above 50% or some such, like net promoter score? If so, it might be nice to add this info to the helper text. Also, DAU/MAU is new to me (and probably to many others) so some sort of link to more details about it might be helpful.
Also, should maybe “DAU/MAU” be renamed “Stickiness”? I did a google search, and came across this explanation in a tech crunch article about facebook apps:
Real retention numbers for other people’s products are notoriously hard to come by, but in Facebook there is good 30 day retention data called the DAU/MAU Ratio – which can also be called Stickiness. This is the ratio of Daily Active Users to Monthly Active Users. For example, a DAU/MAU ratio of 50% would mean that the average user of your app is using it 15 out of 30 days that month.
Well, the help text for DAU/MAU says:
No. of members that logged in in the last day divided by no of members that logged in in the last month – returns a % which indicates community ‘stickiness’. Aim for >30%.
hmm… must have been added since yesterday?
Yes, it was. https://github.com/discourse/discourse/commit/0db04956d7b4b0bf2629decab448f2dcc86efc76
Shouldn’t lower values for “time to first response” be green instead of red?
Perhaps not as easy as a red vs. green, but might negative Y axes be appropriate for some graphs?
@Sam I PM’d you earlier with the Chrome Javascript errors that appear
can you just post it here please ?
Sure, it’s crazy long, how best to use markdown to encapsulate?
Use a service like pastebin
The code looks like this:
[details="Depending on how long it is, you could use a details tag"]
The code looks like this:
```markdown
[details="Depending on how long it is, you could use a details tag"]
The code looks like this
[/details]
```
[/details]
This was in relation to the graphs that intermittently never appear. When that happens I get something like the following in Chrome dev console (pastebin will expire in 24hr). URL is anonymised.
EDIT: Just upgraded again to [v2.0.0.beta10 +21] and everything loads fine now, seemingly every time? Good stuff!
@Sam, tested on both my sites … happy to close this issue for me … am curious to know what the fix was
I fixed it my last commit, Time to first response will be a “lower is better” kind of stat.
I also refactored and added tests for various computations in reports, if you see anything that doesn’t look correct please let me know.