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 не включает время, которое пользователь мог потратить на чтение писем, отправленных с сайта. Его значение рассчитывается на основе времени, которое пользователь провел с открытыми темами на экране. Подробнее о том, как рассчитывается время, см. по адресу: How does post tracking work in Discourse.
Вы можете отправлять 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 также должны работать. Убедитесь, что вы добавили .json к URL-адресу и что параметры запроса start_date и end_date включены в URL-адрес.
Очень полезно и проясняет ситуацию. Спасибо, @simon.
Можно ли сказать, что recent_time_read — это единственная статистика о пользователе, которая не искажена временем, то есть имеет общее временное знаменатель?
Существуют ли общесайтовые итоги для чего-то вроде time_read или posts_read_count?
Гораздо чище, чем у меня было, и это действительно сработало, как только я добавил .json.
Спасибо ещё раз. С нетерпением жду начала работы с этими данными!