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.
Sarebbe interessante identificare gli utenti che visitano il sito rispetto a quelli che rispondono ai post solo tramite email.
Un buon indicatore potrebbe essere qualcosa come time_read / post_count? Al momento non abbiamo nulla di simile nella dashboard, giusto? Ci sono altri dati esistenti che potrebbero aiutarci a catturare gli utenti “solo email”?
Per confrontare un determinato utente con la media del sito, esiste un luogo in cui sono archiviati i totali per tutti gli utenti?
Infine, mentre cerco di esaminare l’API del client, sto guardando le visite degli utenti nella dashboard, ma non riesco a far funzionare gli URL come in altri contesti. Ad esempio, dovrebbe funzionare questo?
{{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
Oltre alle tre domande sopra riportate, qualcuno può confermare se time_read ESCLUDE l’attività proveniente dalla posta elettronica?
time_read non include il tempo che un utente potrebbe aver dedicato alla lettura delle email inviate dal sito. Il suo valore viene calcolato in base al tempo che l’utente ha trascorso con i topic aperti sullo schermo. Per ulteriori dettagli su come viene calcolato il tempo, consulta How does post tracking work in Discourse.
Puoi effettuare richieste API per ottenere rapporti specifici. Ad esempio, questa richiesta funziona per il rapporto sulle visite utente:
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;"
Anche le richieste all’endpoint /admin/reports/bulk.json dovrebbero funzionare. Assicurati di aggiungere .json all’URL e di includere i parametri di query start_date e end_date nell’URL.
Molto utile e chiarificatore. Grazie @simon.
Si può dire che recent_time_read sia l’unica statistica che si può estrarre su un utente senza essere distorta dal tempo, ovvero che abbia un denominatore temporale comune?
Esistono totali a livello di sito per qualcosa come time_read o posts_read_count?
Molto più pulito di quello che avevo, che in realtà ha funzionato non appena ho aggiunto .json.
Grazie ancora. Non vedo l’ora di iniziare a utilizzare questi dati!