گزارش Core Web Vitals در دنیای گوگل و سرچ کنسول نشون می‌ده عملکرد صفحه‌هات چجوریه، اونم بر اساس داده‌های دنیای واقعی (یا همون تجربه کاربرای واقعی)
چرا عملکرد صفحه مهمه؟
تحقیقات نشون دادن که Core Web Vitals بهتر باعث میشن کاربرا بیشتر باهات درگیر بشن و آمار و ارقام سایتت بهتر بشه. مثلا:
۱. وقتی یه سایت معیارهای Core Web Vitals رو داره، مطالعه‌ها نشون دادن که کاربرا ۲۴٪ کمتر احتمال داره وسط بارگذاری از صفحه بزنن بیرون.
۲. برای Farfetch با هر ۱۰۰ میلی‌ثانیه کاهش تو زمان Largest Contentful Paint (LCP)، نرخ تبدیل وب ۱٫۳٪ بیشتر شده.
۳. کم کردن Cumulative Layout Shift (CLS) به میزان ۰٫۲ باعث شد Yahoo! JAPAN به ازای هر سشن شاهد افزایش ۱۵٪ بازدید صفحه، بالا رفتن ۱۳٪ مدت اون بازدیدها، و کاهش ۱٫۷۲٪ بانس ریت (نرخ پرش) باشه.
۳. Netzwelt تونست Core Web Vitals رو بهبود ببخشه و شاهد رشد ۱۸٪ درآمد تبلیغات و افزایش ۲۷٪ بازدید صفحه شد.
۴. redBus وقتی CLS رو از ۱٫۶۵ به صفر رسوند، رتبه دامینش حسابی بالا رفت.
فهم گزارش Core Web Vitals
گزارش Core Web Vitals نشون می‌ده وضعیت آدرس صفحه‌هات چطوریه، اونم بر اساس:
- وضعیت (ضعیف، نیاز به بهبود، خوب) یا (Poor, Need improvement, Good)
- نوع معیار (CLS، FID، INP، LCP)
- گروه آدرس یا URL group (گروه‌هایی از صفحات وب مشابه)
این گزارش بر اساس چهار تا معیار اصلیه که با داده‌های کاربرای واقعی سنجیده میشن: LCP، FID، INP، CLS. وقتی یه گروه از صفحه‌ها به حد کافی برای LCP و CLS داده داشته باشه، وضعیت کلی گروه بر اساس بدترین معیارش مشخص میشه. مثلا اگه یه گروه CLS ضعیفی داشته باشه، ولی FID خوبی داشته باشه، وضعیت کلی گروه «ضعیف» در نظر گرفته میشه.
اگه یه گروه به حد کافی دادهٔ گزارش‌گیری برای LCP و CLS نداشته باشه، اون گروه توی گزارش نمیاد.
فقط صفحاتی که گوگل ایندکس کرده می‌تونن توی این گزارش باشن. داده‌ها به آدرس صفحهٔ واقعی ربط داده میشن، نه آدرس کانونیکال (قانونی)، که این با اکثر گزارش‌های دیگه فرق داره.
یادآور: داده‌ها از همهٔ درخواست‌ها از هر جایی از دنیا ترکیب شدن. اگه بخش مهمی از بازدیدکننده‌هات از کشوری میان که سرعت اینترنتش کنده، طبیعتا عملکرد کلیت میاد پایین. می‌تونی با استفاده از BigQuery عملکردت رو به تفکیک کشور نگاه کنی، اگه فکر می‌کنی این مشکل ممکنه تاثیر داشته باشه.
INP (Interaction to Next Paint) یه معیار جدیده که سال ۲۰۲۴ قراره جای FID (First Input Delay) رو به عنوان یکی از Core Web Vitals بگیره. فعلا که INP بخشی از Core Web Vitals نیست، ولی سرچ کنسول داره داده‌های INP رو گزارش میکنه که بهت کمک کنه آماده بشی.
«اطلاعات در دسترس نیست» «No data available»
اگه با صفحهٔ «اطلاعات در دسترس نیست» مواجه شدی، یعنی یا سایتت توی سرچ کنسول جدیده، یا تو گزارش CrUX اطلاعات کافی برای دستگاهی که انتخاب کردی (دسکتاپ یا موبایل) وجود نداره.
اگه سایتت جدیده: دیتابیس CrUX همیشه داره از آدرس‌های اینترنتی اطلاعات جمع میکنه، چه اون آدرس بخشی از سایت‌های ثبت شده در سرچ کنسول باشه یا نه. ولی خب بعد از اینکه سایتت رو ثبت کردی، ممکنه چند روز طول بکشه تا هر اطلاعاتی که از قبل تو CrUX بوده بررسی و ثبت بشن.
می‌تونی برای هر آدرسی که می‌خوای، تست سرعت رو با یکی از این ابزارا انجام بدی:
۱. ابزار تست PageSpeed Insights
۲. ابزار Chrome Lighthouse
۳. ابزار AMP Page Experience Guide (برای صفحات AMP)
چطوری تو گزارش بگردیم
تو گزارش، برای هر دستگاه (موبایل یا دسکتاپ)، یک جدول میبینی که نشون می‌ده کدوم آدرس‌های سایت وضعیتشون «ضعیفِ» یا «نیاز به بهبود» داره «Poor or Need improvement» (تو قسمت «چرا آدرس‌ها خوب محسوب نمی‌شن» یا Why URLs aren’t considered good). یه جدول دیگه‌ام هست که آدرس‌هایی رو لیست میکنه که وضعیت همهٔ معیارهاشون خوبه (LCP, FID, INP, CLS). (تو قسمت «View data about good URLs»).
- می‌تونی خلاصه آمار کلی مربوط به هر دو دستگاه رو توی صفحه اصلی ببینی.
- می‌خوای فقط آمار موبایل یا دسکتاپ رو ببینی؟ روی «Open report» کنار یکی از نمودارها کلیک کن.
- برای اینکه ببینی آدرس‌های مختلف سایتت چجوری عمل می‌کنن (بر اساس داده‌هایی که از کاربرای واقعی جمع شده)، بین زبانه‌های Poor, Need improvement, یا Good tabs بالای نمودارها جابه‌جا شو.
- می‌تونی لیست مشکلات عملکردی رو تو قسمت «Why URLs aren’t considered good» ببینی. هر آدرسی که اونجا نوشته شده، نمونه‌ای از یک گروه از آدرس‌های مشابه هست.
- روی یکی از آدرس‌ها توی قسمت «Examples» کلیک کن تا دربارهٔ اون گروه از آدرس‌ها اطلاعات بیشتری ببینی.
پیدا کردن وضعیت یک آدرس مشخص
این گزارش برای این درست نشده که بتونی وضعیت یک آدرس خاص رو پیدا کنی. هدف اصلیش اینه که بتونی یه نگاه کلی به عملکرد سایتت داشته باشی و مشکلاتی رو ببینی که ممکنه روی چندین صفحه تاثیر بذارن. اگه می‌خوای اطلاعات تک تک آدرس‌ها رو ببینی، باید از ابزارهای دیگه استفاده کنی. البته می‌تونی با فیلتر کردن وضعیت، لیستی از آدرس‌هایی که مشکل دارن رو ببینی، ولی خب پیدا کردن یک آدرس مشخص با گزارش Core Web Vitals می‌تونه سخت باشه.
اطلاعات گزارش از کجا میان؟
داده‌ها و اطلاعات گزارش Core Web Vitals از گزارش CrUX میاد. گزارش CrUX اطلاعات عملکرد رو از کاربرای واقعی که از صفحه‌ت بازدید کردن جمع میکنه (بهش می‌گن دادهٔ میدانی). دیتابیس CrUX همیشه داره از آدرس‌های اینترنتی اطلاعات جمع میکنه، چه اون آدرس بخشی از سایت‌های ثبت شده در سرچ کنسول باشه یا نه.
وضعیت هر گروه: Poor, Need improvement, Good
عنوان‌های «ضعیف»، «نیاز به بهبود» و «خوب» برای هر گروه از آدرس‌ها در نظر گرفته شدن، ضمن اینکه باید نوع دستگاه رو هم در نظر داشته باشی (یعنی گروه آدرس‌ها برای موبایل با دسکتاپ فرق میکنه). اگه در مورد یک گروه، برای هر دو مورد LCP و CLS اطلاعات کافی وجود نداشته باشه، اون گروه توی گزارش دیده نمیشه (مثلا اگه فقط آمار LCP داشته باشه ولی برای CLS نداشته باشه، توی گزارش ظاهر نمیشه).
وضعیت هر گروه آدرس، به طور پیش‌فرض، کندترین وضعیتی میشه که برای اون دستگاه بهش اختصاص داده شده. مثلا:
- یه آدرس روی موبایل که وضعیت CLS رو ضعیف گزارش میکنه، ولی LCP نیاز به بهبود داره، برای موبایل وضعیت «ضعیف» در نظر گرفته میشه.
- یه آدرس روی موبایل که وضعیت LCP رو نیاز به بهبود نشون می‌ده، ولی CLS وضعیتش خوبه، برای موبایل وضعیتش «نیاز به بهبود» میشه.
- یه آدرس با وضعیت خوب برای هر چهار معیار (LCP, FID, INP, CLS) روی موبایل، ولی وضعیت نیاز به بهبود روی دسکتاپ، وضعیتش «خوب» روی موبایل و «نیاز به بهبود» روی دسکتاپ نشون داده میشه. در واقع موبایل و دسکتاپ کاملا از همدیگه تفکیک هستن و داده‌های میدانیشون هم جداگانه جمع‌آوری میشه.
وضعیت مناسب گزارش‌ها از نگاه گوگل
| معیار | Good «خوب» | Need improvement «نیاز به بهبود» | Poor «ضعیف» |
|---|---|---|---|
| LCP | کمتر از ۲.۵ ثانیه | کمتر از ۴ ثانیه | بیش از ۴ ثانیه |
| FID | کمتر از ۱۰۰ میلی ثانیه | کمتر از ۳۰۰ میلی ثانیه | بیش از ۳۰۰ میلی ثانیه |
| INP | کمتر از ۲۰۰ میلی ثانیه | کمتر از ۵۰۰ میلی ثانیه | بیش از ۵۰۰ میلی ثانیه |
| CLS | کمتر از ۰.۱ | کمتر از ۰.۲۵ | بیش از ۰.۲۵ |
توضیات بیشتر در مورد معیارهای داخل جدول
LCP یا (largest contentful paint): یعنی مدت‌زمان لازم برای اینکه بزرگترین عنصر صفحه، توی قسمتی که کاربر می‌بینه، کامل بارگذاری بشه. از لحظه‌ای که کاربر آدرس رو درخواست می‌ده، اندازه‌گیری میشه. بزرگترین عنصر معمولا یه عکس، ویدیو، یا یه تکه متن گنده‌ست. این معیار مهمه چون نشون می‌ده چقدر سریع سایت داره بارگذاری میشه (حداقل اون چیزی که توی صفحه اصلی قابل دیدنه).
«گروه LCP» که توی گزارش میبینی، یعنی برای ۷۵٪ بازدیدهای یک گروه از آدرس‌ها، این‌قدر زمان طول کشیده تا به حالت LCP برسن.
FID یا (first input delay): مدت زمانی که از اولین تعامل کاربر با صفحه‌ت (مثلا وقتی رو لینک یا دکمه‌ای کلیک میکنه) تا وقتی که مرورگر به اون واکنش نشون می‌ده، اندازه‌گیری میکنه. اندازه‌گیریش از روی اولین عنصر تعاملی که روش کلیک شده شروع میشه. این معیار خیلی مهمه، مخصوصا برای صفحاتی که کاربر می‌خواد توش کاری انجام بده. در اصل یعنی این مدت زمان، تاخیری هست که کاربر قبل از اینکه بتونه با صفحه کار کنه تجربه میکنه.
«FID گروه» توی گزارش یعنی برای ۷۵٪ بازدیدهای یک گروه از آدرس‌ها، بهتر یا مساوی با این مقدار بوده.
توضیح: ممکن هست در آینده FID در سرچ کنسول حذف بشه، یا حداقل در معیارهای اصلی نباشه.
INP یا (interaction to next paint): معیاریه که سرعت واکنش کلی سایت در برابر تعامل‌های کاربر رو بررسی میکنه. نگاه میکنه که چقد طول می‌کشه تا صفحه به همهٔ کلیک‌ها، ضربه‌ها، و حرکت‌های کلید که در طول مدت بازدید یه کاربر انجام میشه، جواب بده. مقدار INP نهایی، طولانی‌ترین تعامله که اندازه‌گیری شده، با صرف نظر کردن از موردهایی که آمار عجیبی رو نشون دادن.
«INP گروه» توی گزارش یعنی ۷۵٪ از بازدیدها از یک گروه آدرس‌ها، بهتر یا مساوی با این مقدار بودن.
CLS یا (Cumulative Layout Shift): خب CLS مجموع همهٔ نمره‌های layout shift (جابه‌جا شدن اجزا) رو برای هر تکونی که تو صفحه اتفاق می‌افته، اندازه‌گیری میکنه (هر وقت چیزایی که نباید، می‌پرن و جابه‌جا میشن!). نمرهٔ این معیار می‌تونه از صفر یا هر عدد مثبتی تشکیل بشه. صفر یعنی هیچ تکون الکی‌ای اتفاق نیافتاده و هرچی عدد بالاتر باشه، یعنی پر پر زدن‌های اتفاق افتاده بیشتر بوده. این معیار مهمه چون اینکه صفحه هی زیر دست و پای کاربر تکون بخوره تجربه بدی رو می‌سازه. بیشتر هم به خاطر اینه که CSS های درستی نوشته نشده که اندازه‌های ثابتی داخل صفحه وجود داشته باشه.
اگه دیدی این عدد زیادی بالا شده و نمی‌تونی دلیلش رو بفهمی، خودت تست کن با صفحه کار کن و ببین چطور نمرش تغییر میکنه.
«گروه CLS» که توی گزارش نوشته شده، یعنی کمترین میزان CLS که در ۷۵٪ بازدیدهای یک گروه از آدرس‌ها مشاهده شده.
برای اینکه راه حل مشکلات رو پیدا کنی، می‌تونی از تست‌های بیرون از سرچ کنسول استفاده کنی. [مثل اون ۳ تا ابزاری که داخل همین داکیومنت معرفی کردیم]
گروه‌های آدرس (URL)
توی گزارش، آدرس‌ها بر اساس تجربه کاربری که دارن، دسته‌بندی میشن. وضعیت LCP, FID, INP, CLS در مورد همهٔ آدرس‌های داخل هر گروه صدق میکنه. ممکنه توی بعضی بازدیدها، یک سری از آدرس‌ها وضعیت بهتر یا بدتری داشته باشن، ولی توی گزارش، اون وضعیتی نشون داده میشه که برای ۷۵٪ بازدیدهای همهٔ آدرس‌ها توی اون گروه ثبت شده. فرض بر اینه که این دسته از آدرس‌ها همگی از یک ساختار مشترک استفاده می‌کنن، برای همین اگه وضعیت یک گروه ضعیف باشه، با پیدا کردن ایراد اصلی احتمالا میشه مشکل رو برای کل اون گروه آدرس‌ها حل کرد.
برای اینکه حریم خصوصی کاربرا رعایت بشه، باید یه گروه از آدرس‌ها، حداقلی از داده و اطلاعات رو داشته باشه تا توی گزارش نشون داده بشه. اگه یه گروه اطلاعات کافی برای نمایش تو گزارش رو نداشته باشه، سرچ کنسول یه گروه بزرگتر تشکیل می‌ده که همه چیز رو در سطح origin نشون بده و معمولا اطلاعات کافی داره. این گروه origin شامل آمار و ارقام همهٔ آدرس‌ها با همون ساختارِ protocol://host:port هست. مثلا اگه آدرس https://m.example.com/a/b/c.html بخشی از گروهی باشه که اطلاعات کافی نداره، سرچ کنسول یه گروه مبدا (origin) به این صورت می‌سازه: https://m.example.com. این گروه مبدا آمار و اطلاعات همهٔ آدرس‌های زیرمجموعهٔ https://m.example.com رو نشون می‌ده، فرقی نداره که آدرسی به یک گروه دیگه با آمار کافی هم تعلق داشته باشه یا نه.
چندتا نکته در مورد origin group یا گروه مبدا:
- تعریف گروه مبدا شامل پروتکل هم میشه، پس http://m.il.example.com و https://m.il.example.com دوتا گروه مبدا جداگانه به حساب میان.
- گروه مبدا شامل اطلاعات و داده‌های مربوط به همهٔ آدرس‌های زیرمجموعه‌اش میشه، چه اون آدرس بخشی از یک گروه دیگه‌ای که توی گزارش نشون داده میشه باشه یا نباشه.
- اگه گروه مبدا اطلاعات کافی نداشته باشه، اون گروه (و در نتیجه کل سایت) اطلاعات کافی برای نمایش توی گزارش نخواهد داشت. مگر اینکه سایت شما چندین گروه مبدا داشته باشه.
- می‌تونی اطلاعات گروه مبدا رو ببینی، چه اون گروه بخشی از سایت فعلی‌ت باشه یا نه. ولی خب، بازم فقط می‌تونی اون آدرس‌های نمونه رو ببینی که داخل سایت فعلی‌ت باشن.
- سرچ کنسول اعضای هر گروه رو بر اساس تعداد ایمپرشن (یعنی تعداد دفعاتی که دیده شدن) مرتب میکنه.
وضعیت سایتم عوض شده، ولی من هیچی رو تغییر ندادم
اگه هیچ تغییری توی ساختار سایتت ندادی، ولی میبینی وضعیت خیلی از صفحات یهو عوض شده، احتمالا دلیلش اینه که خیلی از صفحه‌هات تقریبا روی مرز بودن و یک تغییر کوچیک هم برای کل سایت کافی بوده تا از یه وضعیت به وضعیت پایین‌تر پرتاب بشن. مثلا اگه ترافیک سایت خیلی زیاد بشه، یا سرویسی که عکس‌های سایت رو ارائه می‌ده دچار تاخیر بشه، سرعت سایتت میاد پایین، حالا یه ذره که به تاخیر قبلی اضافه بشه، باعث میشه یه عالمه از صفحه‌های «خوب» بیان زیر مرز و بشن «نیاز به بهبود» یا اصلا پرت بشن سمت «ضعیف».
یه دلیل محتمل دیگه (که البته کمتر اتفاق میفته) تغییرات بزرگ و کلی در ابزارها یا مرورگرهاییه که کاربرا ازشون برای دیدن سایتت استفاده می‌کنن. مثلا اگه مرورگر محبوبی یه آپدیت بده، یا یهو ببینی خیلی از کسایی که میان سایت، شبکه و اینترنتشون خیلی ضعیفه. یادت نره که عملکرد سایت با اطلاعاتی که در واقعیت ثبت شدن (یعنی توسط کاربرای واقعی)، اندازه‌گیری میشه. می‌تونی توی لاگ‌ها بگردی ببینی زمان تغییر وضعیت سایت، تغییر مهمی توی نوع مرورگرها، دستگاه‌هایی که استفاده شده، یا لوکیشن کاربرهایی که اومدن توی سایت، اتفاق افتاده یا نه.
ترافیک سایتت رو توی اون مدتی که وضعیتش تغییر کرده بررسی کن، بگرد ببین نوسان بزرگی داشته یا نه. همینطور یه زوم بیشتر کن روی مشکلاتی که گزارش شده و ببین مقادیر مربوط به CLS/LCP/FID/INP برای اون صفحاتی که مشکل دارن چقدره. اگه این عددها روی مرزند، احتمالش هست که حتی کوچیکترین تغییر بتونه وضعیتشون رو جابجا کنه.
تایید اصلاحات یا Validate fixes
وقتی یه مشکل یا ایراد مشخصی رو توی همهٔ آدرس‌هات درست کردی، می‌تونی بررسی کنی که آیا مشکل به طور کامل برای همه حل شده یا نه. روی «شروع ردیابی» (Start Tracking) کلیک کن تا یه دورهٔ نظارت ۲۸ روزه شروع بشه و ببینی آیا هنوز همون ایراد توی سایت اتفاق می‌افته یا نه. اگه توی اون دورهٔ ۲۸ روزه اثری از اون ایراد توی هیچکدام از آدرس‌ها دیده نشه، مشکلت به طور کامل حل شده. اگه اون ایراد حتی تو یکی از آدرس‌ها هم پیدا بشه، مسئله هنوز حل نشده در نظر گرفته میشه. البته وضعیت هر آدرس به طور جداگانه برای کل ۲۸ روز بررسی میشه، صرف نظر از اینکه وضعیت کلی در چه مرحله‌ای هست.
«شروع ردیابی» (Start tracking) باعث نمیشه گوگل آدرس رو دوباره ایندکس کنه یا کار فعال دیگه‌ای انجام بده. فقط یه بازه زمانی ۴ هفته‌ای برای نظارت و مانیتورینگ داده‌های CrUX مربوط به سایتت توسط سرچ کنسول شروع میشه (یا از اول شروع میشه).
برای اینکه جزئیات تاییدیه (validation details) رو برای یه درخواست که در حال انجامه یا تاییدیه‌ش رد شده ببینی:
- توی بخش توضیحات ایراد یا همون issue details، روی «جزئیات رو ببین» (See details) کلیک کن.
برای اینکه بازه زمانی تاییدیه رو هر وقت خواستی دوباره شروع کنی:
- صفحه validation details رو باز کن و روی «شروع تاییدیه جدید» (Start new validation) کلیک کن.
اگه تاییدیه با شکست مواجه شد
۱. دوباره سعی کن مشکلات رو حل کنی.
۲.دورهٔ ردیابی رو دوباره شروع کن، برای این کار صفحه validation details رو باز کن و روی «شروع تاییدیه جدید» (Start new validation) کلیک کن.
وضعیت تاییدیه ایرادات سایت یا Issue validation status
این نشون‌دهندهٔ وضعیت کلی درخواست تاییدیه برای هر مشکل و ایرادی هست که توی صفحهٔ خلاصه گزارش «summary page» و همینطور جزئیات هر مشکل نشون داده میشه.
وضعیت‌های زیر برای درخواست تاییدیه وجود داره:
- شروع نشده (Not Started): یعنی یک یا چندتا از آدرس‌ها هنوز مشکلی که مد نظر بوده رو دارن و هرگز توی چرخهٔ تاییدیه نبودن.
- شروع شده (Started): شروع کردی مشکل رو بررسی کنی و تا اینجا هیچ نمونه جدیدی از اون مشکل پیدا نشده.
- به نظر خوب میاد (Looking Good): پروسه تاییدیه رو شروع کردی و تا الان هر مشکلی که بررسی شده، حل شده بوده.
- قبول شده (Passed): همهٔ آدرس‌ها توی وضعیت «قبول شده» هستن. حتما باید روی «تایید حل مشکل» (Validate Fix) کلیک کرده باشی تا این وضعیت نشون داده بشه (اگه مشکل به طور خود به خود ناپدید می‌شد بدون اینکه تاییدیه درخواست کرده باشی، وضعیت می‌شد «غیرقابل بررسی»)
- غیر قابل بررسی (N/A): گوگل خودش متوجه شده که مشکل روی همهٔ آدرس‌ها رفع شده، حتی اگه خودت اصلا درخواست تاییدیه نداده باشی.
- ناموفق (Failed): یک یا چند آدرس بعد از تلاش برای تایید، توی وضعیت «ناموفق» قرار گرفتن.
وضعیت تاییدیه آدرس یا URL validation status
این قسمت وضعیت تاییدیه «validation status» رو برای هر آدرس توی صفحه پیشرفت تاییدیه «validation progress» نشون می‌ده. وضعیت‌های «در انتظار» (Pending)، «قبول شده» (Passed)، و «ناموفق» (Failed) در طول یه بازه فعال تاییدیه نمایش داده میشن. بعد از اینکه دوره تموم شد، فقط وضعیت «ناموفق» قابل مشاهده‌ست (آیتم‌های رفع‌شده بعد از پایان دوره از لیست حذف میشن).
- در انتظار (Pending): گوگل منتظر اطلاعات و دادهٔ کافی برای اینه که تشخیص بده آدرس هنوز مشکل داره یا نه.
- قبول شده (Passed): به نظر میاد مشکل برای این آدرس دیگه مطرح نیست.
- ناموفق (Failed): مشکل هنوز برای این آدرس وجود داره.
وضعیت‌های «قبول شده» و «ناموفق» می‌تونن فقط توی دورهٔ ردیابی تاییدیه «validation tracking» مشخص بشن. اگه مشکل اول وجود داشته، بعد بدون اینکه درخواست تاییدیه «validation request» داده باشی برطرف بشه، اون آدرس بدون اینکه وضعیت خاصی بگیره از لیست حذف میشه.
هر آدرسی که از توی وب حذف شده و در ۲۸ روز گذشته هیچ اطلاعاتی براش جمع‌آوری نشده، دیگه توی تاریخچهٔ تاییدیه یا گزارش دیده نمیشه.