See also http://bugzilla.mozilla.org/show_bug.cgi?id=1187054 I believe there is ongoing controversy about whether active ticks has any value at all, but I thought I had heard that it was much improved a while back. Looking at activeTicks values ("payload/simpleMeasurements/activeTicks") in even a tiny bit of v4 data, I am concerned about what activeTicks is measuring and if it's doing so correctly (see http://gist.github.com/bcolloran/323eeea11de94ca8b2dc ) First, as described in bug 1187054, the activeTicks value reported for each subsession should be *only* those active ticks that occur during that subsession, not a cumulative total. The values for activeTicks do not necessarily grow monotonically (as is the case for totalTime), but they do appear to trend strongly positive, which makes me wonder if the implementation intended for this to be cumulative but some weirdness in activeTicks undermined that attempt. And just more generally, the data looks suspicious -- there are all kinds of repeated values, and things that look like oscillation between two trends... it's a mess. I'd like folks to weigh in on what the intended implementation for this field is supposed to do and whether these numbers look in line with that intent.

(In reply to brendan c from comment #0) > See also http://bugzilla.mozilla.org/show_bug.cgi?id=1187054 > > I believe there is ongoing controversy about whether active ticks has any > value at all, but I thought I had heard that it was much improved a while > back. Not as far as i know - bug 1096498, bug 506815, bug 1107782, ... > First, as described in bug 1187054, the activeTicks value reported for each > subsession should be *only* those active ticks that occur during that > subsession, not a cumulative total. The values for activeTicks do not > necessarily grow monotonically (as is the case for totalTime), but they do > appear to trend strongly positive, which makes me wonder if the > implementation intended for this to be cumulative but some weirdness in > activeTicks undermined that attempt. > > And just more generally, the data looks suspicious -- there are all kinds of > repeated values, and things that look like oscillation between two trends... > it's a mess. > > I'd like folks to weigh in on what the intended implementation for this > field is supposed to do and whether these numbers look in line with that > intent. activeTicks should be properly reset per subsession. Yes, that measurement seems pretty broken, i think the best thing we can do here is accumulate & cross-check with FHR & "saved-session" data.

Any updates on this Georg?

There is nothing directly actionable for me here and i don't think i have time for a detailed data review here. Bug 1128491 tracks resetting those kind of things per subsession. Any specific quality issues should be filed against bug 1105864 (like bug 1107782).

From summary of bug 1228368: "Data analyses have been avoiding activeTicks because of its unreliability. Bugs like bug 506815 and bug 1107779 and bug 1107782 have aimed to improve it. But is activeTicks now accurate and reliable? Maybe write an extension to change the look of the chrome to indicate whether or not it's active? Then anyone can install it and watch for indicators that they're more/less active than expected. Crowd-source it." I plan on writing such an add-on and soliciting and collating data.

I've written an add-on, and early testing on latest 45 is hopeful. It's still a little _too_ active because... well, here's an example: A user moves her mouse over the Browser. Generally we consider this to be activity (though, if the window is in the background, maybe we shouldn't?). The problem is we get two user-interaction-active events out of it, one up to 5s after the gesture. Like so: eMouseMove => fire user-interaction-active. Start user-interaction-inactive 5s timer. gMouseOrKeyboardEventCounter++ eMouseMove gMouseOrKeyboardEventCounter++ eMouseMove gMouseOrKeyboardEventCounter++ eMouseMove gMouseOrKeyboardEventCounter++ . 5s pass => fire user-interaction-active because gMouseOrKeyboardEventCounter != mPreviousCount . 5s pass => fire user-interaction-inactive because gMouseOrKeyboardEventCounter == mPreviousCount So, there's a bug in that we probably ought not to be firing that second user-interaction-active. It means one extra u-i-a, and at least 5 seconds' delay before we register u-i-i. Not the end of the world, but something I ought to be able to fix.

(In reply to Chris H-C :chutten from comment #6) > A user moves her mouse over the Browser. Generally we consider this to be > activity (though, if the window is in the background, maybe we shouldn't?). That is a good question, it depends on what we want to measure: * active user interaction with the browser or * user activity that triggers browser activity (seems to happen now?) I'd be interested in clearing this question up as we want to decide early next year whether activeTicks is now a useful/reliable measure for metrics and modeling user engagement/activity/... The addon looked very useful by the way, would be nice to have an email sent around to fhr-dev about it when you consider it stable? :)

I'm okay with the measure as it stands, especially since it is easy to state: Any event generated by a user that could interact with content or chrome during a 5-second window will generate an active tick. (plus one as noted above (which I'm not going to fix because the added complexity isn't worth it)). It isn't measuring whether the user is looking at or _intending_ to interact with web content or the chrome... but without mind-reading, there is no way to know that so I presume we don't want to try.

activeTicks appears to be a legitimate measure at this juncture. To see for yourself, feel free to install `statuser` from http://mzl.la/1k0FxJh It is a red square when the user is active, a blue circle when the user is inactive, rotating when the page is loading, and has a counter than increments every time there's a thread hang > 126ms on gecko's main thread. Clicking the icon resets the counter.