Trong bản beta của Telegram dành cho macOS đã xuất hiện phân tích sản phẩm với các phễu và khả năng thu hồi sự đồng ý

Kể từ tháng 10, một hệ thống con phân tích sản phẩm đã phát triển trong bản beta của Telegram dành cho macOS. Hệ thống này ghi nhận các lượt xem màn hình (screen views), sự kiện trong menu và cài đặt, các phễu (funnels) với kết quả cuối cùng và hành trình người dùng (user journeys) qua phương tiện truyền thông, chuyển tiếp và nhãn dán, cùng với đó là các quy tắc quyền riêng tư và sự đồng ý có thể thu hồi (revocable consent). Hiện tại chưa có công tắc (toggle) trong giao diện, và các lớp này không xuất hiện trong các client khác. Tuy nhiên, Telegram Desktop đã phát hành và tài liệu API đã mô tả từ mùa xuân năm 2026 cách client thông báo cho máy chủ về thời gian một bài đăng hiển thị trên màn hình và thời lượng bài hát đã được nghe.

Những gì đã xuất hiện trong bản beta dành cho macOS

Bản beta macOS được phân phối qua nguồn cấp dữ liệu cập nhật, mã nguồn của nó không có sẵn công khai. Thành phần của hệ thống con có thể được nhìn thấy qua tên các kiểu trong tệp thực thi của các bản build — chúng xuất hiện theo ba đợt.

Trong phân tích sản phẩm, một phễu (funnel) là một chuỗi các bước hướng tới một mục tiêu, với ghi nhận ở bước nào người dùng đã dừng lại: mở bảng nhãn dán, chọn, gửi hoặc đóng. Hành trình (journey) là cùng một chuỗi theo một kịch bản. Theo tên gọi, có ba kịch bản: phương tiện truyền thông, chuyển tiếp và nhãn dán. Riêng biệt, hệ thống cũng ghi nhận nguồn gốc của việc chuyển hướng đến trình duyệt tích hợp (BrowserAnalyticsOrigin) và phần nào trong ứng dụng mà thư viện ảnh được mở (GalleryAnalyticsContext).

Khối này hoạt động như một thử nghiệm. Chưa đầy hai giờ sau bản build 283338, bản build tiếp theo, 283342, đã được phát hành mà không có nó, nhưng vào ngày 23 tháng 10, nó đã quay trở lại trong bản 13.1.0.283362 và duy trì từ đó — trong các bản build ngày 26 tháng 10 và sau đó, tất cả các lớp đều có mặt.

Có công tắc tắt không

Trong giao diện — không. Không có văn bản nào về phân tích, thống kê sử dụng hoặc sự đồng ý thu thập dữ liệu trong các chuỗi nhị phân, gói tài nguyên hay bản dịch của client dành cho macOS.

Trong mã nguồn có một gợi ý. AnalyticsPrivacy và AnalyticsRevocable theo tên gọi là các quy tắc quyền riêng tư và khả năng thu hồi, AnalyticsParameterRule là quy tắc cho phép truyền các tham số sự kiện nào, AnalyticsScope là phạm vi áp dụng. Đây là một giả thuyết dựa trên tên gọi, không có mã nguồn: phân tích thường được thiết kế theo cách này, nơi người dùng có thể từ chối thu thập dữ liệu, và sự kiện không mang các trường không cần thiết.

Các tên gọi không cho biết sự kiện được gửi đi đâu. Trong sơ đồ API công khai đã có phương thức help.saveAppLog: nó chấp nhận một gói sự kiện với thời gian, loại, người trò chuyện và JSON tùy ý. Trình thu thập trong bản beta được gọi là AppLogEvent*, nhưng mối liên hệ giữa chúng chỉ là một phỏng đoán dựa trên sự tương đồng về âm thanh.

Những gì các client đã phát hành đang thu thập

Một phần các phép đo đã không còn là thử nghiệm từ lâu. Trong tài liệu API mô tả phương thức messages.reportReadMetrics: client thông báo cho máy chủ về thời gian mỗi tin nhắn đã ở trong vùng hiển thị của cuộc trò chuyện (chat viewport). Các quy tắc được mô tả chi tiết đến từng mili giây.

• lượt xem ngắn hơn 300 ms không được tính;
• time_in_view_ms — thời gian tin nhắn hiển thị ít nhất một pixel;
• active_time_in_view_ms — một phần của thời gian này khi người dùng hoạt động; các client chính thức coi người dùng hoạt động trong 15 giây sau bất kỳ hành động nào;
• seen_range_ratio_permille — tỷ lệ chiều cao của bài đăng nằm trong vùng hiển thị, tính bằng phần nghìn;
• hơn năm phút hiển thị liên tục sẽ được cắt thành các lượt xem riêng biệt, các phép đo được tích lũy theo cuộc trò chuyện và gửi đi theo gói với độ trễ 5 giây.

Cũng tại đó mô tả messages.reportMusicListen — số giây bài hát đã được nghe. Telegram Desktop gửi cả hai phép đo này từ tháng 3 năm 2026: việc theo dõi lượt xem bài đăng và việc theo dõi lượt nghe xuất hiện trong mã nguồn cùng một ngày, 25 tháng 3.

Các phép đo này trả lời câu hỏi "người dùng đọc và nghe gì", còn hệ thống con mới trả lời câu hỏi "người dùng sử dụng ứng dụng như thế nào". Cái đầu tiên liên quan đến kênh và nội dung, cái thứ hai liên quan đến màn hình, nút và kịch bản.

Đo từ xa mạng và công cụ Rust

Phần sớm nhất, NetworkTelemetry, xuất hiện vào ngày 3 tháng 10 cùng với RecordingNetworkEngine và liên quan đến một nhiệm vụ khác. Một ngày trước đó, vào ngày 2 tháng 10, công cụ mạng dựa trên Rust — RustNetworkEngine, RustRequestService, RustEngineNetworkRouter — và giao diện chung NetworkEngine với công tắc SwitchingNetworkEngine đã xuất hiện trong bản beta. Các chuỗi «Rust (restart required)» và «Engine switch to rust refused» cho thấy công cụ thay đổi khi khởi động lại, còn «Rust engine crash of» và «Rust panic» cho thấy các sự cố của nó được ghi nhận riêng.

Đo từ xa lưu trữ độ trễ, ngắt kết nối và các loại lỗi, trong khi công cụ ghi lại các yêu cầu và phản hồi của bất kỳ trong hai ngăn xếp nào. Cùng với nhau, điều này giống như một môi trường thử nghiệm để so sánh mã mạng cũ với mã mới trên lưu lượng truy cập thực. Không có phương thức nào trong sơ đồ gửi đo từ xa mạng lên máy chủ — các báo cáo có thể vẫn ở cục bộ.

Nơi không có điều này

Trong bản beta Telegram dành cho Android 13.2.0 từ ngày 27 tháng 10 không có Analytics* hay NetworkTelemetry. Tất cả những gì được gọi là analytics và telemetry ở đó đều thuộc về các thư viện tích hợp của Google: Cast, Play Services và Firebase Crashlytics. Phương thức reportReadMetrics được mô tả trong mã nguồn Android, nhưng không thấy lời gọi trong bản beta.

Trong Telegram Desktop cũng không có phân tích sản phẩm — ở đó chỉ có việc theo dõi lượt xem bài đăng và lượt nghe bài hát đã mô tả ở trên.