diff --git a/work/projects/cpm-extension-health-pixels-privacy-triage.md b/work/projects/cpm-extension-health-pixels-privacy-triage.md index bb248557..b7a81081 100644 --- a/work/projects/cpm-extension-health-pixels-privacy-triage.md +++ b/work/projects/cpm-extension-health-pixels-privacy-triage.md @@ -10,18 +10,21 @@ Status: **DRAFT** ## Pixels -| iOS pixel | Trigger | Frequency | -| -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------- | -| `m_debug_web_extension_cpm_initialization_failed_after_session_restore` | CPM does not initialize during a restored-session navigation batch. | Daily | -| `m_debug_web_extension_cpm_initialization_recovered_after_session_restore` | CPM initializes on the next independent navigation after the restored-session batch failed. | Daily | -| `m_debug_web_extension_cpm_messaging_stuck` | CPM also fails on a later independent navigation, with no CPM success between attempts. | Daily + count, once per episode | -| `m_debug_web_extension_cpm_messaging_recovered_without_extension_reload` | A stuck episode recovers before the extension is reloaded. | Daily + count, once per episode | -| `m_debug_web_extension_cpm_messaging_recovered_after_extension_reload` | A stuck episode recovers after the app reloads the extension. | Daily + count, once per episode | -| `m_debug_web_extension_cpm_messaging_extension_reload_failed` | CPM still fails after the app reloads the extension. | Daily + count, once per episode | +| Pixel | Trigger | Frequency | +| -------------------------------------------------------------------------- | --------------------------------------------------------------------- | --------------- | +| `m_debug_web_extension_cpm_initialization_missed_after_session_restore` | Restored tabs do not receive the initial CPM response. | Daily | +| `m_debug_web_extension_cpm_initialization_recovered_after_session_restore` | CPM later responds after the restoration miss. | Daily | +| `m_debug_web_extension_cpm_initialization_failed_after_tab_crash` | CPM fails on the first eligible navigation after a tab crash. | Daily + count | +| `m_debug_web_extension_cpm_initialization_failed_after_extension_reload` | CPM fails on the first eligible navigation after an extension reload. | Daily + count | +| `m_debug_web_extension_cpm_messaging_stuck_session_restoration` | Messaging remains stuck after a restoration-originated failure. | Daily + count, once/episode | +| `m_debug_web_extension_cpm_messaging_stuck_tab_crash` | Messaging remains stuck across attempts associated with a tab crash. | Daily + count, once/episode | +| `m_debug_web_extension_cpm_messaging_stuck_other` | Messaging remains stuck across other independent navigations. | Daily + count, once/episode | +| `m_debug_web_extension_cpm_messaging_recovered_without_extension_reload` | A stuck episode recovers without an extension reload. | Daily + count, once/episode | +| `m_debug_web_extension_cpm_messaging_recovered_after_extension_reload` | A stuck episode recovers after an extension reload. | Daily + count, once/episode | +| `m_debug_web_extension_cpm_messaging_extension_reload_failed` | Reload fails or CPM remains stuck after reload. | Daily + count, once/episode | -macOS uses the same names with the `m_mac_debug_` prefix. iOS adds the standard platform and form-factor suffixes. - -Only standard parameters are sent: `appVersion`, plus `pixelSource` and `channel` on macOS. +iOS and macOS send the exact same pixel names. Parameters distinguish `platform=ios|macos` and `form_factor=phone|tablet|desktop`. +`appVersion` is included; macOS also includes `pixelSource` and `channel`. ## Detection Rules @@ -30,6 +33,9 @@ Only standard parameters are sent: `appVersion`, plus `pixelSource` and `channel - A redirected restoration still belongs to the restoration batch when `.sessionRestoration` appears in its navigation history. - After restoration, any independent eligible document navigation can be the next attempt: reload, typed URL, link, new-tab navigation, or a real back/forward load. - Redirects do not count separately. Same-document, failed, non-HTTP(S), and BFCache navigations do not count when CPM is not expected to initialize again. +- A tab crash marks only the next eligible navigation in that tab. +- A successful extension reload marks only the next eligible CPM attempt. +- `stuck` retains the strongest contributing reason: tab crash, then session restoration, then other. - Any successful CPM initialization closes the episode. Pixels are fired for episode transitions, never for every failed tab. ## Privacy Questions @@ -38,22 +44,22 @@ Only standard parameters are sent: `appVersion`, plus `pixelSource` and `channel Yes. **Do they share parameters with other pixels?** -Yes. They use only existing standard parameters. +Yes. They use `platform` and `form_factor` to combine both apps under the same pixel names. **Could the parameters link pixels to the same user?** -No. No identifier is added. +No. Both parameters are coarse enums and contain no identifier. **Do the pixels include a URL or search query?** No. They also exclude hostnames, page titles, tab IDs, document IDs, navigation types, errors, and CPM rules. **Are the pixels temporary?** -The two session-restoration pixels are temporary diagnostics. The stuck-state and recovery pixels are permanent health monitoring. +The session-restoration and post-crash/reload pixels are diagnostics. The stuck-state and recovery pixels are permanent health monitoring. **Why are the permanent pixels needed?** To measure how often CPM messaging becomes stuck and whether extension reload recovers it. **Do any parameters or suffixes fall outside the standard criteria?** -No. +`platform` and `form_factor` are explicit enum parameters used instead of platform-specific pixel names. **Do the pixels fire on sensitive user events?** No. They report only CPM extension health states.