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:
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?
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.
Ah, makes sense, and very fair.
有兴趣识别访问网站的用户与仅通过电子邮件回复帖子的用户。
一个不错的指标是否可以是 time_read / post_count？仪表板中目前还没有此类数据，对吗？还有其他现有数据可能帮助我们捕捉“仅通过电子邮件”的用户吗？
要将特定用户与网站平均水平进行排名，所有用户的总数是否存储在某处？
最后，在尝试检查客户端 API 时，我正在查看仪表板中的用户访问记录，但无法使 URL 像在其他地方那样正常工作。例如，这是否应该有效？
{{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
除了我上面提出的三个问题外，有人能确认 time_read 是否确实排除了来自电子邮件的活动吗？
time_read 不包含用户可能花费在阅读网站发送的邮件上的时间。其数值是根据用户在屏幕上打开主题所花费的时间计算的。有关时间计算方式的详细信息，请参阅 https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790。
您可以发起 API 请求以获取特定报告。例如，以下请求适用于“用户访问”报告：
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;"
向 /admin/reports/bulk.json 端点发起请求也应有效。您需要确保在 URL 中添加 .json，并在 URL 中添加 start_date 和 end_date 查询参数。
非常有用且清晰。谢谢 @simon。
是否可以认为 recent_time_read 是唯一一个不受时间扭曲的用户统计指标，即具有统一的时间分母？
是否有类似 time_read 或 posts_read_count 这样的全站总计数据？
这比我之前的方案简洁多了，而且在我添加了 .json 后缀后确实可以正常工作。
再次感谢。很期待开始使用这些数据！