كيف تعمل تتبع المشاركات في Discourse

مطور
1

تتبع منصة Discourse وقت القراءة لكل منشور يظهر للمستخدم على الشاشة. وقد تطور هذا النظام عبر السنوات، وأجد أنني غالبًا ما أحتاج إلى الرجوع إلى الكود لفهم كيفية عمله ولماذا وُجد.

يتناول هذا المنشور التفاصيل التقنية الصعبة للتطبيق الحالي.

كيف يتتبع عميل Discourse التوقيت

يتم تنفيذ تتبع توقيت المنشورات في screen-track.js.es6. هذا الوحدة مسؤولة عن تتبع المدة التي يقضيها المنشور على الشاشة، والمدة التي يقضيها الموضوع على الشاشة.

عندما يتم “تمرير” صفحة موضوع، فإنها تُعلم متتبع الشاشة بالمنشورات الموجودة في العرض، وأي من هذه المنشورات قد تم قراءتها. ونعتبر المنشورات التي تظهر جزئيًا في العرض بأنها “في العرض”.

ثم يقوم متتبع الشاشة بإطلاق “نقرة” كل ثانية لتحديد البيانات التي يجب إرسالها إلى الخادم.

سيحافظ متتبع الشاشة على عدة قوائم:

أ. قائمة من (المنشور/الوقت المقضي في قراءة المنشور) التي لم تُرسل إلى الخادم
ب. قائمة بالمنشورات التي نعرف أنها قد قُرأت
ج. قائمة بالمنشورات التي نعرف أنها حاليًا على الشاشة

في بداية كل “نقرة” (كل ثانية)، إذا كان لدينا منشورات في القائمة (أ)، فسننظر في إرسالها إلى الخادم:

  • إذا مرت إعدادات الموقع flush_timing_secs (الافتراضي 60 ثانية) منذ آخر مرة أرسلنا فيها بيانات إلى الخادم.

  • إذا كان أي من المنشورات “غير مقروء” من قبل المستخدم، فسنرسل القائمة كاملة فورًا.

في نهاية كل “نقرة”، إذا كان Discourse في حالة تركيز:

إذا كان لدينا أي “منشورات على الشاشة”، فسنعلم بـ “نقرة واحدة” من الوقت لكل منشور.

إذا غادرنا الموضوع في أي لحظة (ننتقل إلى مكان آخر في Discourse)

سنرسل فورًا إلى الخادم كل ما هو “في طور الإرسال” في القائمة (أ).

الحدود

  • في كل مرة تنظر فيها إلى موضوع، سنسجل الحد الأقصى لـ 6 دقائق من وقت القراءة لكل منشور (سيتم إعادة تعيين هذا عند التنقل بعيدًا ثم العودة إلى المنشور).

  • إذا مرت 3 دقائق دون أن تقوم بالتمرير على الإطلاق، فسنعطل هذا النظام الفرعي حتى يحدث تمرير مرة أخرى.

  • سنسجل التوقيت لما يصل إلى 5 مواضيع للمستخدمين المجهولين (يتم تحويل هذه البيانات عند تسجيل المستخدم إلى جدول posts_timing).

ملاحظة رئيسية

  1. على الرغم من أن جدول post_timings يتتبع الوقت بدقة تصل إلى المللي ثانية، إلا أننا نملك بين “0-1000 مللي ثانية” من الوقت “غير المسجل” لكل منشور، اعتمادًا على توقيت إطلاق “النقرة”.

  2. يمكن لكل “جلسة” من مشاهدة موضوع تسجيل ما يصل إلى 6 دقائق من وقت القراءة لكل منشور. ولا يوجد حد أقصى لوقت القراءة لكل منشور؛ إذ يمكن أن يُقرأ منشور لأيام إذا عاد المستخدم إلى الموضوع.

ماذا نفعل بهذه البيانات؟

أهم قطعة معلومات نستخدمها هي “هل قرأ المستخدم X المنشور Y”، وهذا يحدد عدد المنشورات غير المقروءة في الموضوع، بالإضافة إلى كميات هائلة من البيانات الحرجة الأخرى.

باستثناء الاستخدام الثنائي، نستخدم الوقت المسجل في post_timings لحساب avg_time للمنشور.

يتم حساب متوسط الوقت للمنشور كـ أس متوسط اللوغاريتم الطبيعي للوقت (أي المتوسط الهندسي).

على سبيل المثال:

المنشور 1: سام، 10 ثوانٍ
المنشور 2: جين، ساعة واحدة

avg_time = exp((log(3600000) + log(10000)) / 2)
=~ exp((15.09 + 9.2) / 2)
=~ 189094
=~ 189 ثانية

يُستخدم هذا avg_time بعد ذلك في حاسبة النقاط كـ مكون لـ “نقاط المنشور”.

النقاط = 5 * عدد الردود + 15 * نقاط الإعجاب + 5 * عدد الروابط الواردة + 2 * عدد الإشارات المرجعية + 0.05 * avg_time + 0.2 * عدد قراءات المنشور.

لذلك، في الحالة أعلاه، فإن 189 ثانية في المتوسط لقراءة منشور تعادل 37 نقطة. إذن… ما يعادل تقريبًا إعجابين ونص، أو 72 قراءة.

تُستخدم “نقاط المنشور” بعد ذلك في قسم “الأفضل” لتحديد أفضل المنشورات في موضوع معين.

24 إعجابًا
2

Isn’t this read data the backing store for these numbers, total read time?

image
image.png882×292 15 KB

image
image.png878×272 56 KB

image
image.png1883×608 90.4 KB

3 إعجابات
3

Yes the “topic read time” I will update the OP to explain about that, I touched on it very lightly.

The topic_users table has a column called total_msecs_viewed. This number is updated independent of post_timings in the same controller action. We can not “rebuild” that number from post timings cause we have no idea about overlapping times.

The “topic timing” piece has no 6 minute limit like post timing does. The number is flushed with the same post timing batch according to the same rules.

I think I was so focused on talking about post tracking that I missed out on explaining the topic tracking part.

4 إعجابات
4

Whoa… we do? Do we really need to do this? It feels unnecessary?

What do you mean by “overlapping times”?

إعجاب واحد (1)
5

I have not tested this recently, but yes the code is all there to do it. I guess it means you can get to TL1 a bit faster.

Say you we know about my timings:

Post 1: 10 seconds
Post 2: 12 seconds
Post 3: 17 seconds

The time I spent reading the topic can be anywhere between 17 seconds and 39 seconds.

So we can not use the data in the posts timing table to figure out what the number in topic users should be. So we are forced to track that other number independently.

It is not a huge deal and makes no big diff, but there is no way to “run an inventory” and check that the number in topic user is 100% correct.

3 إعجابات