¿Cómo funciona el seguimiento de publicaciones en Discourse?

Discourse rastrea el tiempo de lectura para cada publicación que los usuarios ven en la pantalla. Este sistema ha evolucionado a lo largo de los años y a menudo necesito volver al código para entender cómo funciona y por qué existe.

Esta publicación cubre los dolorosos detalles técnicos de la implementación actual.

Cómo el cliente de Discourse rastrea el tiempo

El rastreo del tiempo de las publicaciones se implementa en screen-track.js.es6. Este módulo es responsable de rastrear cuánto tiempo ha estado una publicación en la pantalla y cuánto tiempo ha estado el tema en la pantalla.

Cuando una página de tema “se desplaza”, informa al rastreador de pantalla qué publicaciones tiene en vista Y cuáles de estas publicaciones se han leído. Consideramos que las publicaciones parcialmente visibles están “en vista”.

El rastreador de pantalla luego emite un “tic” cada segundo que decide qué datos deben enviarse al servidor.

El rastreador de pantalla mantendrá el seguimiento de varias listas.

a. Una lista de (publicación/tiempo dedicado a leer la publicación) que no se ha enviado al servidor
b. Una lista de publicaciones que sabemos que se leyeron
c. Una lista de publicaciones que sabemos que están en la pantalla en este momento

Al inicio de un tic (cada segundo), si tenemos publicaciones en (a), consideraremos enviarlas al servidor:

  • Si la configuración del sitio flush_timing_secs (valor predeterminado: 60 segundos) ha pasado desde la última vez que enviamos datos al servidor.

  • Si alguna de las publicaciones es “no leída” por el usuario, enviaremos toda la lista de inmediato.

Al final de un tic, si Discourse tiene el foco:

Si tenemos alguna “publicación en la pantalla”, registraremos “1 tic” de tiempo para cada publicación.

En cualquier momento en que salgamos del tema (naveguemos a otro lugar en Discourse)

Enviaremos todo lo que esté “en tránsito” en (a) al servidor de inmediato.

Límites

  • Cada vez que ves un tema, registraremos un máximo de 6 minutos de tiempo de lectura por publicación (esto se reinicia si te alejas y regresas a la publicación).

  • Si pasan 3 minutos y no te has desplazado en absoluto, desactivamos este subsistema hasta que haya desplazamiento nuevamente.

  • Registraremos el tiempo para hasta 5 temas para usuarios anónimos (lo cual se convierte en datos en la tabla posts_timing cuando el usuario se registra).

Observación clave

  1. Aunque la tabla post_timings registra hasta el milisegundo, tenemos entre “0-1000 ms” de tiempo “no registrado” por publicación, dependiendo de cuándo se active el tic.

  2. Cada “sesión” de ver un tema puede registrar hasta 6 minutos de tiempo de lectura por publicación. No hay un límite superior en el tiempo de lectura por publicación; una publicación puede ser leída durante días por un usuario si este regresa al tema.

¿Qué hacemos con estos datos?

La pieza de información más crítica que utilizamos es “¿el usuario X leyó la publicación Y?”, lo cual determina los conteos de no leídos en el tema y una gran cantidad de otros datos críticos.

Excepto por el uso binario, utilizamos el tiempo registrado en post_timings para calcular avg_time para una publicación.

El tiempo promedio para una publicación se calcula como el exponencial del promedio del logaritmo natural del tiempo (también conocido como media geométrica).

Por ejemplo:

Publicación 1: sam, 10 segundos
Publicación 2: jane, 1 hora

avg_time = exp((log(3600000) + log(10000)) / 2)
=~ exp((15.09 + 9.2) / 2)
=~ 189094
=~ 189 segundos

Este avg_time se utiliza luego en el calculador de puntuación como un componente para la “puntuación de la publicación”.

Puntuación = 5 * número de respuestas + 15 * puntuación de “me gusta” + 5 * número de enlaces entrantes + 2 * número de marcadores + 0.05 * avg_time + 0.2 * lecturas de la publicación.

Por lo tanto, en el caso anterior, 189 segundos de lectura promedio de una publicación se traducen en 37 puntos. Entonces… aproximadamente 2 “me gusta” y un poco más. O 72 lecturas.

La “puntuación de la publicación” se utiliza luego en “lo mejor de” para determinar cuáles son las mejores publicaciones en un tema.

24 Me gusta

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

3 Me gusta

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 Me gusta

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

What do you mean by “overlapping times”?

1 me gusta

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 Me gusta