از ماه اکتبر، زیرسیستم Product Analytics در نسخه بتا تلگرام برای macOS در حال توسعه است. این زیرسیستم، نمایش صفحهها (screen views)، رویدادها در منوها و تنظیمات، قیفهای (funnels) با نتایج نهایی، و مسیرهای کاربر (user journeys) از طریق رسانهها، فوروارد کردن و استیکرها را ردیابی میکند. در کنار آن، قوانین حریم خصوصی و رضایت قابل لغو (revocable consent) نیز وجود دارد. هنوز هیچ سوئیچ (toggle) برای آن در رابط کاربری وجود ندارد و این کلاسها در سایر کلاینتها دیده نمیشوند. با این حال، Telegram Desktop منتشر شده و مستندات API از بهار ۲۰۲۶ توضیح میدهند که چگونه کلاینت به سرور گزارش میدهد که یک پست چه مدت در صفحه نمایش بوده و چه مقدار از یک آهنگ گوش داده شده است.
چه چیزهایی در نسخه بتا برای macOS اضافه شده است
نسخه بتا macOS از طریق فید بهروزرسانیها توزیع میشود؛ کدهای منبع آن به صورت عمومی در دسترس نیستند. ترکیب این زیرسیستم از طریق نامهای انواع (type names) در فایل اجرایی (executable) بیلدها قابل مشاهده است — این موارد در سه مرحله اضافه شدهاند.
| بیلد | تاریخ | چه چیزهایی اضافه شد |
|---|---|---|
| 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 |
در Product Analytics، قیف (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 مارس، در یک روز به کد اضافه شدند.
این اندازهگیریها به سؤال «چه چیزی خوانده و گوش داده میشود» پاسخ میدهند، در حالی که زیرسیستم جدید به سؤال «چگونه از خود برنامه استفاده میشود» پاسخ میدهد. اولی مربوط به کانالها و محتوا است، دومی مربوط به صفحهها، دکمهها و سناریوها.
تلهمتری شبکه و موتور 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» نشان میدهند که خطاهای آن به طور جداگانه ثبت میشوند.
تلهمتری تأخیرها، قطعیها و کلاسهای خطا را ذخیره میکند، و موتور ضبطکننده درخواستها و پاسخهای هر یک از دو پشته را مینویسد. در مجموع، این به نظر میرسد یک تست بنچ (test bench) برای مقایسه کد شبکه قدیمی با کد جدید در ترافیک زنده (live traffic) باشد. متدی که تلهمتری شبکه را به سرور ارسال کند، در طرح وجود ندارد — گزارشها ممکن است محلی باقی بمانند.
کجا این قابلیتها وجود ندارند
در نسخه بتا Telegram برای Android 13.2.0 مورخ 27 اکتبر، نه Analytics* و نه NetworkTelemetry وجود ندارد. هر آنچه در آنجا analytics و telemetry نامیده میشود، متعلق به کتابخانههای داخلی Google است: Cast، Play Services و Firebase Crashlytics. متد reportReadMetrics در کد Android توضیح داده شده است، اما فراخوانی آن در نسخه بتا دیده نمیشود.
در Telegram Desktop نیز Product Analytics وجود ندارد — در آنجا فقط ردیابی بازدیدهای پستها و گوش دادن به آهنگها که در بالا توضیح داده شد، موجود است.




