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.
¿Les interesa identificar a los usuarios que visitan el sitio frente a los que solo responden publicaciones por correo electrónico?
¿Sería una buena métrica algo como time_read / post_count? ¿Aún no tenemos nada así en el panel de control, verdad? ¿Hay algún otro dato existente que pueda ayudarnos a capturar a los usuarios que solo usan el correo electrónico?
Para clasificar a un usuario determinado en comparación con el promedio del sitio, ¿hay algún lugar donde se almacenen los totales de todos los usuarios?
Finalmente, al intentar examinar la API del cliente, estoy revisando las visitas de los usuarios en el panel de control, pero no logro que las URL funcionen para mí como en otros lugares. ¿Debería funcionar esto?:
{{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
Además de mis tres preguntas anteriores, ¿puede alguien confirmar si time_read EXCLUYE la actividad que proviene del correo electrónico?
time_read no incluye el tiempo que un usuario pueda haber pasado leyendo correos electrónicos enviados desde el sitio. Su valor se calcula en función del tiempo que el usuario ha tenido los temas abiertos en la pantalla. Consulta How does post tracking work in Discourse para obtener detalles sobre cómo se calcula el tiempo.
Puedes realizar solicitudes a la API para obtener informes específicos. Por ejemplo, esta solicitud funciona para el informe de visitas de usuario:
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;"
Las solicitudes al endpoint /admin/reports/bulk.json también deberían funcionar. Asegúrate de agregar .json a la URL y de incluir los parámetros de consulta start_date y end_date en la URL.
Muy útil y esclarecedor. Gracias @simon.
¿Es justo decir que recent_time_read es la única estadística que se puede obtener de un usuario que no está distorsionada por el tiempo, es decir, que tiene un denominador de tiempo común?
¿Existen totales a nivel de sitio para cosas como time_read o posts_read_count?
Mucho más limpio que lo que tenía yo, lo cual en realidad funcionó una vez que agregué el .json.
Gracias de nuevo. ¡Estoy emocionado por empezar a usar estos datos!