[2026-10-06] eagle: work/projects/cpm-web-extension-public-attribution-2026-10-05.md

work/projects/cpm-web-extension-public-attribution-2026-10-05.md

@@ -95,6 +95,34 @@
 
 Код release tags: `WebExtensionPixelFiring.swift` (семейства и частоты CPM); `WebExtensionManager.swift` (`.loaded` после общего load); `WebExtensionLifecycleCoordinator.swift` (`stateChecked`/`embeddedNotLoaded`); платформенные `AutoconsentMessageHandlerDelegate` (пересылка Web Extension пикселей); `AutoconsentUserScript.swift` (то же имя с `fromExtension=0` или без параметра); release bundle background `handleAutoConsentMessage`, `firePixel`, `sendSummaryPixel` (`init`, `initResp` и двухминутная сводка).
 
+## 7. Общие `bg_events` у init failure и последующего stuck
+
+**Кодовая связь сильнее совпадения строк.** Внутри `CPMMessagingHealthMonitor.reportFailure` первый timeout создаёт `Episode`, а `messaging.stuck` отправляется только после ещё одного timeout проверки, начатой позже первого failure (для confirmation — не session-restoration). Episode живёт не более пяти минут. Имя stuck наследует `failureReason` **первого** timeout; диагностика `stuck` снимается с вкладки **второго** timeout. `CPMMessagingDiagnosticsRecorder` сохраняет общую историю background context между этими снимками и при каждом берёт последние 12 событий; первый failure не очищает её. Поэтому `stuck.bg_events` действительно может содержать события, случившиеся до первого init failure. Новый context или вытеснение старых событий обрывает это наблюдение.
+
+**Проверка на выгрузке после release tag.** Для каждого stuck искался более ранний init failure той же платформы и с тем же `reason` в окне пяти минут. Требовалось точное совпадение порядка токенов `bg_events` без возрастных суффиксов и совместимость всех возрастных buckets после прибавления разницы timestamps (допуск ±30 с). Для сильного сигнала оставлены цепочки длиной **не менее шести** событий. Контроль: timestamps stuck сдвинуты на +10 и −10 минут внутри post-tag интервала; все прочие правила те же. Это тест **обогащения совпадениями**, не восстановление анонимного reporter ID. Время пикселя может отличаться от времени снимка из-за доставки.
+
+| После tag | Stuck daily | С цепочкой ≥6 | Совпало с более ранним init | Контроль +10 / −10 мин | Ровно один кандидат в выгрузке |
+|---|---:|---:|---:|---:|---:|
+| iOS 7.240 | 1 440 | 1 025 | **693** | 255 / 270 | 467 |
+| macOS 1.210 | 487 | 368 | **168** | 29 / 19 | 148 |
+
+Иными словами, длинные цепочки у последующих stuck совпадают с цепочками более ранних init failures значительно чаще, чем при соседнем сдвинутом времени. Но «ровно один кандидат» означает один подходящий **анонимный пиксель** в этой выгрузке, а не доказанный один пользователь. `.daily` мог подавить настоящий первый пиксель, а часто встречающиеся цепочки способны совпасть у разных пользователей.
+
+**Какие группы дают эту связь:**
+
+| Группа stuck после tag | Stuck всего | Длинная цепочка совпала | Контроль +10 мин | Уникальный кандидат с той же группой init |
+|---|---:|---:|---:|---:|
+| iOS, исправный native-снимок | 789 | **437** | 199 | 249 |
+| iOS, background load error 6 | 338 | **152** | 20 | 142 |
+| macOS, исправный native-снимок | 335 | **138** | 21 | 120 |
+| macOS, только история context error | 79 | **20** | 6 | 14 |
+
+Пример совместимой пары iOS с одним кандидатом: в init-хвосте после повторных `dealloc→view→proxy_on` стоит `error_wkwebextensioncontexterrordomain:6@30s`; 41 секунду спустя stuck содержит **тот же порядок 12 токенов**, а последний error уже помечен `@2m`. Это согласуется с одним сохраняющимся background-сбоем через два timeout, но без reporter/episode ID остаётся вероятностным сопоставлением. В группе с исправным native-снимком найдены аналогичные пары с тем же длинным `load→view→proxy_on→dealloc→view→proxy_on...` и более старшими age buckets на stuck: два timeout могут происходить без нового видимого WebKit lifecycle-события.
+
+Метод намеренно слаб для коротких хвостов `load` и `load→view→proxy_on`, в том числе startup `no scripts/no view` и macOS controller mismatch: у 35 macOS stuck с неверным controller только 3 хвоста длиной ≥6, поэтому отсутствие длинного match здесь ничего не опровергает. Из этих таблиц **нельзя вычислять вероятность перехода отдельного init failure в stuck**: нет идентификатора установки или episode, а `.daily` дедуплицирует имена. Тем не менее сочетание state machine в коде и превышения над контролем подтверждает, что stuck-пиксели отражают повторные timeout-эпизоды, а не просто новое имя для одиночного init failure.
+
+Воспроизведение: `match_event_chains.py` → `chain_match_summary.tsv`, `chain_match_transitions.tsv` в каталоге выгрузки. Исходные строки: `initialization_daily.tsv` и `events_daily.tsv`. Числа выше используют только after-tag строки; до публикации остаются отдельно.
+
 ## Источники и воспроизведение сверки
 
 Локальная выгрузка и код подсчёта: `cpm-public-attribution-2026-10-06/` в `/Users/admin/DuckDuckGo/apple-browsers.git`. `inventory.tsv` — полный CPM daily/count перечень и actual reload errors; `release_cutover_daily.tsv` — все CPM daily и actual reload daily по обе стороны release-tag timestamp; `initialization_daily.tsv` и `events_daily.tsv` — PII-free строки attribution с точным timestamp; `release_cutover_groups.tsv` и `release_cutover_reasons.tsv` — группы и причины по обе стороны tag, воспроизводятся `analyze_cutover.py`; `daily_groups_exclusive.tsv`, `daily_families.tsv`, `daily_reasons.tsv`, `daily_signatures.tsv` — сводки **полного дня, включая pre-tag**; `release_cpm_daily_trends.tsv` — 982 строки дневных трендов шести версий. Код поведения: `CPMMessagingHealthMonitor.swift` (`reportFailure`, `reportSuccess`), `WebExtensionManager.swift` (`onConfirmedHang`, `reloadEmbeddedExtensionAfterCPMMessagingHang`), `WebExtensionLifecycleCoordinator.swift` (navigation gate), `PixelKit.swift` (лимит `.daily` по имени и UTC). Снимок законченного дня; для вывода о динамике incidence нужен следующий полный UTC-день новой версии и знаменатель активных установок той же версии.