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.
Nous souhaitons identifier les utilisateurs qui visitent le site par rapport à ceux qui répondent uniquement aux publications par e-mail.
Un bon indicateur serait-il quelque chose comme temps_lu / nombre_de_publications ? Nous n’avons pas encore de fonctionnalité de ce type dans le tableau de bord, n’est-ce pas ? Existe-t-il d’autres données disponibles qui pourraient nous aider à capturer les utilisateurs « e-mail uniquement » ?
Pour comparer un utilisateur donné à la moyenne du site, les totaux pour tous les utilisateurs sont-ils stockés quelque part ?
Enfin, en examinant l’API client, je consulte les visites d’utilisateurs dans le tableau de bord, mais je n’arrive pas à faire fonctionner les URL comme ailleurs. Par exemple, cela devrait-il fonctionner ?
{{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
En dehors de mes trois questions ci-dessus, quelqu’un peut-il confirmer si time_read EXCLUT bien les activités provenant des e-mails ?
time_read n’inclut pas le temps qu’un utilisateur peut avoir passé à lire les e-mails envoyés depuis le site. Sa valeur est calculée en fonction du temps que l’utilisateur a passé avec des sujets ouverts à l’écran. Consultez How does post tracking work in Discourse pour plus de détails sur le calcul de ce temps.
Vous pouvez effectuer des requêtes API pour obtenir des rapports spécifiques. Par exemple, cette requête fonctionne pour le rapport des visites d’utilisateurs :
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;"
Les requêtes vers le point de terminaison /admin/reports/bulk.json devraient également fonctionner. Assurez-vous d’ajouter .json à l’URL et que les paramètres de requête start_date et end_date sont bien inclus dans l’URL.
Très utile et éclairant. Merci @simon.
Peut-on dire que recent_time_read est la seule statistique que l’on peut extraire sur un utilisateur qui n’est pas faussée par le temps, c’est-à-dire qui a un dénominateur temporel commun ?
Existe-t-il des totaux au niveau du site pour des éléments comme time_read ou posts_read_count ?
Beaucoup plus propre que ce que j’avais, ce qui a en fait fonctionné une fois que j’ai ajouté le .json.
Merci encore. J’ai hâte de commencer à utiliser ces données !