بر پایداری آخرین نسخه برنامه خود نظارت کنید

عرضه یک نسخه جدید از برنامه تلفن همراه خود برای تولید یکی از هیجان انگیزترین بخش های توسعه برنامه است، اما می تواند یکی از استرس زاترین نیز باشد! تیم شما باید میزان دریافت نسخه، اشکالات جدید و تأثیر آن اشکالات، مقایسه با نسخه های قبلی و موارد دیگر را پیگیری کند.

این صفحه چندین ابزار ارائه شده توسط Firebase را برای نظارت بر داده‌هایی که برای اطمینان از انتشار برنامه تلفن همراه خود نیاز دارید، شرح می‌دهد.

از داشبورد نظارت بر انتشار برای کاوش داده های مربوط به انتشار خود استفاده کنید

داشبورد Release Monitoring در کنسول Firebase توسط Firebase Crashlytics پشتیبانی می‌شود. این یک داشبورد واحد برای نظارت بر آخرین نسخه تولید شما است. داشبورد تقریباً در زمان واقعی به‌روزرسانی می‌شود و نمای سطح بالایی از مهم‌ترین معیارهای انتشار، از جمله معیارهای بدون خرابی، دریافت نسخه، مقایسه با نسخه‌های قبلی و هرگونه مشکل جدید برای انتشار را در اختیار شما قرار می‌دهد.

این داشبورد جدید در صفحه آخرین نسخه در کنسول بهبود می یابد. در مقایسه با آن صفحه، داشبورد Release Monitoring اطلاعات بیشتری را اضافه می‌کند، داده‌های مفید را بدون نیاز به Google Analytics نمایش می‌دهد و سریع‌تر بارگیری می‌شود.

ویژگی های داشبورد

  • گزارش زمان واقعی
    تمام نمودارها تقریباً در زمان واقعی به روز می شوند. مدت کوتاهی پس از استقرار آخرین نسخه خود، می توانید مشاهده کنید که کاربران شروع به تعامل با آن نسخه می کنند. اگر برخی از این کاربران با خرابی مواجه شوند، فوراً از طریق نمودارهای معیارهای بدون خرابی، تأثیر آن را خواهید فهمید.

  • مقایسه و محک گذاری بر اساس نسخه های قبلی
    می توانید پایداری آخرین نسخه خود را در زمینه نسخه های قبلی خود مشاهده کنید. داشبورد به شما امکان می دهد معیارهای زنده آخرین نسخه خود را با حداکثر دو نسخه از نسخه های قبلی خود مقایسه کنید.

  • موضوعات جدید برتر
    می‌توانید خرابی‌های جدید را برای آخرین نسخه خود به محض رسیدن مشاهده کنید. در جدول شماره‌های جدید برتر ، می‌توانید تأثیر مشکلاتی را که برای اولین بار در آخرین نسخه‌تان شناسایی شده‌اند نظارت کنید و به شما این امکان را می‌دهد که به سرعت درباره توقف یا بازگرداندن انتشار تصمیم بگیرید.

الزامات داشبورد

برای مشاهده آخرین نسخه خود در داشبورد Release Monitoring ، موارد زیر را انجام دهید:

  1. مطمئن شوید که برنامه شما حداقل از نسخه‌های زیر از Crashlytics SDK استفاده می‌کند:
    پلتفرم های اپل: v10.8.0+ | اندروید: نسخه 18.6.0+ ( BoM v32.6.0+) | فلوتر: نسخه 3.4.5+ | یونیتی: 11.7.0+

  2. نسخه جدیدی از برنامه را برای تولید منتشر کنید تا با آخرین نسخه خود تعداد کافی کاربر درگیر داشته باشید.

سوالات متداول در مورد داشبورد

برای اینکه یک ساخت در داشبورد ظاهر شود، باید حداقل از نسخه‌های زیر از Crashlytics SDK استفاده کند:
پلتفرم های اپل: v10.8.0+ | اندروید: نسخه 18.6.0+ ( BoM v32.6.0+) | فلوتر: نسخه 3.4.5+ | یونیتی: 11.7.0+

توجه داشته باشید که این نسخه‌های SDK اغلب به‌عنوان نسخه‌های SDK «قابلیت جلسات» نامیده می‌شوند، زیرا می‌توانند داده‌های جلسات را به Crashlytics ارسال کنند که برای بسیاری از ویژگی‌های جدید در Crashlytics ، مانند داشبورد Release Monitoring ، لازم است.

برای اینکه یک ساخت در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:

  • این سازه حداقل از نسخه‌های زیر از Crashlytics SDK استفاده می‌کند:
    پلتفرم های اپل: v10.8.0+ | اندروید: نسخه 18.6.0+ ( BoM v32.6.0+) | فلوتر: نسخه 3.4.5+ | یونیتی: 11.7.0+

  • این بیلد در 3 روز گذشته تعداد کافی کاربر دارد:

    • ساخت باید حداقل 500 کاربر منحصر به فرد داشته باشد

    • این بیلد حداقل 1 درصد از کل کاربران را دارد و حداقل 2 کاربر منحصر به فرد دارد.

داشبورد Release Monitoring با هدف کمک به شما در انتشارات تولیدی‌تان، یعنی ساخت‌هایی که تعداد قابل‌توجهی کاربر دارند، کمک می‌کند.

برای اینکه یک ساخت در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:

  • این سازه حداقل از نسخه‌های زیر از Crashlytics SDK استفاده می‌کند:
    پلتفرم های اپل: v10.8.0+ | اندروید: نسخه 18.6.0+ ( BoM v32.6.0+) | فلوتر: نسخه 3.4.5+ | یونیتی: 11.7.0+

  • این بیلد در 3 روز گذشته تعداد کافی کاربر دارد:

    • ساخت باید حداقل 500 کاربر منحصر به فرد داشته باشد

    • این بیلد حداقل 1 درصد از کل کاربران را دارد و حداقل 2 کاربر منحصر به فرد دارد.

(برای برنامه‌هایی که از طریق Google Play توزیع می‌شوند) اگر برنامه‌ای پیوند Google Play داشته باشد، داشبورد تمام ساخت‌های فهرست‌شده در مسیر Play Prod را نشان می‌دهد، حتی اگر Crashlytics هیچ گزارش جلسه‌ای دریافت نکرده باشد یا کاربران فعالی را برای آن ساخت شناسایی نکرده باشد.

توجه داشته باشید که برای مشاهده داده‌ها در داشبورد برای مقایسه یا درصد کاربران فعال، باید حداقل دو بیلد منتشر کرده باشید که شرایط قبلی را برآورده کند.

ابتدا، درک برخی از اصطلاحات مرتبط با نمودار کاربران فعال مفید است:

  • جلسه یک دوره زمانی مداوم است که کاربر با یک برنامه درگیر است. یک جلسه جدید زمانی شروع می شود که برنامه به صورت سرد شروع شود یا برنامه پس از حداقل 30 دقیقه پس زمینه در پیش زمینه قرار گیرد.

  • کاربران فعال برای یک بیلد خاص، تعداد کاربرانی هستند که یک جلسه را با استفاده از آن بیلد شروع کرده‌اند، گروه‌بندی شده بر اساس ساعت.

  • مجموع کاربران (فعال) تعداد کاربرانی هستند که جلسه‌ای را در هر ساختنی از برنامه‌ای که از نسخه SDK با قابلیت جلسات استفاده می‌کند، شروع کرده‌اند که بر حسب ساعت گروه‌بندی شده‌اند.

در نمودار کاربران فعال ، مقدار درصد و تعداد کاربران فعالی که همیشه در نمودار نمایش داده می‌شوند مربوط به 60 دقیقه گذشته است (یا اگر در 60 دقیقه گذشته هیچ کاربر فعالی وجود نداشته است، دوره ساعت گذشته که دارای داده بوده است). به عنوان مثال، در اسکرین شات مثال، 90 کاربر فعال برای ساخت 6.0.0 (600) در 60 دقیقه گذشته وجود داشته است که 22.1٪ از کل کاربران (فعال) برنامه را تشکیل می دهد.

اسکرین شات نمونه نمودار _کاربران فعال_ از داشبورد <i>نظارت انتشار</i>

وقتی ماوس را روی خطوط در نمودار کاربران فعال نگه می‌دارید، درصد کاربر فعال از تعداد کاربران فعال از بازه زمانی ساعتی که نشانگر ماوس را روی آن قرار می‌دهید محاسبه می‌شود.

توجه داشته باشید که برای مشاهده درصد کاربران فعال، باید حداقل دو بیلد منتشر کرده باشید که الزامات توضیح داده شده در سؤالات متداول "کدام بیلدها را می توان در داشبورد نظارت بر انتشار مشاهده کرد؟" .

درصد کاربران فعال بر اساس داده‌های جلسه دریافتی است نه بر روی هیچ داده دیگری (مانند داده‌های Google Play یا گزارش‌های خرابی).

اگر این اولین باری است که برنامه خود را با نسخه سازگار با Crashlytics SDK منتشر می کنید، Crashlytics هیچ داده جلسه قبلی برای مقایسه ندارد.

هشدارها را تنظیم کنید

چندین محصول Firebase، از جمله Crashlytics ، می‌توانند به دلایل مختلف محصول، هشدار ارسال کنند. برای دریافت هشدارها ، باید مجوزهای لازم را داشته باشید.

برای نظارت بر پایداری آخرین نسخه خود، می‌توانید هشدارهایی را از Performance Monitoring و Crashlytics تنظیم کنید. به طور خاص برای Crashlytics ، می‌توانید هشدارهای زیر را تنظیم کنید:

  • اگر هر مشکل فردی در برنامه شما از آستانه ای که در کنسول Firebase تعریف کرده اید عبور کرد، از هشدارهای سرعت استفاده کنید تا به تیم خود اطلاع دهید.

  • هشدارهای مربوط به مشکلات جدید یا عقب افتاده را به کانال اعلان ترجیحی خود ارسال کنید:

قبل از رهاسازی از آزادسازی صاف اطمینان حاصل کنید

قبل از اینکه آخرین نسخه خود را منتشر کنید، از برخی از خدمات و ویژگی های زیر استفاده کنید تا از انتشار روان اطمینان حاصل کنید.

از خدمات تست قبل از انتشار استفاده کنید

Firebase دو محصول را ارائه می‌کند که می‌توانند به آزمایش قبل از انتشار کمک کنند: Test Lab و App Distribution . هر دوی این سرویس ها می توانند در جریان های CI/CD شما ادغام شوند.

Firebase Test Lab یک زیرساخت آزمایش برنامه مبتنی بر ابر است که به شما امکان می‌دهد برنامه خود را روی طیف وسیعی از دستگاه‌ها و پیکربندی‌ها آزمایش کنید، بنابراین می‌توانید درک اولیه از نحوه عملکرد آن در دست کاربران زنده داشته باشید.

و وقتی آماده هستید که آخرین ساخت خود را در دست آزمایش‌کنندگان انسانی مورد اعتماد قرار دهید، از Firebase App Distribution استفاده کنید. شما می توانید هر دو پلتفرم اپل و توزیع های پیش از انتشار اندروید خود را از یک مکان مدیریت کنید.

از خدمات آزمایشی عرضه و محدود استفاده کنید

از Firebase Remote Config برای راه‌اندازی ویژگی‌های جدید با مکانیزم انتشار درصد یا آزمایش آن ویژگی‌ها در یک گروه آزمایشی محدود استفاده کنید.

Firebase همچنین A/B Testing ارائه می‌کند تا بتوانید تغییرات را در UI، ویژگی‌ها، یا کمپین‌های تعامل برنامه‌تان آزمایش کنید تا ببینید چگونه بر معیارهای کلیدی شما (مانند درآمد و حفظ) تأثیر می‌گذارند، قبل از اینکه آن‌ها را به طور گسترده منتشر کنید.