Окно: 2026-10-12…14 UTC (3 полных дня), версии с диагностикой: iOS 7.240+, macOS 1.210+. Единица: daily-пиксель = устройство-день на причину, не пользователь и не эпизод.
Инструмент: ~/Developer/grafana-data-tools (query.py, Grafana → ClickHouse metrics.pixels, read-only). Запросы ниже запускались через тот же helper (read-dashboard.py) отдельным раннером; SQL приведён в конце.
Классификация когорт по приоритету: error 6 → нет background view → tab not connected → Network заменён → пробуждение (view <30 с после dealloc) → недавняя загрузка контекста (load/base_url_changed ≤2 мин) → other.
Объёмы (12–14 октября)
iOS
macOS
initialization_failed.daily
3 273 025
119 950
stuck.daily
511 660
40 842
восстановились без reload (daily, from=initialization_failed)
1 135 477 (34.7% от init)
30 738 (25.6%)
stuck → восстановились после M4 reload (daily)
293 557 (57.4% от stuck)
21 865 (53.5%)
reload_failed.daily
140 921 (27.5% от stuck)
17 796 (43.6%)
initialization_failed — только .daily; stuck, recovered_*, reload_failed — daily+count. Параметры снимка есть только на init_failed и stuck; на recovered только recovery_from/recovery_document/recovery_after.
Когорты: доля init → stuck
Когорта
iOS init → stuck
macOS init → stuck
error 6
6.1% → 21.5%
1.0% → 1.9%
нет background view
48.1% → 10.9%
3.3% → 1.8%
tab not connected
0.03% → 0.05%
6.2% → 8.9%
Network заменён
16.8% → 39.7%
13.6% → 26.6%
пробуждение (view <30 с)
7.9% → 9.5%
32.5% → 32.2%
недавняя загрузка контекста
15.7% → 6.0%
20.0% → 6.4%
other
5.3% → 12.5%
23.4% → 22.2%
Рост доли при переходе init → stuck значит, что когорта чаще остаётся сломанной (error 6, Network заменён, tab not connected); падение значит самоизлечение (нет view, недавняя загрузка).
Основание для фиксов
B (Network-процесс): когорта «Network заменён» растёт в 2–2.4× при переходе в stuck; reload_failed высок (reload расширения не лечит мёртвый worker). Основание сильное. Ограничение: network_restarted это прокси «PID изменился»; причинность подтверждает только init_stage=none (#7385).
A (первая загрузка посреди сессии): сигнатура «загрузка ≤2 мин, не при запуске (launch age ≥15 мин), первый view»: iOS 129k init (3.9%) → 4.6k stuck (0.9%); macOS 505 → 118. Реально, но разово (0.23×) и на macOS мелко. Сигнатура неточна: захватывает и M4-reload; нужен context_load_cause.
Паттерны событий без фиксов (stuck.daily, 14 октября, хвост bg_events без возрастов)
Картина
Хвост
iOS / macOS (строк)
Чем различать
P1. Цикл пробуждения: idle-выгрузка, затем view
view>proxy_on>dealloc>view>proxy_on
16.0k / 4.3k (wake) + 16.3k / 2.4k (то же, но view старше 30 с, класс other)
load>view>proxy_on>dealloc, часто сextension_updated
iOS ≈0 / 627 + 235
есть tab_controller_match, tab_has_ext_scripts, app_version_change, reason
В iOS-когорте «нет view» крупнейшие группы лежат в первых 30 с после запуска: восстановление сессии (около половины) и reason=other. Первая корзина app_launch_age «<30 с» слишком грубая.
Что нужно в данных (минимум)
Поле / пиксель
Вопрос
Где
bg_ready_after
всё ещё загружается, загрузился или упал
PR0
bg_view_age
пробуждение или давно
PR0
bg_load_error_after, bg_load_error_app_state (только при error 6)
таймер 30 с, состояние приложения
PR0
recovery_document, recovery_after
опоздавший ответ или потерянный
PR0
app_state, open_tabs (грубо), только на initialization_failed
когорта «нет view» на запуске
PR0
новое:context_load_cause (запуск / установка / апгрейд / reload при восстановлении) и context_load_age
точная сигнатура A, замена load@ и extension_updated
PR0
новое:bg_died_reason, base_url_changed
смерть процесса, очистка при смене baseURL
PR0
новое: мелкие корзины app_launch_age для первых 30 с
loading_tabs; в таймлайне view, dealloc, proxy_on, error_*, hold/release/proxy_off
bg_events
Сейчас единственный источник давности загрузки и причины смерти процесса. Остальные токены дублируют bg_view_creations, context_errors или нули (hold/release/proxy_off = 0%).
Скаляры вместо таймлайна воспроизводят когорты загрузки и пробуждения на 100% строк (измерено 14 октября).
Однодневная уникальность строк stuck.daily по всем параметрам: с bg_events 8.3% (iOS) и 30% (macOS); сокращённые информативные токены 2.1% / 5.2%; скаляры 0.96% / 4.4%; без событий 0.25% / 2.0%.
Верхняя граница прироста от новых полей (синтетическое независимое равновероятное поле): с текущим bg_events при десяти значениях iOS 21%, macOS 65%; со скалярами 3.6% / 15.8%. Про «не станет хуже» можно говорить только со скалярами. В публичный PR цифры не писать.
Критерии успеха и опровержения
B подтверждается, если после релиза падают доля «Network заменён» среди stuck и reload_failed, background_restart показывает восстановление, а у таких stuck init_stage=none.
A подтверждается, если сокращается когорта «мид-сессионная первая загрузка» (context_load_cause). Если нет, основание слабое: она около 1% stuck на iOS и почти 0 на macOS.
Остаток P1/P3 подтверждает гипотезу «медленный старт, а не потеря», если bg_ready_after у упавших заметно хуже базлайна здоровых загрузок и recovery_document=failed_navigation.
