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.
Interessiert daran, Benutzer zu identifizieren, die die Site besuchen, im Vergleich zu Benutzern, die nur auf Beiträge per E-Mail antworten.
Wäre eine gute Metrik etwas wie time_read / post_count? Wir haben noch nichts Ähnliches im Dashboard, oder? Gibt es andere vorhandene Daten, die uns helfen könnten, “nur E-Mail”-Benutzer zu erfassen?
Um einen bestimmten Benutzer im Vergleich zum Site-Durchschnitt zu bewerten, werden die Gesamtwerte für alle Benutzer irgendwo gespeichert?
Schließlich, beim Versuch, die Client-API zu untersuchen, schaue ich mir die Benutzerbesuche im Dashboard an, kann aber die URLs nicht wie an anderen Stellen zum Laufen bringen. Sollte dies funktionieren?:
{{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
Abgesehen von meinen drei obigen Fragen: Kann jemand bestätigen, dass time_read Aktivitäten, die per E-Mail hereinkommen, NICHT einschließt?
time_read enthält nicht die Zeit, die ein Benutzer möglicherweise mit dem Lesen von E-Mails verbracht hat, die von der Website gesendet wurden. Der Wert wird basierend auf der Zeit berechnet, die der Benutzer mit geöffneten Themen auf dem Bildschirm verbracht hat. Weitere Einzelheiten zur Berechnung der Zeit finden Sie unter How does post tracking work in Discourse.
Sie können API-Anfragen stellen, um bestimmte Berichte abzurufen. Zum Beispiel funktioniert diese Anfrage für den Benutzerbesuchs-Bericht:
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;"
Auch Anfragen an den Endpunkt /admin/reports/bulk.json sollten funktionieren. Stellen Sie sicher, dass Sie .json an die URL anhängen und die Abfrageparameter start_date und end_date zur URL hinzugefügt werden.
Sehr hilfreich und klärend. Danke, @simon.
Ist es zutreffend zu sagen, dass recent_time_read die einzige Statistik ist, die man über einen Nutzer abrufen kann, die nicht durch die Zeit verzerrt ist, also einen gemeinsamen Zeit-Nenner hat?
Gibt es siteweite Gesamtwerte für Dinge wie time_read oder posts_read_count?
Viel sauberer als meine Lösung, die tatsächlich funktionierte, sobald ich .json hinzugefügt hatte.
Nochmals vielen Dank. Ich freue mich darauf, diese Daten zu nutzen!