macOS के लिए Telegram बीटा में अक्टूबर से प्रोडक्ट एनालिटिक्स की एक सबसिस्टम विकसित हो रही है। यह स्क्रीन व्यूज़, मेनू और सेटिंग्स में होने वाली घटनाओं, परिणामों के साथ फ़नल और मीडिया, फ़ॉरवर्डिंग और स्टिकर्स के माध्यम से यूज़र जर्नी को ट्रैक करती है। इसके साथ ही, प्राइवेसी रूल्स और सहमति जिसे वापस लिया जा सकता है, भी हैं। इंटरफ़ेस में अभी तक कोई टॉगल नहीं है, और अन्य क्लाइंट्स में ये क्लास दिखाई नहीं देते हैं। हालांकि, जारी किए गए 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 नाम से - प्राइवेसी रूल्स और revocability, AnalyticsParameterRule - यह नियम कि इवेंट के कौन से पैरामीटर भेजने की अनुमति है, AnalyticsScope - स्कोप। यह नामों के आधार पर एक परिकल्पना है, बिना कोड के: एनालिटिक्स आमतौर पर इस तरह से संरचित होता है जहाँ उपयोगकर्ता कलेक्शन से ऑप्ट-आउट कर सकता है, और इवेंट में अनावश्यक फ़ील्ड नहीं होते हैं।
इवेंट कहाँ जाते हैं, नाम नहीं बताते। सार्वजनिक API स्कीम में लंबे समय से help.saveAppLog मेथड है: यह समय, प्रकार, चैट पार्टनर और मनमाने JSON के साथ इवेंट्स का एक बैच स्वीकार करता है। बीटा में कलेक्टर को AppLogEvent* कहा जाता है, लेकिन उनके बीच का संबंध ध्वनि समानता के आधार पर एक अनुमान है।
जारी किए गए क्लाइंट पहले से क्या ट्रैक करते हैं
कुछ मेज़रमेंट्स लंबे समय से प्रयोग नहीं हैं। API डॉक्यूमेंटेशन messages.reportReadMetrics मेथड का वर्णन करता है: क्लाइंट सर्वर को रिपोर्ट करता है कि प्रत्येक मैसेज चैट के विज़िबल एरिया में कितने समय तक रहा। नियम मिलीसेकंड तक विस्तृत हैं।
- 300 ms से कम का व्यू काउंट नहीं किया जाता है;
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» बताते हैं कि इसकी क्रैश को अलग से पकड़ा जाता है।
टेलीमेट्री देरी, डिस्कनेक्शन और एरर क्लास को स्टोर करती है, जबकि रिकॉर्डिंग इंजन दोनों स्टैक में से किसी के भी रिक्वेस्ट और रिस्पॉन्स को लिखता है। साथ में, यह पुराने नेटवर्क कोड की नए के साथ लाइव ट्रैफ़िक पर तुलना करने के लिए एक टेस्ट बेंच जैसा लगता है। सर्वर पर नेटवर्क टेलीमेट्री भेजने वाला कोई मेथड स्कीम में नहीं है - रिपोर्ट स्थानीय रह सकती हैं।
यह कहाँ नहीं है
27 अक्टूबर के Telegram for Android 13.2.0 बीटा में न तो Analytics* और न ही NetworkTelemetry है। वहाँ जो कुछ भी एनालिटिक्स और टेलीमेट्री कहलाता है, वह Google की एम्बेडेड लाइब्रेरीज़ से संबंधित है: Cast, Play Services और Firebase Crashlytics। Android कोड में reportReadMetrics मेथड का वर्णन किया गया है, लेकिन बीटा में इसका कॉल दिखाई नहीं देता है।
Telegram Desktop में भी प्रोडक्ट एनालिटिक्स नहीं है - वहाँ केवल ऊपर वर्णित पोस्ट व्यूज़ और गाने सुनने की ट्रैकिंग है।
