--- updated: '2026-10-20' --- # Privacy Triage: Apple - CPM Extension Health Pixels > **Historical privacy draft; current contract checked 20 October 2026.** The separate event list below is superseded on the published #7376 branch by one `web_extension_cpm_episode` with **daily+count**. The PR is closed without merge; no shipping claim follows from this note. > > All current parameters, four-value `stuck`, two-phase `bg_events`, 11 retired events and nine removed fields: [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. Old `platform`/`form_factor` proposals and self-service answers below are not a current approval. No identifiers are added, but rare combinations of fields/history can still be correlated; daily deduplication does not prove anonymity. Approval coverage for the latest field/history changes was not verified. See [[cpm-status-2026-10-15#6. Телеметрия]]. ## Historical context — recorded 15 October 2026 > **Исторический draft; контекст сверён 15 октября 2026.** Текущая реализация/атрибуция failure, stuck и recovery, PR/CI и новые P5/P6 tests описаны в [[cpm-status-2026-10-15]]. Таблица и поля draft ниже сохранены; это обновление не отправляет privacy review и не утверждает новую схему. > > Actual failure/stuck из новых tests — существующие production monitor events. Healthy page initResp проверяется отдельно от dashboard refresh; source-linked P5/P6 не добавляют новых pixels/params и не доказывают prevalence. См. также [[cpm-m3-telemetry-privacy-triage]] и [[cpm-readiness-telemetry-tech-design-2026-10-15]]. Status: **DRAFT** **Name:** Alex M **Email:** amartemyanov@duckduckgo.com **Objective:** O-E **PR:** [Add PR link] **Project:** https://app.asana.com/1/137249556945/project/1163321984198618/task/1216761517055116?focus=true ## Pixels | Pixel | Trigger | Frequency | | -------------------------------------------------------------------------- | --------------------------------------------------------------------- | --------------- | | `debug_web_extension_cpm_initialization_failed_after_session_restoration` | CPM fails after a restored-page navigation. | Daily | | `debug_web_extension_cpm_initialization_failed_after_tab_crash` | CPM fails on the first eligible navigation after a tab crash. | Daily | | `debug_web_extension_cpm_initialization_failed_after_extension_reload` | CPM fails on the first eligible navigation after an extension reload. | Daily | | `debug_web_extension_cpm_initialization_failed_after_other` | CPM fails after another eligible navigation. | Daily | | `debug_web_extension_cpm_messaging_stuck_session_restoration` | Messaging remains stuck after a restoration-originated failure. | Daily + count, once/episode | | `debug_web_extension_cpm_messaging_stuck_tab_crash` | Messaging remains stuck across attempts associated with a tab crash. | Daily + count, once/episode | | `debug_web_extension_cpm_messaging_stuck_other` | Messaging remains stuck across other independent navigations. | Daily + count, once/episode | | `debug_web_extension_cpm_messaging_recovered_without_extension_reload` | A failed tab or stuck episode recovers without an extension reload. | Daily + count, once/episode | | `debug_web_extension_cpm_messaging_recovered_after_extension_reload` | A failed tab or stuck episode recovers after an extension reload. | Daily + count, once/episode | | `debug_web_extension_cpm_messaging_extension_reload_failed` | CPM still fails after a successful extension reload. | Daily + count, once/episode | 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 - Check only finished, current, main-frame HTTP(S) document navigations after a grace period. A failure means the extension is loaded and the dashboard remains `.waiting`; `cpmStage` is diagnostic data, not part of detection. - A redirected restored-page navigation remains classified as session restoration. - 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` keeps the reason of the first initialization failure; a later failure does not replace it. - Any successful CPM initialization breaks the failure sequence. Recovery is reported when that success belongs to a previously failed tab or follows a stuck state. ## Privacy Questions **Do the pixels use transparent names?** Yes. **Do they share parameters with other pixels?** 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?** This historical draft proposed only coarse enums. That alone does not establish unlinkability, especially for the current payload containing multiple fields and a lifecycle timeline; combined distinguishability must be reviewed. **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 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?** `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. **Can occurrences be tied to the same user or a small group?** There is no explicit correlation identifier or browsing data, but rare combinations and matching timeline sequences can still distinguish reports. Daily deduplication is not a guarantee against correlation. **Does this meet the self-service criteria?** This is the historical draft's question, not a current approval. Eligibility/approval for the latest episode fields and timeline changes has not been verified in this documentation update.