Real User Monitoring چیست؟ Real User Monitoring یا RUM، اندازه‌گیری عملکرد و خطای محصول از نشست‌های واقعی کاربران در دستگاه، مرورگر، شبکه و موقعیت‌های مختلف است. برخلاف تست آزمایشگاهی که محیطی کنترل‌شده دارد، RUM توزیع تجربه واقعی را نشان می‌دهد. معیارهایی مانند LCP، INP و CLS باید همراه با خطا، نسخه، صفحه، سگمنت و پیامد محصول تحلیل شوند تا به اقدام قابل‌اولویت برسند.
RUM چیست و چه داده‌ای جمع می‌کند؟
RUM با یک SDK یا کد اندازه‌گیری در محصول، داده‌هایی را هنگام استفاده واقعی ثبت می‌کند. داده می‌تواند شامل زمان بارگذاری، تعامل، تغییر چیدمان، درخواست شبکه، خطا، route، نوع دستگاه و نسخه باشد. باید فقط اطلاعات لازم جمع شود و محتوای حساس حذف یا ماسک شود.
IBM، RUM را نظارت غیرفعال بر تعامل کاربران واقعی با برنامه معرفی می‌کند؛ New Relic و Datadog نیز بر مشاهده عملکرد frontend، شبکه، خطا و تجربه کاربران واقعی تأکید دارند. تعریف RUM در IBM، راهنمای RUM در New Relic و Real User Monitoring در Datadog
تفاوت RUM، Synthetic Monitoring و Lab Test
| روش | محیط | مزیت | محدودیت |
|---|---|---|---|
| RUM | کاربر واقعی | تنوع دستگاه، شبکه، مسیر و نسخه | کنترل کمتر و نیاز به ترافیک |
| Synthetic | ربات و سناریوی زمان‌بندی‌شده | پایش مداوم و قابل‌تکرار | نماینده همه کاربران نیست |
| Lab Test | محیط کنترل‌شده توسعه/CI | تشخیص و بازتولید سریع | تنوع واقعی را پوشش نمی‌دهد |
| Load Test | بار شبیه‌سازی‌شده backend | ظرفیت و رفتار زیر فشار | تجربه frontend واقعی نیست |
این روش‌ها مکمل‌اند. Lab برای پیشگیری و تشخیص، synthetic برای دسترس‌پذیری، load برای ظرفیت و RUM برای پیامد واقعی مناسب است. یک مسئله RUM را در lab بازتولید و اصلاح را دوباره در میدان تأیید کنید.
Core Web Vitals چیست؟
Core Web Vitals مجموعه‌ای از معیارهای میدانی گوگل برای کیفیت تجربه صفحه است. در وضعیت فعلی مستندات رسمی:
- LCP یا Largest Contentful Paint: سرعت نمایش بزرگ‌ترین محتوای اصلی. آستانه «خوب» حداکثر ۲٫۵ ثانیه.
- INP یا Interaction to Next Paint: پاسخ‌گویی کلی صفحه به تعامل‌ها. آستانه «خوب» حداکثر ۲۰۰ میلی‌ثانیه.
- CLS یا Cumulative Layout Shift: ثبات بصری. آستانه «خوب» حداکثر ۰٫۱.
برای ارزیابی، صدک ۷۵ بارگذاری‌های صفحه و تفکیک موبایل/دسکتاپ توصیه می‌شود. راهنمای رسمی Web Vitals
این آستانه‌ها هدف مهندسی مفیدند، اما همه تجربه را خلاصه نمی‌کنند. خطای پرداخت، پاسخ API، در دسترس‌بودن و هدف کاربر نیز مهم‌اند. گوگل Core Web Vitals را بخشی از سیگنال‌های تجربه صفحه می‌داند و توصیه می‌کند سایت در کل تجربه مناسب ارائه کند. Core Web Vitals در Google Search
LCP را چگونه تحلیل کنیم؟
LCP زمان نمایش بزرگ‌ترین تصویر یا بلوک متن قابل‌مشاهده در viewport را می‌سنجد. عنصر LCP می‌تواند با صفحه و دستگاه فرق کند. برای تحلیل، خود عنصر، Time to First Byte، زمان کشف resource، زمان دانلود و تأخیر رندر را جدا کنید.
علت‌های رایج:
- پاسخ کند سرور یا cache نامناسب.
- تصویر hero بزرگ و بدون اندازه/فرمت مناسب.
- resource مهم که دیر در HTML کشف می‌شود.
- CSS یا JavaScript مسدودکننده رندر.
- فونت و hydration طولانی.
- lazy-loading اشتباه روی محتوای بالای صفحه.
فقط کم‌کردن اندازه فایل کافی نیست. اگر تصویر پس از اجرای JavaScript کشف شود، بهینه‌سازی شبکه محدود خواهد بود. breakdown و waterfall لازم است.
INP را چگونه تحلیل کنیم؟
INP latency تعامل‌های کلیک، لمس و کیبورد را در طول حضور کاربر خلاصه می‌کند و معمولاً یکی از کندترین تعامل‌ها را نمایندگی می‌کند. تأخیر از سه بخش می‌آید: input delay، processing duration و presentation delay.
علت‌های رایج:
- task طولانی JavaScript که main thread را اشغال کرده است.
- handler سنگین یا محاسبه هم‌زمان.
- رندر و reconciliation بزرگ.
- DOM بسیار پیچیده.
- اسکریپت‌های ثالث.
- به‌روزرسانی بصری پرهزینه پس از تعامل.
برای اقدام، interaction target و route را ثبت کنید. «INP سایت بد است» قابل‌اجرا نیست؛ «تعامل بازکردن فیلتر در صفحه فهرست روی موبایل میان‌رده، processing طولانی دارد» روشن‌تر است.
Rage Click ممکن است با پاسخ کند همراه باشد، اما رابطه باید بررسی شود. راهنمای Rage Click و Dead Click روش اتصال سیگنال و عملکرد را توضیح می‌دهد. (لینک پیشنهادی پس از انتشار)
CLS را چگونه تحلیل کنیم؟
CLS جابه‌جایی‌های غیرمنتظره عناصر را در طول عمر صفحه جمع‌بندی می‌کند. تغییر پس از تعامل کاربر ممکن است expected باشد و در محاسبه رفتار متفاوتی داشته باشد. هدف، جلوگیری از حرکت ناخواسته‌ای است که باعث گم‌کردن جای خواندن یا کلیک اشتباه می‌شود.
علت‌های رایج:
- تصویر یا iframe بدون ابعاد رزروشده.
- تبلیغ یا بنر که فضای قبلی ندارد.
- فونت با تفاوت متریک زیاد.
- محتوای async که بالای محتوای موجود درج می‌شود.
- انیمیشن با property نامناسب.
- بنر رضایت یا اعلان که layout را جابه‌جا می‌کند.
در بازپخش مرتبط بررسی کنید آیا جابه‌جایی واقعاً روی هدف اثر گذاشته است. یک CLS عددی می‌تواند با کلیک اشتباه، خروج یا نارضایتی همراه باشد.
چرا صدک مهم‌تر از میانگین است؟
میانگین می‌تواند تجربه بد یک اقلیت مهم را پنهان کند. اگر بیشتر کاربران سریع و گروهی روی دستگاه ضعیف بسیار کند باشند، میانگین تصویری نرم می‌سازد. صدک ۷۵ می‌گوید ۷۵ درصد تجربه‌ها بهتر یا برابر آن مقدار بوده‌اند.
فقط یک صدک نیز کافی نیست. p50، p75 و p95 را برای تشخیص tail ببینید. p95 بد ممکن است گروه کوچک اما ارزشمند یا محیط فنی خاص را نشان دهد. حجم نمونه و بازه را همراه عدد نمایش دهید.
طراحی داده RUM
شناسه و زمینه
route، نسخه برنامه، release، نوع دستگاه، مرورگر، network class در صورت دسترس و سگمنت محصولی حداقلی را ثبت کنید. از fingerprinting یا ترکیب ویژگی‌های غیرضروری پرهیز کنید.
رویدادهای عملکرد
Core Web Vitals، navigation timing، resourceهای کلیدی، long task، خطای JavaScript و درخواست‌های API پرارزش را اندازه بگیرید. ثبت همه resourceها برای همه نشست‌ها می‌تواند پرهزینه باشد؛ نمونه‌گیری و allowlist بسازید.
اتصال به رفتار
performance باید به pageview و هدف محصول متصل شود. آیا کاربر پس از LCP ضعیف فرم را شروع کرد؟ آیا INP ضعیف نزدیک دکمه پرداخت با retry همراه بود؟ اتصال تحلیل رفتار کاربران به RUM، اولویت را روشن می‌کند. (لینک پیشنهادی پس از انتشار)
حریم خصوصی
URL ممکن است query حاوی داده حساس داشته باشد. آن را پاک‌سازی کنید. متن خطا، breadcrumb و request body را قبل از ارسال redaction کنید. نقش‌ها، نگهداری و حذف را تعریف کنید.
فرایند تحلیل RUM از هشدار تا اقدام
گام اول: SLO یا بودجه تجربه تعریف کنید
برای مسیر و سگمنت، هدف و آستانه بنویسید: p75 LCP موبایل لندینگ، نرخ خطای پرداخت یا p95 زمان API. آستانه را با هدف کاربر و خط پایه تنظیم کنید.
گام دوم: روند و تغییر را ببینید
نسخه، deploy، feature flag، کمپین و تغییر زیرساخت را annotation کنید. جهش پس از انتشار نقطه شروع قوی است؛ روند تدریجی می‌تواند از رشد bundle یا ترکیب دستگاه باشد.
گام سوم: مسئله را سگمنت‌بندی کنید
- route یا template.
- دستگاه و viewport.
- مرورگر و نسخه.
- release و variant.
- کشور/منطقه در سطح لازم.
- نوع شبکه در صورت داده معتبر.
- کاربران جدید/بازگشتی.
- مرحله قیف یا outcome.
از cardinality بسیار بالا پرهیز کنید. شناسه فردی در داشبورد عملکرد معمولاً لازم نیست.
گام چهارم: دامنه و پیامد را بسنجید
چند تجربه درگیر است؟ آیا نرخ تبدیل یا خطا در bucket کند متفاوت است؟ مقایسه observational است؛ کاربران شبکه کند ممکن است ویژگی‌های دیگری نیز داشته باشند. از آن برای اولویت و فرضیه استفاده کنید، نه ادعای قطعی.
گام پنجم: نمونه مرتبط را بررسی کنید
trace، waterfall، خطا و در صورت مجاز بازپخش را از همان release ببینید. Session Replay می‌تواند نشان دهد metric فنی چگونه در تجربه ظاهر شده، به شرط حریم خصوصی. (لینک پیشنهادی پس از انتشار)
گام ششم: در محیط کنترل‌شده بازتولید کنید
دستگاه، throttling، cache state و مسیر مشابه بسازید. profiling و coverage علت را پیدا می‌کند. RUM محل و دامنه؛ lab علت فنی را دقیق‌تر می‌سازد.
گام هفتم: اصلاح را مرحله‌ای منتشر کنید
Feature Flag یا rollout درصدی ریسک را کنترل می‌کند. معیار فنی و محصولی را هم‌زمان پایش کنید. راهنمای A/B Test و Feature Flag تفاوت rollout سلامت و آزمایش اثر را شرح می‌دهد. (لینک پیشنهادی پس از انتشار)
گام هشتم: نتیجه را در میدان تأیید کنید
بهبود Lighthouse روی یک دستگاه کافی نیست. همان route، سگمنت و صدک را پس از رسیدن داده کافی مقایسه کنید و تغییر ترکیب ترافیک را لحاظ کنید.
مثال فرضی: افت تبدیل لندینگ موبایل
نرخ شروع فرم روی موبایل کم شده است. RUM نشان می‌دهد p75 LCP در نسخه جدید بالا رفته و عنصر LCP تصویر hero است. waterfall نشان می‌دهد تصویر پس از hydration کشف می‌شود. هیت‌مپ اسکرول تغییر چشمگیری ندارد، اما بازپخش‌ها تأخیر نمایش بخش اصلی را نشان می‌دهند.
تیم تصویر را در HTML اولیه قابل‌کشف، ابعاد و فرمت را بهینه و preload را فقط در صورت مناسب اعمال می‌کند. rollout محدود انجام می‌شود. معیار اصلی p75 LCP همان template؛ شاخص محصول شروع فرم؛ نگهبان bandwidth و خطای تصویر است. اگر عملکرد بهتر و رفتار ثابت بماند، باز هم اصلاح فنی ارزش دارد، اما ادعای افزایش تبدیل بدون طراحی مناسب نمی‌شود.
مثال فرضی: پاسخ کند فیلتر محصول
INP کلی سایت خوب به‌نظر می‌رسد، اما p95 صفحه فهرست روی دستگاه میان‌رده بد است. interaction attribution نشان می‌دهد بازکردن فیلتر task طولانی دارد. بازپخش‌ها کلیک تکراری و بسته/بازشدن ناخواسته را نشان می‌دهند.
profiling آشکار می‌کند کل فهرست هنگام هر تغییر دوباره رندر می‌شود. تیم state و rendering را محدود می‌کند. نتیجه با INP interaction، نرخ Rage Click، خطا و استفاده موفق فیلتر سنجیده می‌شود. این رویکرد از «بهینه‌سازی عمومی JavaScript» به اقدام دقیق می‌رسد.
RUM برای SPA و Next.js
در Single-Page Application، navigation کامل مرورگر برای هر route رخ نمی‌دهد. تغییر route، hydration، data fetching و soft navigation باید جدا ثبت شود. LCP استاندارد در navigation اولیه تعریف روشن‌تری دارد؛ برای route داخلی معیارهای سفارشی مانند زمان تا محتوای قابل‌استفاده را با نام متفاوت ثبت کنید و آن را «LCP» ننامید مگر مطابق استاندارد باشد.
در SSR/Next.js، TTFB، hydration، chunk، image optimization و cache می‌توانند بخش‌های متفاوت را تحت‌تأثیر قرار دهند. release و route template را نگه دارید. خطاهای client و server را با trace یا correlation ID غیرحساس متصل کنید.
عملکرد اسکریپت‌های تحلیل
خود ابزار RUM، بازپخش یا تبلیغات می‌تواند هزینه داشته باشد. بودجه اسکریپت ثالث، بارگذاری async، نمونه‌گیری و دامنه ثبت را کنترل کنید. ادعای «بدون اثر» را فقط با داده واقعی می‌توان سنجید و معمولاً مطلق نیست.
آزمایش قبل/بعد را روی دستگاه‌های ضعیف و RUM انجام دهید. اگر ابزار همه mutationها یا resourceها را ثبت می‌کند، pageهای سنگین را جدا بررسی کنید.
طراحی داشبورد RUM قابل‌اقدام
یک داشبورد کوچک بهتر از ده‌ها نمودار بدون مالک است:
| بخش | نمایش |
|---|---|
| سلامت کل | p75 LCP/INP/CLS، نرخ خطا و حجم |
| مسیر حیاتی | ثبت‌نام، Checkout یا فعال‌سازی |
| سگمنت | موبایل، مرورگر، نسخه و template |
| پیامد | نرخ تکمیل و retry در bucketهای تجربه |
| تغییر | release و feature flag annotation |
| اقدام | مالک، severity، لینک trace و وضعیت |
هشدار را بر افزایش پایدار، حجم کافی و مسیر مهم تنظیم کنید. alert روی هر نوسان fatigue می‌سازد.
اولویت‌بندی بهبود عملکرد
چهار عامل را ترکیب کنید:
- دامنه: چند کاربر و چه سهمی؟
- شدت: چقدر از آستانه یا خط پایه دور است؟
- پیامد: آیا هدف یا خطا درگیر است؟
- تلاش و ریسک: اصلاح چه هزینه و blast radius دارد؟
کاهش ۵۰۰ میلی‌ثانیه در صفحه کم‌ترافیک ممکن است از رفع timeout پرداخت کم‌اهمیت‌تر باشد. از سوی دیگر، بهبود یک template مشترک می‌تواند دامنه وسیع داشته باشد.
اشتباه‌های رایج
فقط Lighthouse
Lab ضروری است، اما تجربه واقعی را کامل نشان نمی‌دهد. RUM و synthetic را اضافه کنید.
فقط میانگین
صدک و توزیع را ببینید. اقلیت کند ممکن است پنهان شود.
جمع‌کردن همه صفحه‌ها
template و route را جدا کنید. صفحه مقاله و Checkout هدف و منابع متفاوت دارند.
اتصال ساده عملکرد به تبدیل
هم‌بستگی ممکن است از دستگاه، شبکه یا کانال باشد. برای استنباط اثر، طراحی آزمایش یا کنترل دقیق‌تر لازم است.
هشدار بدون مالک
هر alert باید runbook، severity، مالک و معیار بسته‌شدن داشته باشد.
ثبت داده حساس در خطا
URL، stack context و request را redaction کنید. جزئیات بیشتر همیشه لازم نیست.
بهینه‌سازی یک عدد با آسیب دیگر
حذف محتوا شاید LCP را بهتر ولی ارزش صفحه را کمتر کند. معیار محصول و دسترس‌پذیری را نگهبان قرار دهید.
چک‌لیست راه‌اندازی RUM
- مسیرهای حیاتی و هدف کاربر را مشخص کنید.
- Core Web Vitals را با نسخه استاندارد کتابخانه ثبت کنید.
- release، route و دستگاه را به‌صورت حداقلی اضافه کنید.
- خطا و API پرارزش را instrument کنید.
- URL و متن حساس را پیش از ارسال پاک‌سازی کنید.
- sampling و هزینه داده را تعیین کنید.
- p50، p75 و p95 را کنار حجم ببینید.
- موبایل و دسکتاپ را جدا کنید.
- deploy و flag را annotation کنید.
- معیار عملکرد را به قیف و outcome متصل کنید.
- مسئله را در lab بازتولید کنید.
- اصلاح را مرحله‌ای و با rollback منتشر کنید.
- نتیجه را پس از داده کافی در RUM تأیید کنید.
- تعریف، مالک و runbook هشدار را مستند کنید.
از میلی‌ثانیه تا تصمیم محصول
RUM زمانی مفید است که معیار فنی به کاربر، مسیر و پیامد متصل شود. یک صدک بد باید به سگمنت، release و علت فنی برسد؛ سپس اصلاح در میدان تأیید شود.
آلفانا پایش عملکرد، خطا و رفتار را کنار بازپخش نشست، قیف و سگمنت قرار می‌دهد تا تیم بتواند تجربه واقعی را با نتیجه محصول بسنجد. جزئیات SDK و قابلیت‌های فعلی در مستندات آلفانا آمده است.
اقدام پیشنهادی: یک مسیر حیاتی موبایل را انتخاب کنید و p75 Core Web Vitals، نرخ خطا و تکمیل هدف آن را در یک نمای مشترک قرار دهید.
مرز داده قطعی و تفسیر در Real User Monitoring چیست
برای تفسیر Real User Monitoring چیست، سه سطح را جدا نگه دارید: داده مشاهده‌شده، برداشت تحلیلی و ادعای علّی. وقتی این مرز نوشته شود، تیم می‌فهمد کدام بخش قابل بازتولید است و کدام بخش هنوز به شاهد تازه نیاز دارد.
| نوع گزاره | نمونه بیان درست | اقدام بعدی |
|---|---|---|
| داده مشاهده‌شده | در این بازه و برای این سگمنت، رویداد یا الگوی مشخص ثبت شده است. | تعریف، مخرج، نسخه و سلامت ورودی را کنترل کنید. |
| تفسیر | این الگو می‌تواند با اصطکاک، پیام نامتناسب یا محدودیت فنی مرتبط باشد. | شواهد مستقل و توضیح‌های جایگزین را بررسی کنید. |
| ادعای علّی | فقط طراحی مناسب آزمایش یا شواهد کافی می‌تواند اثر مداخله را پشتیبانی کند. | معیار نتیجه و شاخص نگهبان را پیش از اجرا ثبت کنید. |
مزایا و محدودیت‌های Real User Monitoring چیست
کاربرد Real User Monitoring چیست وقتی پررنگ می‌شود که تیم بتواند از مشاهده به اقدام برسد. همین سرعت اگر بدون کنترل داده، سگمنت و پیامد پایین‌دست باشد، می‌تواند اعتماد کاذب بسازد؛ بنابراین مزیت و محدودیت را هم‌زمان ببینید.
| جنبه | مزیت عملی | محدودیت و کنترل لازم |
|---|---|---|
| تمرکز بر رفتار واقعی | فاصله میان گزارش کلی و تجربه مسیر را کمتر می‌کند. | رفتار مشاهده‌شده قصد قطعی کاربر را ثابت نمی‌کند؛ زمینه و شاهد مکمل لازم است. |
| سگمنت‌بندی | میانگین پنهان‌کننده تفاوت دستگاه، کانال یا مرحله عمر را آشکار می‌کند. | گروه بسیار کوچک یا انتخاب پس از دیدن نتیجه می‌تواند برداشت ناپایدار بسازد. |
| قابلیت اقدام | یافته را به فرضیه، مالک و معیار بازبینی متصل می‌کند. | بدون شاخص نگهبان، بهبود یک مرحله ممکن است تجربه پایین‌دست را بدتر کند. |
| سرعت یادگیری | مسئله‌های پراثر را پیش از بازطراحی گسترده محدود می‌کند. | سرعت نباید جای کنترل کیفیت، حریم خصوصی یا بررسی علت‌های جایگزین را بگیرد. |
پرسش‌های متداول درباره Real User Monitoring چیست
RUM چیست؟
پایش عملکرد و خطا از نشست‌های واقعی کاربران است. این روش تنوع دستگاه، شبکه، مرورگر و مسیر را نشان می‌دهد و برای اولویت‌بندی تجربه میدانی به‌کار می‌رود. اگر شواهد کافی نیست، نتیجه را فرضیه بنامید و با یک اقدام محدود، شاخص نگهبان و تاریخ بازبینی دوباره بسنجید.
تفاوت RUM و APM چیست؟
RUM بیشتر تجربه frontend کاربر را می‌بیند؛ APM عملکرد سرویس و backend را. اتصال trace و correlation کمک می‌کند تعامل کند تا سرویس مربوط دنبال شود. مرز ابزارها ممکن است هم‌پوشانی داشته باشد. زمینه محصول، دستگاه، منبع ورود و محدودیت حریم خصوصی می‌تواند تفسیر را تغییر دهد؛ بنابراین نسخه واحد برای همه کسب‌وکارها وجود ندارد.
Core Web Vitals شامل چه معیارهایی است؟
در مستندات فعلی LCP برای بارگذاری، INP برای پاسخ‌گویی و CLS برای ثبات بصری. آستانه‌های خوب به‌ترتیب ۲٫۵ ثانیه، ۲۰۰ میلی‌ثانیه و ۰٫۱ در صدک ۷۵ هستند. پیش از اقدام، تعریف Real User Monitoring چیست، مخرج، بازه زمانی و کیفیت داده را ثبت کنید تا نتیجه قابل بازبینی باشد.
آیا Core Web Vitals عامل رتبه‌بندی است؟
گوگل آن‌ها را در سیگنال‌های تجربه صفحه استفاده می‌کند، اما نتیجه جست‌وجو فقط به این سه عدد وابسته نیست. محتوای مفید، ارتباط و سایر عوامل نیز مهم‌اند. تجربه را برای کاربر بهبود دهید، نه برای امتیاز منفرد. اگر شواهد کافی نیست، نتیجه را فرضیه بنامید و با یک اقدام محدود، شاخص نگهبان و تاریخ بازبینی دوباره بسنجید.
داده RUM چقدر لازم دارد؟
به ترافیک، سگمنت و پایداری معیار بستگی دارد. حجم و فاصله عدم‌قطعیت را گزارش کنید. برای صفحه کم‌ترافیک، synthetic و بازه طولانی‌تر مکمل‌اند. زمینه محصول، دستگاه، منبع ورود و محدودیت حریم خصوصی می‌تواند تفسیر را تغییر دهد؛ بنابراین نسخه واحد برای همه کسب‌وکارها وجود ندارد.
آیا RUM سرعت سایت را کم می‌کند؟
SDK هزینه‌ای دارد که به قابلیت و تنظیمات وابسته است. بارگذاری، حجم، پردازش و اثر را اندازه بگیرید؛ نمونه‌گیری و ثبت هدفمند را اعمال کنید. پیش از اقدام، تعریف Real User Monitoring چیست، مخرج، بازه زمانی و کیفیت داده را ثبت کنید تا نتیجه قابل بازبینی باشد.
آیا RUM جایگزین تست قبل از انتشار است؟
خیر. RUM مشکلات میدان را پیدا می‌کند، اما QA، performance budget، test lab، synthetic و load test برای پیشگیری لازم‌اند. اگر شواهد کافی نیست، نتیجه را فرضیه بنامید و با یک اقدام محدود، شاخص نگهبان و تاریخ بازبینی دوباره بسنجید.
بدون دیدگاه