Consumer: Los timestamp.lapse dan altísimos, no tienen en cuenta el context

[asanzo]

Problema: Hoy en el consumer muchos timestamps están dando un lapse entre comienzo y fin de experience MUY altos (~50 días, ~100 días).

Hipótesis: Les pibis agarran el mismo ejercicio en dos momentos (dos contexts) distintos.Es decir, puede haber comenzado a hacer un ejercicio, se fue a tomar la leche, y volvió a seguirlo haciendo. En el consumer, el buildExperience y el mergeExperiences sencillamente se encargan de encontrar el mínimo y el máximo valor de timestamp entre todos los trials. Entonces, estamos considerando como que estuvo haciendo el ejercicio más tiempo de lo que en realidad estuvo haciendo.

Forma ideal de arreglarlo: No se puede hacer un lapse restando tiempo de último trial con tiempo de primer trial.

• [ ] Queremos el verdadero tiempo que estuvo sentade resolviendo. El cálculo debería considerar los tiempos de inactividad. Esto es, si ordenamos cronológicamente los trials, y en un momento cambia el context, entonces hay que sacar el tiempo entre el "end" del trial del context A, y el "start" del trial del context siguiente. (Así considerando todos los posibles agujeros). Yo esto lo pondría en un valor aparte, un realWorkingLapse, o algo así.
• [ ] Queremos saber cuántas "sentadas" (contexts) le llevó resolver ese ejercicio. (idealmente agregaría un contextCount al experience)

[asanzo]

Dijimos que para el estudio actual nos alcanza con filtrar por sessionCount = 1, y ahí todos los valores se vuelven "verdaderos". Además, dejamos afuera las múltiples sesiones que sospechamos que son en su mayoría máquinas de uso por varias personas.

Por ahora no vamos a resolver este issue.