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؟ نحن لا نملك شيئًا مشابهًا في لوحة التحكم حتى الآن، أليس كذلك؟ هل هناك أي بيانات أخرى موجودة قد تساعدنا في التقاط المستخدمين من فئة “البريد الإلكتروني فقط”؟
ولترتيب مستخدم معين مقارنةً بمتوسط الموقع، هل توجد أي مكان يتم فيه تخزين الإجماليات لجميع المستخدمين؟
أخيرًا، في محاولة لفحص واجهة برمجة التطبيقات الخاصة بالعميل، أنا أراجع زيارات المستخدمين في لوحة التحكم، لكنني لا أستطيع جعل الروابط تعمل بالنسبة لي كما في أماكن أخرى، على سبيل المثال، هل يجب أن يعمل هذا؟
{{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 للحصول على تفاصيل حول كيفية حساب الوقت.
يمكنك إرسال طلبات واجهة برمجة التطبيقات للحصول على تقارير محددة. على سبيل المثال، يعمل هذا الطلب لتقرير زيارات المستخدمين:
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 إلى الرابط، وأن تُضاف معاملات الاستعلام start_date وend_date إلى الرابط.
مفيد جدًا وواضح. شكرًا لك @simon.
هل من العادل القول إن recent_time_read هو الإحصائية الوحيدة التي يمكن استخراجها عن مستخدم ولا تتأثر بالزمن، أي أن لها مقام زمني مشترك؟
هل توجد إجماليات على مستوى الموقع لأي شيء مثل time_read أو posts_read_count؟
أكثر نظافة مما كان لدي، والذي كان يعمل بالفعل بمجرد إضافة .json.
شكرًا مجددًا. متحمس للبدء في استخدام هذه البيانات!