Kibana query to report active weekly, bi-weekly or monthly desktop client users

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: RT, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

User Story

A "Recurring user" is a desktop client user who has participated in at least one call or have been in a room with another user, per time period, 2 periods in a row.
Comment hidden (empty)
(Reporter)

Updated

4 years ago
Blocks: 1105994
User Story: (updated)
(Reporter)

Updated

4 years ago
User Story: (updated)
Summary: Loop dashboard "Recurring callers" needs to include room usage → Kibana query to report active weekly, bi-weekly or monthly desktop client users

Comment 1

4 years ago
Romain, how long do they need to have been in a room with another user for the call to count as "successful"?
Flags: needinfo?(rtestard)
(Reporter)

Comment 2

4 years ago
I think we want here to report calls technically successful where both peers have the opportunity to communicate if they want to (we then have another bug for call duration distribution) - I mean by that no minimal duration.

That said I am not sure which events you are basing your reports on and if these events are a true reflection of "2 users in a room concurrently". There may be timeout values that we need to take into account to consider that both peers have had a chance to be in a room - Mark/Alexis is there such timeout we should consider to be guaranteed that if 2 peers have been together in a room for X seconds it means that technically the call was successful?
Flags: needinfo?(standard8)
Flags: needinfo?(rtestard)
Flags: needinfo?(alexis+bugs)
(In reply to Romain Testard [:RT] from comment #2)
> That said I am not sure which events you are basing your reports on and if
> these events are a true reflection of "2 users in a room concurrently".
> There may be timeout values that we need to take into account to consider
> that both peers have had a chance to be in a room - Mark/Alexis is there
> such timeout we should consider to be guaranteed that if 2 peers have been
> together in a room for X seconds it means that technically the call was
> successful?

Currently the messages we get are:

- Room Join
- Room Refresh (iirc every 5 mins * 0.9 - the factor is inserted by the client to ensure we hit the refresh time)
- Room Leave

These will be received one set per user.

If there's no room leave after 5 minutes from a join or refresh, then the user crashed or had some other issue. We don't know at which part in that 5 minutes it happened.

Obviously to determine if two people are in the room at the same time, we need to analyse individual room tokens for when the room join -> room leave period for two users overlaps.
Flags: needinfo?(standard8)
(Reporter)

Comment 4

4 years ago
(In reply to Mark Banner (:standard8) from comment #3)
> (In reply to Romain Testard [:RT] from comment #2)
> > That said I am not sure which events you are basing your reports on and if
> > these events are a true reflection of "2 users in a room concurrently".
> > There may be timeout values that we need to take into account to consider
> > that both peers have had a chance to be in a room - Mark/Alexis is there
> > such timeout we should consider to be guaranteed that if 2 peers have been
> > together in a room for X seconds it means that technically the call was
> > successful?
> 
> Currently the messages we get are:
> 
> - Room Join
> - Room Refresh (iirc every 5 mins * 0.9 - the factor is inserted by the
> client to ensure we hit the refresh time)
> - Room Leave
> 
> These will be received one set per user.
> 
> If there's no room leave after 5 minutes from a join or refresh, then the
> user crashed or had some other issue. We don't know at which part in that 5
> minutes it happened.
> 
> Obviously to determine if two people are in the room at the same time, we
> need to analyse individual room tokens for when the room join -> room leave
> period for two users overlaps.

Thanks.

A = Count of overlaps when 2 peers have joined a room before the other peer leaves
B = Count of instances where 2 peers are in a room and one or 2 peers never left it OR one or 2 peers never generated a refresh

Valid count of room conversations = A - B

Sounds right?
On the server side, we know normally when a user joins and when a user leaves. This should be enough to find out how long 2 users where around.

Katie, do you agree on that?
Flags: needinfo?(alexis+bugs) → needinfo?(kparlante)

Comment 6

4 years ago
(In reply to Alexis Metaireau (:alexis) from comment #5)
> On the server side, we know normally when a user joins and when a user
> leaves. This should be enough to find out how long 2 users where around.
> 
> Katie, do you agree on that?

Yes, we can track when a user joins/leaves, but we also need to count the case where we never see a leave event. In that case, perhaps we want to compare join/last refresh. We might be able to do this fairly easily with current logs using the heka sessionization stuff. 

For this case (recurring users) we're using the "participants" logging (
https://bugzilla.mozilla.org/show_bug.cgi?id=1124371). I do think we should be measuring the times ourselves as well (separate bug).
Flags: needinfo?(kparlante)

Comment 7

4 years ago
Here's a bug for doing something to collect/process that timing information: https://bugzilla.mozilla.org/show_bug.cgi?id=1126801

Comment 8

3 years ago
Reopen if necessary.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.