В бете Telegram для macOS с октября растёт подсистема продуктовой аналитики. Она учитывает показы экранов, события в меню и настройках, воронки с итогом и пути пользователя через медиа, пересылку и стикеры, а рядом с ней — правила приватности и согласие, которое можно отозвать. Переключателя в интерфейсе пока нет, в других клиентах этих классов не видно. При этом выпущенные Telegram Desktop и документация API уже с весны 2026 года описывают, как клиент сообщает серверу, сколько времени пост провёл на экране и сколько песни прослушано.
Что появилось в бете для macOS
Бета macOS раздаётся через фид обновлений, исходников у неё в открытом доступе нет. Состав подсистемы виден по именам типов в исполняемом файле сборок — они появлялись в три приёма.
| Сборка | Дата | Что добавилось |
|---|---|---|
| 12.10.283258 | 3 октября | Сетевая телеметрия NetworkTelemetry: замеры, события, обрывы, сводки за период, хранилище; рядом — RecordingNetworkEngine, запись сетевого поведения |
| 13.0.283308 | 11 октября | AppAnalytics, AnalyticsScreenTracker, AnalyticsEvent, AnalyticsEventSpec, AnalyticsSchema, AnalyticsMenu, AnalyticsSetting — показы экранов и события по заранее описанной схеме |
| 13.0.283338 | 19 октября | Пути пользователя AnalyticsMediaJourney, AnalyticsShareJourney, AnalyticsStickerJourney, AnalyticsMessageSend; воронки AnalyticsFlow и AnalyticsFlowOutcome; AnalyticsPrivacy, AnalyticsRevocable, AnalyticsScope, AnalyticsParameterRule; сборщик AppLogEventCollection |
Воронкой в продуктовой аналитике называют цепочку шагов к цели с отметкой, на каком шаге человек сошёл: открыл панель стикеров, выбрал, отправил или закрыл. Путь (journey) — та же цепочка по одному сценарию. По именам видно три сценария: медиа, пересылка и стикеры. Отдельно учитывается, откуда пришёл переход во встроенный браузер (BrowserAnalyticsOrigin) и в каком разделе открыта галерея (GalleryAnalyticsContext).
Блок вёл себя как эксперимент. Меньше чем через два часа после 283338 следующая сборка, 283342, вышла уже без него, а 23 октября он вернулся в 13.1.0.283362 и с тех пор держится — в сборках 26 октября и позже все классы на месте.
Есть ли выключатель
В интерфейсе — нет. Ни в строках бинарника, ни в пакете ресурсов, ни в переводах клиента для macOS нет текста про аналитику, статистику использования или согласие на сбор.
В коде намёк есть. AnalyticsPrivacy и AnalyticsRevocable по названию — правила приватности и отзываемость, AnalyticsParameterRule — правило, какие параметры события разрешено передавать, AnalyticsScope — область действия. Это гипотеза по именам, без кода: так обычно устроена аналитика, где пользователь может отказаться от сбора, а событие не несёт лишних полей.
Куда события уходят, имена не говорят. В публичной схеме API давно есть метод help.saveAppLog: он принимает пачку событий с временем, типом, собеседником и произвольным JSON. Сборщик в бете называется AppLogEvent*, но связь между ними — догадка по созвучию.
Что уже считают выпущенные клиенты
Часть замеров давно не эксперимент. В документации API описан метод messages.reportReadMetrics: клиент сообщает серверу, сколько каждое сообщение пробыло в видимой области чата. Правила расписаны до миллисекунды.
- показ короче 300 мс не считается;
time_in_view_ms— сколько сообщение было видно хотя бы одним пикселем;active_time_in_view_ms— часть этого времени, когда человек был активен; активным официальные клиенты считают пользователя 15 секунд после любого действия;seen_range_ratio_permille— какая доля высоты поста попала в видимую область, в тысячных;- больше пяти минут непрерывного показа режутся на отдельные показы, замеры копятся по чатам и уходят пачкой с задержкой в 5 секунд.
Там же описан messages.reportMusicListen — сколько секунд песни прослушано. Telegram Desktop отправляет оба замера с марта 2026 года: учёт просмотров постов и учёт прослушиваний появились в коде одним днём, 25 марта.
Эти замеры отвечают на вопрос «что читают и слушают», а новая подсистема — на вопрос «как пользуются самим приложением». Первое касается каналов и контента, второе — экранов, кнопок и сценариев.
Сетевая телеметрия и движок на Rust
Самая ранняя часть, NetworkTelemetry, пришла 3 октября вместе с RecordingNetworkEngine и относится к другой задаче. Днём раньше, 2 октября, в бете появился сетевой движок на Rust — RustNetworkEngine, RustRequestService, RustEngineNetworkRouter — и общий интерфейс NetworkEngine с переключателем SwitchingNetworkEngine. Строки «Rust (restart required)» и «Engine switch to rust refused» говорят, что движок меняется с перезапуском, а «Rust engine crash of» и «Rust panic» — что его падения ловятся отдельно.
Телеметрия хранит задержки, обрывы и классы ошибок, а записывающий движок пишет запросы и ответы любого из двух стеков. Вместе это похоже на стенд для сравнения старого сетевого кода с новым на живом трафике. Метода, который отправлял бы сетевую телеметрию на сервер, в схеме нет — отчёты могут оставаться локальными.
Где этого нет
В бете Telegram для Android 13.2.0 от 27 октября нет ни Analytics*, ни NetworkTelemetry. Всё, что там называется analytics и telemetry, принадлежит встроенным библиотекам Google: Cast, Play Services и Firebase Crashlytics. Метод reportReadMetrics в коде Android описан, но вызова в бете не видно.
В Telegram Desktop продуктовой аналитики тоже нет — там есть только учёт просмотров постов и прослушиваний песен, описанный выше.
