This is a request to change the PUSH_API_NOTIFICATION_RECEIVED Telemetry probe to be opt-out as it currently is not and our team has determined that this probe is needed for better understanding the usage of our product. https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json#10415 * How will collecting this data provide user value? By collecting this data we'll be able to optimize the client experience (performance and interactions) for the number of actually messages received. Currently we have no clear understanding of the number of push messages a client in the production environment receives. * How is collecting this data essential to running the business? The Push service gives us an understanding of how many messages are received by clients and collecting this data would give us another separate end point which could be used to verify the service metric. * Who is responsible for monitoring the data, and what data artifacts (dashboards, alerts, custom reports) will they use to do this? This information will be used to help create the main dashboard for understanding user value of the Push service. As noted in bug 1270482 this metric is missing and should be included as soon as possible to give our team another perspective on usage.

Ben - am I correct in thinking you need to review this change?

The user value sounds fine here. I do want to officially mark it when the patch is ready, and make sure that the histogram description is well-documented. Bryan, you say "will be used to help create the main dashboard" but I'm looking for personal responsibility. Are you responsible for monitoring that dashboard and the long-term user value attached to collecting this data?

Hmm, looking at the code, I think we want to make "PUSH_API_NOTIFY" opt-out instead. "PUSH_API_NOTIFICATION_RECEIVED" counts all messages received from the server, including ones where we don't notify the service worker because the crypto is bad, or the background message quota is exceeded. Bryan also suggested making "WEB_NOTIFICATION_CLICKED" opt-out. The funnel looks something like: PUSH_API_NOTIFY -> WEB_NOTIFICATION_SHOWN -> WEB_NOTIFICATION_CLICKED.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > Bryan, you say "will be used to help create the main dashboard" but I'm > looking for personal responsibility. Are you responsible for monitoring that > dashboard and the long-term user value attached to collecting this data? Yes, that's correct. I'm responsible for monitoring the dashboards and sharing our KPIs from them. (In reply to Kit Cambridge [:kitcambridge] from comment #3) > Hmm, looking at the code, I think we want to make "PUSH_API_NOTIFY" opt-out > instead. "PUSH_API_NOTIFICATION_RECEIVED" counts all messages received from > the server, including ones where we don't notify the service worker because > the crypto is bad, or the background message quota is exceeded. Hmm, ok. That makes more sense for our funnel. > Bryan also suggested making "WEB_NOTIFICATION_CLICKED" opt-out. The funnel > looks something like: PUSH_API_NOTIFY -> WEB_NOTIFICATION_SHOWN -> > WEB_NOTIFICATION_CLICKED. Yes, we just talked about this today. Lets pull these all together as this represents the funnel dashboard we're expecting to create and so they have the same reasoning behind them.

Benjamin, do these descriptions look OK to you?

Comment on attachment 8759879 [details] [diff] [review] optOut.patch data-review=me

Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/fx-team/rev/ebcfd81debe7 Change the PUSH_API_NOTIFY and WEB_NOTIFICATION_CLICKED probes to be opt-out. r=bsmedberg