Read time metrics

Sounds like a good plan.

Note that I’m not pushing back on read time on the main dashboard. It’s not a metric that people generally report on which is why it’s not included, but if enough people are asking for it then we can do it.

6 Likes

Where did we end up with adding read-time to the dashboard? TIA :slight_smile:

1 Like

I imagine we could add a Read Time report to the Reporting tab pretty easily.
Thoughts @joffreyjaffeux ?

4 Likes

I think it’s now doable in a plugin. So it’s more your call than mine, do you think it makes sense in core? Would you use it?

Having thought about this a bit more…

I think this is important to surface to users directly, in public “take a look in the mirror” UI fashion, not as much the site owners and staff in the back-end reporting. So maybe that’s what @hawk was reacting to.

What is critically important is a regular influx of new users who read (this is captured in TL1 transitions), and daily/monthly users who come back regularly and read (which is captured in the DAU/MAU). Heck, for that matter, the /users page kinda captures reading reports for anyone who wants to look at it, not just staff!

Perhaps the only thing not captured is users who come back regularly and never post (or like?), but do read. I’m a little unclear if DAU/MAU will show you users who visited and read but did not post a reply/topic.

That said, to @mcwumbly’s point I think we should still continue to look at even more ways to surface read time directly to users themselves and that’s the more important effort.

4 Likes

AFAIK DAU/MAU is using UserVisit.count_by_active_users which is using the user_visits table, notably updated in UserStat.update_time_read!

5 Likes

Do you mean their respective own read time or the read times of posts/topics? In other words: are you thinking of reading time or being-read-time, if you know what I mean?

1 Like

Forgive me if I’m being dense, please, but I do need a clarification: having a UserStat.update_time_read table means that user reading time “counts” as activity, hence making an active user? Said differently, if I come onto the site and read for, say, 30 seconds, does that count me as an “active user”? I might have tangled myself up in a confusion-knot.

While I’m not dure if there is a threshold (don’t think so, though), yes, reading counts as “being active”. A very important though often undervalued kind of activity.

4 Likes

Exactly! I think it’s interesting, but the purpose of the dashboard graphs is to make reporting quicker and easier for CMs. I’m yet to meet one that reports on general read time.

1 Like

You could turn that around and say: we think read time is an undervalued indicator so we are putting it on the dashboard so that CMs can report on it, thus making it more valued.

(The assumption is, of course, that CMs can have a say in what they report on.)

I don’t actually believe that read time is an undervalued metric in this context. Reporting should generally be tied directly to a goal or objective – generally one tied to a financial ROI.

I’m interested to hear from CMs who do think it is important to report on, and the reasons for that. I’m open to being convinced, but so far I’m not.

While not CM-specific, I feel like the “Session Duration” metric that Google Analytics puts pretty front-and-center is a reasonable proxy for this, and offers some evidence for the general utility of knowing how valuable people are finding the content on a site by way of the time they spend consuming it:

2 Likes

I’m hoping to use “read-time” as a metric for how helpful the Forums are to lurkers, specifically.

I want this, in addition to metrics on activity among contributors, because I’d like a way to report on the value we’re creating for our largest visitor-base: the non-contributors.

Am I missing another way of reporting on this subset of users?

1 Like

The issue with this approach is that you’re also counting read time from contributors – if you want read time that is specific to non-contributors you’ll need to make that distinction. A data explorer query is going to be your best bet there.

2 Likes

Ah, makes sense, and very fair.

1 Like

Interested in identifying users who visit the site vs. users who just reply to posts via email.

Would a decent metric be something like time_read / post_count? We don’t have anything like this in the dashboard yet, correct? Any other existing data that might help us capture “email only” users?

To rank a given user against the site average, is there anywhere totals for all users are stored?

Finally, in trying to examine the client API I’m looking at the dashboard user visits, but can’t get the urls to work for me as in other places, e.g. should this work?:

{{base_url}}/admin/reports/bulk?api_key={{api_key}}&api_username={{api_username}}&reports%5Bvisits%5D%5Bcache%5D=true&reports%5Bvisits%5D%5Bfacets%5D%5B%5D=prev_period&reports%5Bvisits%5D%5Bstart_date%5D=2019-06-08T00%3A00%3A00.000Z&reports%5Bvisits%5D%5Bend_date%5D=2019-07-09T00%3A00%3A00.000Z&reports%5Bvisits%5D%5Blimit%5D=50

Short of my three questions above, can anyone confirm if time_read does EXCLUDE activity coming in from email?

time_read does not include the time a user may have spent reading emails sent from the site. Its value is calculated based on the amount of time the user has spent with topics open on the screen. See How does post tracking work in Discourse for details about how the time is calculated.

You can make API requests to get specific reports. For example, this request works for the User Visits report:

curl -X GET "https://forum.example.com/admin/reports/visits.json?end_date=2019-07-10&start_date=2019-06-10" \
-H "Api-Username: system" \
-H "Api-Key: $api_key" -H \
"Content-Type: multipart/form-data;"

Making requests to the /admin/reports/bulk.json endpoint should work as well. You need to be sure that you add .json to the URL and that start_date and end_date query parameters are added to the URL.

3 Likes

Very helpful and clarifying. Thank you @simon.

  • Is it fair to say that recent_time_read is the only stat one can pull on a user that is not distorted by time, i.e. has a common time denominator?

  • Are there site-wide totals for anything like time_read or posts_read_count?

Much cleaner than what I had, which did actually work once I added the .json.

Thanks again. Excited to start using this data!