MetricsDataPing: Difference between revisions

Jump to navigation Jump to search

MetricsDataPing (view source)

Revision as of 18:39, 1 February 2012

156 bytes added ,  1 February 2012
m
→‎Anonymous alternative: formatting
Line 257: Line 257:


1. Avoiding UUID
1. Avoiding UUID
So, now you wanted to know which profiles are not used anymore (dormant, retention problem) and which characteristics they have. This is inherently difficult, but it is possible with the following algo:
So, now you wanted to know which profiles are not used anymore (dormant, retention problem) and which characteristics they have. This is inherently difficult, but it is possible with the following algo:


You submit:
You submit:


    Age of profile (Firefox installation) in days - e.g. 500
* Date of last submission - e.g. 2012-01-18
    Date of last submission - e.g. 2012-01-18
* Current date (from client perspective) - only date, not time - e.g. 2012-01-20
    Current date (from client perspective) - only date, not time - e.g. 2012-01-20
* Age of profile (Firefox installation) in days - e.g. 500
    Number of crashes - e.g. 15
* (Last submitted age is implied - e.g. 498)
    Number of crashes submitted last time - e.g. 10
* Number of crashes - e.g. 15
* Number of crashes submitted last time - e.g. 10


Then, on the server, you write that information in a database, as such:
Then, on the server, you write that information in a database, as such:
Date of submission | Age of installation | Crash count | Number of users
Date of submission | Age of installation | Crash count | Number of users
2012-01-20 | 500 | 15 | 100000
2012-01-20         | 500                 | 15         | 100000
Any additional user also submitting today the same combination "age 500, crash count 15" increases the "number of users" column by 1.
Any additional user also submitting today the same combination "age 500, crash count 15" increases the "number of users" column by 1.
Also, you look up the row for the last submission, namely
Also, you look up the row for the last submission, namely
2012-01-18 | 498 | 10 | 20001
2012-01-18         | 498                 | 10         | 20001
and decrease the number of users by 1.
and decrease the number of users by 1.


If the user decides that there were too many crashes and switches to Chrome, he will be stranded on the row "2012-01-20 | 500 | 15 | 5000", because users who have continued to use FF have been subtracted already. So, you can say with certainty that there were 5000 users who used Firefox the last time on 2012-01-20, after having used Firefox for 500 days, and they had 15 crashes (per day/week, whatever you submit) when they stopped using Firefox.
If the user on that day decides that there were too many crashes and switches to Chrome, he will now be stranded on the row
2012-01-20         | 500                 | 15         | 5000
because users who have continued to use FF have been subtracted already. So, you can say with certainty that there were 5000 users who used Firefox the last time on 2012-01-20, after having used Firefox for 500 days, and they had 15 crashes (per day/week, whatever you submit) when they stopped using Firefox.


As you told me, that is exactly the information you are so desperately seeking. Dere, you has it. Without tracking any individual user, it's completely anonymous.
As you told me, that is exactly the information you are so desperately seeking. Dere, you has it. Without tracking any individual user, it's completely anonymous.


2. Avoiding Fingerprinting.
2. Avoiding Fingerprinting


Now, what about all the other information that you need: startup times, addons, etc.? If we just add all that information to the same table and row, it would allow fingerprinting. But that is not necessary. You merely make one table per atomic information. I.e.
Now, what about all the other information that you need: startup times, addons, etc.? If we just add all that information to the same table and row, it would allow fingerprinting. But that is not necessary. You merely make one table per atomic information. I.e.
Table A
Table A
Date of submission | Age of installation | Crash count | Number of users
Date of submission | Age of installation | Crash count | Number of users
Table B
Table B
Date of submission | Age of installation | startuptime | Number of users
Date of submission | Age of installation | Startup time | Number of users
or of course whatever other database schema you want, as long as each value is separate. That takes care of the fingerprinting.
or of course whatever other database schema you want, as long as each value is separate. That takes care of the fingerprinting.


At least on the server side, not on the submission side. I would have to trust you, and anything between you and me. It would be possible to separate the calls and submit each value separately, but I think that would be overdoing it.
At least on the server side, not on the submission side. I would have to trust you, and anything between you and me. It would be possible to separate the calls and submit each value separately, but I think that would be overdoing it.
BenB
Confirmed users
596

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/393007"

Navigation menu