Closed Bug 1036069 Opened 10 years ago Closed 9 years ago

Loop recurring users (json output)

Categories

(Cloud Services :: Operations: Metrics/Monitoring, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kparlante, Assigned: whd)

References

Details

(Whiteboard: [qa-])

For the loop dashboard we need:

- Weekly recurring users
- Fortnightly recurring users
- Monthly recurring users

We'd like a FxOS segmentation for each of these (based on user agent). 

We're defining recurring users as unique uids that occur both within the given time period as well as the preceding time period.

Server logging work going on here: https://github.com/mozilla-services/loop-server/pull/131
Summary: Loop recurring users heka filter & output → Loop recurring users heka filter
Whiteboard: [qa+]
Depends on: 1046236
Although this can be done Heka, it is impractical to keep a list (actually many bloom filters) of the last two months of active users in the real-time monitoring system with an ever growing memory requirement.  It should be calculated once a week from a data warehouse.
Repeated information, same as total bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1036551):

The current plan is to track total unique uid's that are involved in successful calls, as will be logged here: https://bugzilla.mozilla.org/show_bug.cgi?id=1046236.

In the meantime, we can count unique uids on all endpoints, as we are doing with daily active users.

Timeframe: My understanding is that Loop is planned for FF33, which goes to Beta on 2014-09-02 and release on 2014-10-14. It would be great to have this up and running for Beta.
Summary: Loop recurring users heka filter → Loop recurring users (json output)
Blocks: 1052152
Whiteboard: [qa+] → [qa-]
For the record, the current plan for these numbers is to look at:
- unique uid's on the "GET /calls" (no token in url) endpoint
- correlated with successful call setup, by linking "callid" from "GET /calls" to a call.setup success (on the same day)
- filter out empty UA (non standard user agents, under the assumption they indicate load testing)

To complete the plan, we need two server logging changes to be deployed:
- log the method in the request.summary: https://github.com/mozilla-services/loop-server/pull/180
- log the call state: https://github.com/mozilla-services/loop-server/pull/186

In the meantime, its good enough to just look at "/calls" endpoints with a uid.
Depends on: 1074468
:whd, the extra callid logging just landed on production: https://bugzilla.mozilla.org/show_bug.cgi?id=1074468 

Two refinements from the original plan:
- The callid is being logged on "POST /calls" and "POST /calls/<token>"
- "POST /calls/<token>" has a "calleeId", which we want to treat like a uid

I believe the current logic looks at both GET and POST /calls. We're going to end up only counting one user, essentially the one initiating the call. That matches the original ask, so lets go with that.
Assignee: mtrinkala → whd
Closing since this was delivered in the Hello dashboard. (fortnightly recurring users was dropped as a requirement)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.