MetricsDataPing: Difference between revisions

Jump to navigation Jump to search
m
Line 256: Line 256:
For simplicity, I will take the number of crashes (e.g. in the last week or overall) as data point that you want to gather. The data itself is anonymous and can (apart from fingerprinting, more to that later) not identify a single user.
For simplicity, I will take the number of crashes (e.g. in the last week or overall) as data point that you want to gather. The data itself is anonymous and can (apart from fingerprinting, more to that later) not identify a single user.


1. Avoiding UUID
== 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:
Line 283: Line 283:
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
== 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.
Confirmed users
596

edits

Navigation menu