git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[2026-08-31] eagle: work/projects/cpm-extension-health-pixels-privacy-triage.md

Browse Source
This commit is contained in:
Alexey Martemyanov
2026-08-31 18:26:21 +06:00
parent d59bf19d43
commit 715e3e0731
1 changed files with 24 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
work/projects/cpm-extension-health-pixels-privacy-triage.md
+24 -14
View File
@@ -10,17 +10,27 @@ Status: **DRAFT**
## Pixels
| Pixel | When it fires |
| ------------------------------------------------------------ | -------------------------------------------------------------------------- |
| `m_debug_web_extension_cpm_page_initialization_missing` | A finished HTTP(S) page load does not receive the initial CPM status. |
| `m_debug_web_extension_cpm_page_initialization_recovered` | CPM works on the next page load or reload without reloading the extension. |
| `m_debug_web_extension_cpm_messaging_suspected_stuck` | CPM fails repeatedly, including after a page reload and in another tab. |
| `m_debug_web_extension_cpm_messaging_recovered_after_reload` | CPM starts working after the app reloads the extension. |
| `m_debug_web_extension_cpm_messaging_reload_failed` | CPM still does not work after the app reloads the extension. |
| iOS pixel | Trigger | Frequency |
|---|---|---|
| `m_debug_web_extension_cpm_initialization_missed_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 |
macOS uses the same names with the `m_mac_debug_` prefix. iOS uses the standard platform and form-factor suffixes.
macOS uses the same names with the `m_mac_debug_` prefix. iOS adds the standard platform and form-factor suffixes.
The pixels send only the standard parameters: `appVersion`, plus `pixelSource` and `channel` on macOS.
Only standard parameters are sent: `appVersion`, plus `pixelSource` and `channel` on macOS.
## Detection Rules
- Check only finished, current, main-frame HTTP(S) document navigations after a grace period.
- Treat all `.sessionRestoration` navigations from one app launch as one batch, not one failure per restored tab.
- 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.
- Any successful CPM initialization closes the episode. Pixels are fired for episode transitions, never for every failed tab.
## Privacy Questions
@@ -34,13 +44,13 @@ Yes. They use only existing standard parameters.
No. No identifier is added.
**Do the pixels include a URL or search query?**
No. They also do not include hostnames, page titles, tab IDs, document IDs, error text, or CPM rules.
No. They also exclude hostnames, page titles, tab IDs, document IDs, navigation types, errors, and CPM rules.
**Are the pixels temporary?**
The two page-initialization pixels are temporary diagnostics. The three stuck-state and reload-result pixels are permanent health monitoring.
The two session-restoration pixels are temporary 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 reloading the extension fixes it.
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.
@@ -48,8 +58,8 @@ No.
**Do the pixels fire on sensitive user events?**
No. They report only CPM extension health states.
**Can multiple occurrences be tied to the same user or a small group?**
No. The pixels contain no correlation identifier or browsing data.
**Can occurrences be tied to the same user or a small group?**
No. There is no correlation identifier or browsing data.
**Does this meet the self-service criteria?**
Yes.