منذ أكتوبر، تتطور منظومة فرعية لتحليلات المنتج في نسخة بيتا من Telegram لنظام macOS. تأخذ هذه المنظومة في الاعتبار مشاهدات الشاشات، والأحداث في القوائم والإعدادات، ومسارات التحويل (funnels) بنتائجها، ومسارات المستخدم (user journeys) عبر الوسائط، وإعادة التوجيه (forwarding)، والملصقات (stickers). وإلى جانب ذلك، توجد قواعد الخصوصية والموافقة القابلة للسحب (revocable consent). لا يوجد مفتاح تبديل (toggle) في الواجهة حتى الآن، ولا تظهر هذه الفئات في العملاء الآخرين. ومع ذلك، فإن إصدارات Telegram Desktop ووثائق الـ API تصف منذ ربيع عام 2026 كيف يبلغ العميل الخادم عن المدة التي قضاها المنشور على الشاشة وعدد الثواني التي تم الاستماع إليها من الأغاني.
ما الذي ظهر في نسخة بيتا لنظام macOS
يتم توزيع نسخة بيتا لنظام macOS عبر تغذية التحديثات، ولا تتوفر شفرتها المصدرية للعامة. يمكن رؤية مكونات المنظومة الفرعية من خلال أسماء الأنواع في الملف التنفيذي (executable) للإصدارات (builds) — وقد ظهرت على ثلاث مراحل.
| الإصدار | التاريخ | ما أضيف |
|---|---|---|
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 |
في تحليلات المنتج، يُطلق على "مسار التحويل" (funnel) سلسلة من الخطوات نحو هدف معين، مع تحديد الخطوة التي توقف عندها المستخدم: هل فتح لوحة الملصقات، اختار، أرسل، أم أغلق. أما "المسار" (journey) فهو نفس السلسلة ضمن سيناريو واحد. من الأسماء، يمكن رؤية ثلاثة سيناريوهات: الوسائط، إعادة التوجيه، والملصقات. ويتم تتبع مصدر الانتقال إلى المتصفح المدمج (BrowserAnalyticsOrigin) والقسم الذي تم فيه فتح المعرض (GalleryAnalyticsContext) بشكل منفصل.
تصرف هذا المكون كتجربة. فبعد أقل من ساعتين من الإصدار 283338، صدر الإصدار التالي 283342 بدونه، ثم عاد في 23 أكتوبر في الإصدار 13.1.0.283362، ومنذ ذلك الحين وهو موجود — ففي إصدارات 26 أكتوبر وما بعدها، جميع الفئات موجودة.
هل يوجد مفتاح إيقاف/تشغيل؟
في الواجهة — لا يوجد. لا في سطور الملف الثنائي، ولا في حزمة الموارد، ولا في ترجمات عميل macOS، يوجد أي نص حول التحليلات، أو إحصائيات الاستخدام، أو الموافقة على جمع البيانات.
في الكود، هناك تلميح. AnalyticsPrivacy و AnalyticsRevocable، حسب الاسم، هما قواعد الخصوصية وإمكانية سحب الموافقة، و AnalyticsParameterRule هي قاعدة تحدد أي معلمات الحدث مسموح بنقلها، و AnalyticsScope هو نطاق العمل. هذه فرضية بناءً على الأسماء، بدون الكود: هكذا عادة ما يتم تنظيم التحليلات حيث يمكن للمستخدم رفض جمع البيانات، ولا يحمل الحدث حقولًا زائدة.
لا تشير الأسماء إلى أين تذهب الأحداث. في مخطط الـ API العام، توجد منذ فترة طويلة طريقة help.saveAppLog: تقبل مجموعة من الأحداث مع الوقت والنوع والمحادث والـ JSON التعسفي. يُطلق على جامع البيانات في نسخة البيتا AppLogEvent*، لكن العلاقة بينهما هي مجرد تخمين بناءً على التشابه في الاسم.
ما الذي يتم حسابه بالفعل بواسطة العملاء الصادرة
جزء من القياسات لم يعد تجربة منذ فترة طويلة. تصف وثائق الـ API طريقة messages.reportReadMetrics: يبلغ العميل الخادم عن المدة التي قضاها كل رسالة في منطقة الرؤية المرئية للدردشة (chat viewport). القواعد مفصلة بالمللي ثانية.
- لا يُحتسب العرض الأقل من 300 مللي ثانية.
time_in_view_ms— المدة التي كانت فيها الرسالة مرئية ولو ببكسل واحد.active_time_in_view_ms— جزء من هذا الوقت عندما كان الشخص نشطًا؛ يعتبر العملاء الرسميون المستخدم نشطًا لمدة 15 ثانية بعد أي إجراء.seen_range_ratio_permille— نسبة ارتفاع المنشور الذي ظهر في منطقة الرؤية المرئية، بالألف.- يتم تقسيم العروض المستمرة التي تزيد عن خمس دقائق إلى عروض منفصلة، وتتراكم القياسات حسب الدردشات وتُرسل دفعة واحدة بتأخير 5 ثوانٍ.
تصف الوثائق نفسها messages.reportMusicListen — عدد الثواني التي تم الاستماع إليها من الأغنية. يرسل Telegram Desktop كلا القياسين منذ مارس 2026: ظهر تتبع مشاهدات المنشورات و تتبع الاستماعات في الكود في نفس اليوم، 25 مارس.
تُجيب هذه القياسات على سؤال "ما الذي يُقرأ ويُستمع إليه"، بينما تُجيب المنظومة الفرعية الجديدة على سؤال "كيف يُستخدم التطبيق نفسه". الأول يتعلق بالقنوات والمحتوى، والثاني يتعلق بالشاشات والأزرار والسيناريوهات.
قياسات الشبكة (Network Telemetry) والمحرك المكتوب بلغة 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» إلى أن أعطاله تُسجل بشكل منفصل.
تخزن قياسات الشبكة التأخيرات والانقطاعات وفئات الأخطاء، بينما يسجل المحرك التسجيلي الطلبات والاستجابات لأي من المكدسين. يبدو هذا معًا وكأنه منصة اختبار لمقارنة كود الشبكة القديم بالجديد على حركة المرور الحية (live traffic). لا توجد طريقة في المخطط ترسل قياسات الشبكة إلى الخادم — قد تبقى التقارير محلية.
أين لا يوجد هذا
في نسخة بيتا من Telegram لنظام Android 13.2.0 بتاريخ 27 أكتوبر، لا يوجد أي من Analytics* أو NetworkTelemetry. كل ما يُسمى analytics و telemetry هناك ينتمي إلى مكتبات Google المدمجة: Cast، Play Services، و Firebase Crashlytics. طريقة reportReadMetrics موصوفة في كود Android، لكن لا يظهر استدعاؤها في نسخة البيتا.
في Telegram Desktop، لا توجد تحليلات للمنتج أيضًا — هناك فقط تتبع مشاهدات المنشورات والاستماعات للأغاني، الموصوفة أعلاه.
