Bugzilla

Ideally, we want the measurement to allow us to answer three questions:

1. How many cards are stored? In the original spec this would be conveyed by the sum of the histogram's values (height of the bins).
2. How many times the cards that are stored have been used (this was conveyed by the value of the bin labels).
3. How many total uses there has been across all cards (sum-product of 1 and 2). 

We don't care about having a stable ID of each card over time, we just want to know how many cards there are, and among all cards, how often they were used. For example, if usage bin 2 had 4 cards (value of 4) and bin 3 had 0 cards ( histogram looks like { 2:4, 3:0 } ) and one card is used once, then we now have { 2:3, 3:1 }. We don't care about *which* card moved over to  bin 3. 

In this scheme, we know how many cards are stored (sum of values: 4), how many times the cards were used (3 cards were used twice, once card was used three times), and how many total usages there were (sum of the products, (2*3) + (3*1) = 9). 

[Here is an example of a histogram that works in a similar way](https://probes.telemetry.mozilla.org/?search=pwmgr&view=detail&probeId=histogram%2FPWMGR_LOGIN_LAST_USED_DAYS). IIRC the bin labels here are number of days and the values are the number of logins that were used that many days ago. 

We could break up the measurements. For example, have a scalar for number of cards stored, another scalar for total uses across all cards. That would cover 1 and 3. But it won't describe *the distribution* of card usage (2). We would like to have that, since we may want to know if users are storing a lot of cards and using only a handful frequently, or spreading their usage across all of them. 

I think you are right that you would have to re-write the histogram values after each card usage (you can't just increment after each usage). LMK if that causes problems. I am also OK if we don't handle card deletion. We want the full usage history, so I'm ok if cards continue to count to the histogram even after they are removed (they will just be stuck in one bin forever).

I'm trying to get my head around if option 1 would cover 1-3 above. I think it might, but I could use your opinion there. At first glace it seems a bit more cumbersome to have many scalars rather than a single histogram, but if there are technical reasons to do so let me know. I think option 2 might not cover (1) in the case of a tie in usage. 

Hopefully that made things more clear. I could be missing something - let me know.

Ideally, we want the measurement to allow us to answer three questions:

1. How many cards are stored? In the original spec this would be conveyed by the sum of the histogram's values (height of the bins).
2. How many times the cards that are stored have been used (this was conveyed by the value of the bin labels).
3. How many total uses there has been across all cards (sum-product of 1 and 2). 

We don't care about having a stable ID of each card over time, we just want to know how many cards there are, and among all cards, how often they were used. For example, if usage bin 2 had 4 cards (value of 4) and bin 3 had 0 cards ( histogram looks like { 2:4, 3:0 } ) and one card is used once, then we now have { 2:3, 3:1 }. We don't care about *which* card moved over to  bin 3. 

In this scheme, we know how many cards are stored (sum of values: 4), how many times the cards were used (3 cards were used twice, once card was used three times), and how many total usages there were (sum of the products, (2\*3) + (3\*1) = 9). 

[Here is an example of a histogram that works in a similar way](https://probes.telemetry.mozilla.org/?search=pwmgr&view=detail&probeId=histogram%2FPWMGR_LOGIN_LAST_USED_DAYS). IIRC the bin labels here are number of days and the values are the number of logins that were used that many days ago. 

We could break up the measurements. For example, have a scalar for number of cards stored, another scalar for total uses across all cards. That would cover 1 and 3. But it won't describe *the distribution* of card usage (2). We would like to have that, since we may want to know if users are storing a lot of cards and using only a handful frequently, or spreading their usage across all of them. 

I think you are right that you would have to re-write the histogram values after each card usage (you can't just increment after each usage). LMK if that causes problems. I am also OK if we don't handle card deletion. We want the full usage history, so I'm ok if cards continue to count to the histogram even after they are removed (they will just be stuck in one bin forever).

I'm trying to get my head around if option 1 would cover 1-3 above. I think it might, but I could use your opinion there. At first glace it seems a bit more cumbersome to have many scalars rather than a single histogram, but if there are technical reasons to do so let me know. I think option 2 might not cover (1) in the case of a tie in usage. 

Hopefully that made things more clear. I could be missing something - let me know.

Ideally, we want the measurement to allow us to answer three questions:

1. How many cards are stored? In the original spec this would be conveyed by the sum of the histogram's values (height of the bins).
2. How many times the cards that are stored have been used (this was conveyed by the value of the bin labels).
3. How many total uses there has been across all cards (sum-product of 1 and 2). 

We don't care about having a stable ID of each card over time, we just want to know how many cards there are, and among all cards, how often they were used. For example, if usage bin 2 had 4 cards (value of 4) and bin 3 had 0 cards ( histogram looks like { 2:4, 3:0 } ) and one card is used once, then we now have { 2:3, 3:1 }. We don't care about *which* card moved over to  bin 3. 

In this scheme, we know how many cards are stored (sum of values: 4), how many times the cards were used (3 cards were used twice, once card was used three times), and how many total usages there were (sum of the products, (2\*3) + (3\*1) = 9). 

[Here is an example of a histogram that works in a similar way](https://probes.telemetry.mozilla.org/?search=pwmgr&view=detail&probeId=histogram%2FPWMGR_LOGIN_LAST_USED_DAYS). IIRC the bin labels here are number of days and the values are the number of logins that were used that many days ago. 

We could break up the measurements. For example, have a scalar for number of cards stored, another scalar for total uses across all cards. That would cover 1 and 3. But it won't describe *the distribution* of card usage (2). We would like to have that, since we may want to know if users are storing a lot of cards and using only a handful frequently, or spreading their usage across all of them. 

I think you are right that you would have to re-write the histogram values after each card usage (you can't just increment after each usage). LMK if that causes problems. I am also OK if we don't handle card deletion. We want the full usage history, so I'm ok if cards continue to count to the histogram even after they are removed (they will just be stuck in one bin forever). If they need to drop out of the histogram, I guess that's OK too.

I'm trying to get my head around if option 1 would cover 1-3 above. I think it might, but I could use your opinion there. At first glace it seems a bit more cumbersome to have many scalars rather than a single histogram, but if there are technical reasons to do so let me know. I think option 2 might not cover (1) in the case of a tie in usage. 

Hopefully that made things more clear. I could be missing something - let me know.