ارائه نسخه جدید اپلیکیشن موبایل به مرحله تولید، یکی از هیجان‌انگیزترین بخش‌های توسعه اپلیکیشن است، اما می‌تواند یکی از استرس‌زاترین آنها نیز باشد! تیم شما باید میزان جذب نسخه، اشکالات جدید و تأثیر این اشکالات، مقایسه با نسخه‌های قبلی و موارد دیگر را پیگیری کند.
این صفحه چندین ابزار ارائه شده توسط Firebase را برای نظارت بر داده‌هایی که برای اطمینان از انتشار برنامه تلفن همراه خود نیاز دارید، شرح می‌دهد.
از داشبورد نظارت بر انتشار برای بررسی داده‌های مربوط به انتشار خود استفاده کنید
داشبورد نظارت بر انتشار در کنسول Firebase توسط Firebase Crashlytics پشتیبانی می‌شود. این یک داشبورد واحد برای نظارت بر جدیدترین نسخه تولیدی شماست. این داشبورد تقریباً به صورت بلادرنگ به‌روزرسانی می‌شود و به شما یک نمای سطح بالا از مهم‌ترین معیارهای انتشار، از جمله معیارهای بدون خرابی، میزان جذب نسخه، مقایسه با نسخه‌های قبلی و هرگونه مشکل جدید برای انتشار، ارائه می‌دهد.
این داشبورد جدید، صفحه «آخرین نسخه» در کنسول را بهبود می‌بخشد. در مقایسه با آن صفحه، داشبورد «نظارت بر انتشار» اطلاعات بیشتری اضافه می‌کند، داده‌های مفیدی را بدون نیاز به گوگل آنالیتیکس نمایش می‌دهد و سریع‌تر بارگذاری می‌شود.
ویژگی‌های داشبورد
گزارش‌دهی بلادرنگ
تمام نمودارها تقریباً به صورت آنی به‌روزرسانی می‌شوند. کمی پس از استقرار آخرین نسخه، می‌توانید شاهد شروع تعامل کاربران با آن نسخه باشید. اگر برخی از این کاربران دچار خرابی شوند، فوراً از طریق نمودارهای معیارهای بدون خرابی ، تأثیر آن را خواهید دید.مقایسه و بنچمارک بر اساس نسخه‌های قبلی
شما می‌توانید پایداری آخرین نسخه خود را در مقایسه با نسخه‌های قبلی مشاهده کنید. داشبورد به شما امکان می‌دهد معیارهای زنده آخرین نسخه و حداکثر دو نسخه از نسخه‌های قبلی خود را مقایسه کنید.شماره‌های جدید برتر
شما می‌توانید خرابی‌های جدید آخرین نسخه خود را به محض رسیدن مشاهده کنید. در جدول «مشکلات جدید برتر» ، می‌توانید تأثیر مشکلاتی را که برای اولین بار در آخرین نسخه شما شناسایی شده‌اند، رصد کنید و به شما این امکان را می‌دهد که به سرعت در مورد توقف یا بازگرداندن نسخه به نسخه قبلی تصمیم بگیرید.
الزامات مربوط به داشبورد
برای مشاهده آخرین نسخه خود در داشبورد نظارت بر انتشار ، موارد زیر را انجام دهید:
مطمئن شوید که برنامه شما حداقل از نسخه‌های زیر از Crashlytics SDK استفاده می‌کند:
پلتفرم‌های اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+نسخه جدیدی از برنامه را در محیط عملیاتی منتشر کنید تا تعداد کافی از کاربران با آخرین نسخه شما تعامل داشته باشند.
سوالات متداول در مورد داشبورد
برای اینکه یک نسخه در داشبورد ظاهر شود، باید حداقل از نسخه‌های زیر از Crashlytics SDK استفاده کند:
پلتفرم‌های اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+
توجه داشته باشید که این نسخه‌های SDK اغلب به عنوان نسخه‌های SDK با قابلیت session شناخته می‌شوند، زیرا قادر به ارسال داده‌های session به Crashlytics هستند که برای بسیاری از ویژگی‌های جدید Crashlytics ، مانند داشبورد Release Monitoring ، مورد نیاز است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخه‌های زیر از Crashlytics SDK استفاده می‌کند:
پلتفرم‌های اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
داشبورد نظارت بر انتشار ، با هدف کمک به شما در انتشار نسخه‌های عملیاتی، یعنی نسخه‌هایی که تعداد قابل توجهی کاربر دارند، طراحی شده است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخه‌های زیر از Crashlytics SDK استفاده می‌کند:
پلتفرم‌های اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
(برای برنامه‌هایی که از طریق Google Play توزیع شده‌اند) اگر برنامه‌ای لینک Google Play داشته باشد، داشبورد تمام نسخه‌های موجود در لیست Play Prod را نشان می‌دهد، حتی اگر Crashlytics هیچ گزارش نشستی دریافت نکرده باشد یا کاربران فعالی را برای آن نسخه شناسایی نکرده باشد.
توجه داشته باشید که برای مشاهده داده‌ها در داشبورد برای مقایسه یا درصد کاربران فعال، باید حداقل دو نسخه منتشر کرده باشید که الزامات قبلی را برآورده کنند.
اول از همه، درک برخی از اصطلاحات مربوط به نمودار کاربران فعال مفید است:
یک جلسه (session) یک دوره زمانی مداوم است که کاربر با یک برنامه درگیر است. یک جلسه جدید زمانی شروع می‌شود که برنامه به صورت سرد (cold-started) شروع به کار کند یا برنامه پس از حداقل 30 دقیقه فعالیت در پس‌زمینه، در حالت آماده به کار (forgrounded) قرار گیرد.
کاربران فعال برای یک ساخت خاص، تعداد کاربرانی هستند که با استفاده از آن ساخت، جلسه‌ای را آغاز کرده‌اند و بر اساس ساعت گروه‌بندی شده‌اند.
کل کاربران (فعال) تعداد کاربرانی است که در هر نسخه از برنامه که از نسخه SDK با قابلیت session استفاده می‌کند، یک جلسه را شروع کرده‌اند و بر اساس ساعت گروه‌بندی شده‌اند.
در نمودار کاربران فعال ، مقدار درصد و تعداد کاربران فعال که همیشه در نمودار نمایش داده می‌شوند، مربوط به ۶۰ دقیقه گذشته هستند (یا اگر در ۶۰ دقیقه گذشته هیچ کاربر فعالی وجود نداشته است، دوره زمانی یک ساعته گذشته که داده داشته است). برای مثال، در تصویر نمونه، در ۶۰ دقیقه گذشته ۹۰ کاربر فعال برای 6.0.0 (600) وجود داشته است که ۲۲.۱٪ از کل کاربران (فعال) برنامه را تشکیل می‌دهد.
وقتی ماوس را روی خطوط نمودار کاربران فعال نگه می‌دارید، درصد کاربران فعال از تعداد کاربران فعال در دوره ساعتی که ماوس را روی آن نگه داشته‌اید محاسبه می‌شود.
توجه داشته باشید که برای مشاهده درصد کاربران فعال، باید حداقل دو نسخه منتشر کرده باشید که الزامات شرح داده شده در سوالات متداول «کدام نسخه‌ها را می‌توان در داشبورد نظارت بر انتشار مشاهده کرد؟» را برآورده کنند.
درصد کاربران فعال بر اساس داده‌های دریافتی از جلسات محاسبه می‌شود، نه بر اساس داده‌های دیگر (مانند داده‌های Google Play یا گزارش‌های خرابی).
اگر این اولین باری است که برنامه خود را با نسخه سازگار Crashlytics SDK منتشر می‌کنید، Crashlytics هیچ داده‌ای از جلسات قبلی برای مقایسه ندارد.
تنظیم هشدارها
چندین محصول Firebase، از جمله Crashlytics ، می‌توانند به دلایل مختلف مربوط به محصول، هشدار ارسال کنند. برای دریافت هشدارها ، باید مجوزهای لازم را داشته باشید.
برای نظارت بر پایداری آخرین نسخه خود، می‌توانید هشدارهایی را هم از Performance Monitoring و هم Crashlytics تنظیم کنید. به طور خاص برای Crashlytics ، می‌توانید هشدارهای زیر را تنظیم کنید:
از هشدارهای سرعت استفاده کنید تا در صورت عبور هر مشکل خاص در برنامه‌تان از آستانه‌ای که در کنسول Firebase تعریف کرده‌اید، به تیم خود اطلاع دهید.
هشدارهای مربوط به مشکلات جدید یا رفع‌شده را به کانال اعلان دلخواه خود ارسال کنید:
از یکپارچه‌سازی‌های هشدار پیکربندی‌شده توسط Firebase-console برای Jira ، Slack و PagerDuty استفاده کنید.
با استفاده از Cloud Functions for Firebase هشدار پیشرفته برای سرویس‌های شخص ثالث تنظیم کنید.
قبل از رهاسازی، از رهاسازی روان آن اطمینان حاصل کنید
قبل از انتشار آخرین نسخه، استفاده از برخی از سرویس‌ها و ویژگی‌های زیر را برای اطمینان از انتشار روان در نظر بگیرید.
از سرویس‌های تست قبل از انتشار استفاده کنید
فایربیس دو محصول ارائه می‌دهد که می‌توانند به آزمایش قبل از انتشار کمک کنند: Test Lab و App Distribution . هر دوی این سرویس‌ها می‌توانند در جریان‌های CI/CD شما ادغام شوند.
Firebase Test Lab یک زیرساخت تست اپلیکیشن مبتنی بر ابر است که به شما امکان می‌دهد اپلیکیشن خود را روی طیف وسیعی از دستگاه‌ها و پیکربندی‌ها آزمایش کنید، بنابراین می‌توانید درک اولیه‌ای از نحوه عملکرد آن در دست کاربران واقعی داشته باشید.
و وقتی آماده شدید که آخرین نسخه ساخته شده خود را به دست آزمایش‌کنندگان انسانی مورد اعتماد بسپارید، از Firebase App Distribution استفاده کنید. می‌توانید توزیع‌های پیش‌انتشار پلتفرم اپل و اندروید خود را از یک جا مدیریت کنید.
از سرویس‌های آزمایشی گسترده و محدود استفاده کنید
از Firebase Remote Config برای راه‌اندازی ویژگی‌های جدید با مکانیزم انتشار درصدی یا آزمایش آن ویژگی‌ها در یک گروه آزمایشی محدود استفاده کنید.
فایربیس همچنین A/B Testing ارائه می‌دهد تا بتوانید تغییرات در رابط کاربری، ویژگی‌ها یا کمپین‌های تعامل برنامه خود را آزمایش کنید تا ببینید که چگونه بر معیارهای کلیدی شما (مانند درآمد و حفظ مشتری) تأثیر می‌گذارند، قبل از اینکه آنها را به طور گسترده اعمال کنید.