Add scalars to "deletion-request" ping
Categories
(Toolkit :: Telemetry, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox74 | --- | fixed |
People
(Reporter: chutten, Assigned: chutten)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
We did too good of a job keeping our datasets separate, which means we can't find out all the Telemetry we have on a profile from just its client_id
. This means we need to send more than one id in the "deletion-request" ping so we can delete it all.
Let's do this via Scalars. The "deletion-request" ping can snapshot a "deletion-request" store which would be full of all the Telemetry ids we can't link to the client_id
. In the event of a deletion request, we'll then have everything we need in one place.
Assignee | ||
Comment 1•5 years ago
|
||
In thinking about what format the payload should take.... :frank, is there a benefit to adopting the payload.processes.[processname].scalars
approach from the "main" ping? Will that help on the server side?
The payload can be anything we want it to be at this stage.
Assignee | ||
Updated•5 years ago
|
Comment 2•5 years ago
|
||
In thinking about what format the payload should take.... :frank, is there a benefit to adopting the
payload.processes.[processname].scalars
approach from the "main" ping? Will that help on the server side?
Sorry for the delay - there's no specific reason to follow that format for our end. We can fill-in scalars that are any form. Benefits could come from similarity to existing pings, but I'll let you all decide if that's useful.
Assignee | ||
Comment 3•5 years ago
|
||
Comment 4•5 years ago
|
||
Assignee | ||
Comment 5•5 years ago
|
||
A quick note that, though this adds a mechanism for data collection, it doesn't add data collections itself so is not subject to Data Collection Review. It does have documentation, though, and any ids added will be data reviewed as Scalars like impression_id was.
Comment 7•5 years ago
|
||
bugherder |
Description
•