La beta de Telegram para macOS incorpora analítica de producto con embudos y consentimiento revocable

Desde octubre, el subsistema de analítica de producto en la beta de Telegram para macOS ha estado creciendo. Este subsistema registra las vistas de pantalla, los eventos en menús y configuraciones, los embudos con resultados y los recorridos del usuario a través de medios, reenvíos y stickers. Junto a ella, se encuentran las reglas de privacidad y el consentimiento revocable. Por ahora, no hay un interruptor en la interfaz, y estas clases no son visibles en otros clientes. Sin embargo, Telegram Desktop y la documentación de la API, lanzados desde la primavera de 2026, ya describen cómo el cliente informa al servidor cuánto tiempo ha permanecido una publicación en pantalla y cuántas canciones se han escuchado.

Novedades en la beta para macOS

La beta de macOS se distribuye a través del feed de actualizaciones, y su código fuente no está disponible públicamente. La composición del subsistema es visible por los nombres de los tipos en el archivo ejecutable de las compilaciones — estos aparecieron en tres fases.

En la analítica de producto, un embudo (funnel) es una cadena de pasos hacia un objetivo, con una marca en el paso donde el usuario abandonó: abrió el panel de stickers, seleccionó, envió o cerró. Un recorrido (journey) es la misma cadena para un escenario específico. Por los nombres, se distinguen tres escenarios: medios, reenvío y stickers. Se registra por separado el origen de la transición al navegador integrado (BrowserAnalyticsOrigin) y la sección donde se abre la galería (GalleryAnalyticsContext).

Este bloque se comportó como un experimento. Menos de dos horas después de la 283338, la siguiente build, la 283342, se lanzó sin él, pero el 23 de octubre regresó en la 13.1.0.283362 y se ha mantenido desde entonces — en las builds del 26 de octubre y posteriores, todas las clases están presentes.

¿Hay un interruptor?

En la interfaz, no. Ni en las cadenas del binario, ni en el paquete de recursos, ni en las traducciones del cliente para macOS hay texto sobre analítica, estadísticas de uso o consentimiento para la recopilación.

En el código hay una pista. AnalyticsPrivacy y AnalyticsRevocable, por su nombre, son reglas de privacidad y revocabilidad, AnalyticsParameterRule es una regla sobre qué parámetros de evento se permite transmitir, y AnalyticsScope es el ámbito de acción. Esta es una hipótesis basada en los nombres, sin el código: así es como suele funcionar la analítica donde el usuario puede rechazar la recopilación, y el evento no lleva campos innecesarios.

Los nombres no indican a dónde van los eventos. En el esquema público de la API existe desde hace tiempo el método help.saveAppLog: este acepta un paquete de eventos con tiempo, tipo, interlocutor y un JSON arbitrario. El recolector en la beta se llama AppLogEvent*, pero la conexión entre ellos es una conjetura por la similitud fonética.

Qué ya registran los clientes lanzados

Parte de las mediciones no son un experimento desde hace tiempo. La documentación de la API describe el método messages.reportReadMetrics: el cliente informa al servidor cuánto tiempo permaneció cada mensaje en el área visible del chat. Las reglas están detalladas hasta el milisegundo.

• una vista de menos de 300 ms no se cuenta;
• time_in_view_ms — cuánto tiempo fue visible el mensaje, aunque sea por un píxel;
• active_time_in_view_ms — parte de ese tiempo, cuando la persona estuvo activa; los clientes oficiales consideran activo a un usuario 15 segundos después de cualquier acción;
• seen_range_ratio_permille — qué proporción de la altura de la publicación entró en el área visible, en milésimas;
• más de cinco minutos de visualización continua se dividen en vistas separadas, las mediciones se acumulan por chats y se envían en un paquete con un retraso de 5 segundos.

También se describe messages.reportMusicListen — cuántos segundos de una canción se han escuchado. Telegram Desktop envía ambas mediciones desde marzo de 2026: el registro de vistas de publicaciones y el registro de escuchas aparecieron en el código el mismo día, el 25 de marzo.

Estas mediciones responden a la pregunta "¿qué leen y escuchan?", mientras que el nuevo subsistema responde a la pregunta "¿cómo utilizan la aplicación en sí?". Lo primero se refiere a canales y contenido, lo segundo a pantallas, botones y escenarios.

Telemetría de red y motor en Rust

La parte más temprana, NetworkTelemetry, llegó el 3 de octubre junto con RecordingNetworkEngine y se relaciona con otra tarea. Un día antes, el 2 de octubre, apareció en la beta un motor de red en Rust — RustNetworkEngine, RustRequestService, RustEngineNetworkRouter — y una interfaz general NetworkEngine con un interruptor SwitchingNetworkEngine. Las cadenas «Rust (restart required)» y «Engine switch to rust refused» indican que el motor cambia con un reinicio, y «Rust engine crash of» y «Rust panic» — que sus fallos se capturan por separado.

La telemetría almacena latencias, interrupciones y clases de errores, y el motor de grabación escribe las solicitudes y respuestas de cualquiera de las dos pilas. Juntos, esto parece un banco de pruebas para comparar el código de red antiguo con el nuevo en tráfico real. No hay un método en el esquema que envíe la telemetría de red al servidor — los informes pueden permanecer locales.

Dónde no está esto

En la beta de Telegram para Android 13.2.0 del 27 de octubre no hay ni Analytics* ni NetworkTelemetry. Todo lo que allí se llama analytics y telemetry pertenece a las bibliotecas integradas de Google: Cast, Play Services y Firebase Crashlytics. El método reportReadMetrics está descrito en el código de Android, pero no se ve ninguna llamada en la beta.

En Telegram Desktop tampoco hay analítica de producto — allí solo existe el registro de vistas de publicaciones y escuchas de canciones, descrito anteriormente.