131
edits
MetricsDataPing: Difference between revisions
Jump to navigation
Jump to search
no edit summary
m (→What to avoid) |
DEinspanjer (talk | contribs) No edit summary |
||
| Line 18: | Line 18: | ||
*We want to acquire representative data and analyze it for the ‘de-averaged’ benefit of multiple but still large sub-populations of users | *We want to acquire representative data and analyze it for the ‘de-averaged’ benefit of multiple but still large sub-populations of users | ||
*Each subpopulation requires insights and actions that are not of the ‘one size fits all’ variety <br> | *Each subpopulation requires insights and actions that are not of the ‘one size fits all’ variety <br> | ||
There is a section in the discussion page for the topic of opt-out:<br>[[Talk:MetricsDataPing#Opinions_from_User:BenB]]<br>That opinion and discussion is also included below. | |||
'''What difference does it make for the user''' | '''What difference does it make for the user''' | ||
| Line 35: | Line 37: | ||
The list and definitions of data elements in the Metrics Ping is here [https://metrics.etherpad.mozilla.org/ep/pad/view/ro.9$yFtH/latest MDP Data Point Descriptions] | The list and definitions of data elements in the Metrics Ping is here [https://metrics.etherpad.mozilla.org/ep/pad/view/ro.9$yFtH/latest MDP Data Point Descriptions] | ||
== | == Document Identifier Strategy == | ||
Each profile will generate a UUID to be used as the document key. Each day's submission will use that UUID, and this will also be the key for that profile's cumulative data on the server. When each submission is received, the server merges it on the fly with the cumulative data, not persisting the individual documents. | |||
' | When it is time to submit data, the client will collect the latest data and append it to the cumulative view of the data stored locally in the Profile directory. The client will then generate a new document ID for this submission and post it to the data.mozilla.com service along with a header indicating the previously submitted document ID. On the server side, the previous document ID is used to delete that document, and the new document is stored with the new ID. If the server returns a success response to the client, the client saves the ID of the document just submitted as the previous document ID. If the client does not receive a success response, it will attempt to submit later using the same two document IDs. This makes sure that we don't leave old data for the installation hanging around. | ||
There is a section in the discussion page for the topic of the old UUID strategy originally proposed:<br>[[Talk:MetricsDataPing#Update_from_User:DEinspanjer]]<br>[[Talk:MetricsDataPing#Opinions_from_User:BenB_2]]<br> | |||
That opinion and discussion is also included below. | |||
=== Privacy === | === Privacy === | ||