What is /topics/timings ajax request for?


(lid) #1

I was curious for quite sometime to know what is the purpose of this ajax request

When the user is inside a topic the browser will initiate this request every few seconds.
/topics/timings

what does it do ? and how important is it?

@sam


(Sam Saffron) #2

It is there to keep track of read times, without it we don’t know what you read


(lid) #3

is it there for any other purposes? for example Analytic ?

I was observing its behavior, on a random topic and I got 33 server request in 1-2 minutes
with a minimum user interaction, no scrolling down the topic just staring at the first post.

it seem that the only content it post is:

timings[1]:5005
topic_time:5005
topic_id:17492

33 request without even scrolling down(timing parameter does change to random values 2000, 4005,5006 of sort)

So basically what you are saying is that the client tell the server 33 times that I read the first post.

When I scroll down it does add additional parameters, which now make more sense to me, the client tell the server that I just read that messages 2,3,4,5. and it know when (I am not sure what the 5005 number mean, is it the sample time? like 5 sec ago of this request?)

timings[2]:5005
timings[3]:5005
timings[4]:5005
timings[5]:5005
topic_time:5005
topic_id:17492

(Jeff Atwood) #4

We track how long every post is visible on your screen and how long you spent reading each one.

Make sense now?


(Sam Saffron) #5

There are a bunch of optimization see can apply to cut down Ajax reqs, though I don’t want to muck with this now


(lid) #6

So it is not just for a functional purpose tracking ( for example this post was read)
it is also collects analytical information, user spend x amount of time with post b on his screen.

is this data accessible for site owner to produce some sort of reports or this data is just saved in database in the meantime for the future use?

@codinghorror and @sam Thanks for the answers so for, It is starting to make more sense.

@sam I understand, just for future reference:

#####possible optimizations

  1. move timing reports to a subdomain purposed for analytics collection currently each request carry on an unnecessary cookie information that bloats the request. ( this probably going to complicate things and i am not sure how beneficial it is if the browser actually send the request as gzip, chrome for some reason does not show the final total request size including headers)

  2. aggregate analytical information on client side ( time spent on reading a post)

  3. post only high priority request immediately for example the first time the user read an unread post and remember that locally.

  4. instead of relying on time events or mouse events to post reports, use “milestones events” for example
    aggregate in local storage / internally statistics of a topic, when user switch to another topic (“milestone”) flush the report on the previous topic data.