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

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.

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.

: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.

Closing since this was delivered in the Hello dashboard. (fortnightly recurring users was dropped as a requirement)