Firebase Performance: ما هو، المقاييس وكيفية التتبع

ما هو Firebase Performance Monitoring

Firebase Performance Monitoring هو SDK ومنصة سحابية لجمع وتجميع وتصور مقاييس أداء التطبيقات المحمولة. يتم تضمين SDK في التطبيق ويقوم بأتمتة تتبع النقاط الرئيسية: دورة حياة Activity (Android) أو ViewController (iOS)، وطلبات الشبكة عبر URLSession (iOS) أو OkHttp (Android)، واستدعاءات النظام. يتم إرسال البيانات المجمعة إلى خادم Firebase، حيث يتم تجميعها حسب إصدار التطبيق والجهاز والدولة وسمات أخرى.

تم تصميم بنية Performance SDK على مبدأ العبء الإضافي الأدنى: لا يضيف التتبع أكثر من 1–2% إلى وقت تنفيذ العمليات المقاسة. يتم جمع البيانات بشكل غير متزامن وتخزينها مؤقتاً على الجهاز قبل الإرسال، مما يلغي أي تأثير على أداء سلسلة UI. يتم إرسال البيانات وفقاً لجدول زمني (افتراضياً كل 30 دقيقة) أو عند وصول المخزن المؤقت إلى 100 كيلوبايت.

الفرق الرئيسي بين Firebase Performance وأدوات التحليل في Android Studio (CPU Profiler) أو Xcode Instruments هو مراقبة الإنتاج. يقوم Firebase Performance بجمع البيانات من أجهزة المستخدمين الحقيقية، وليس فقط من أجهزة المطورين. هذا يسمح باكتشاف المشكلات التي تحدث فقط على طرازات محددة أو إصدارات نظام تشغيل معينة أو في مناطق معينة — وهي مشكلات لا يمكن إعادة إنتاجها في بيئة خاضعة للتحكم.

كيف يجمع SDK البيانات بدون تغيير الكود

التتبع التلقائي هو الميزة الرئيسية لـ Firebase Performance. بالنسبة لنظام Android، يسجل SDK تلقائياً ActivityLifecycleCallbacks ويقيس الوقت بين onCreate وonResume (وقت عرض الشاشة). بالنسبة لنظام iOS، يقوم بالتبديل بين طرق viewDidLoad وviewDidAppear. يتم اعتراض طلبات الشبكة على مستوى OkHttpInterceptor (Android) أو NSURLProtocol (iOS). لا يحتاج المطور إلى إضافة استدعاءات بدء/إيقاف للمقاييس القياسية.

تمكين وتعطيل Performance SDK يتم إدارته من خلال إضافة Google Services (Android) أو Info.plist (iOS). لتصحيح الأخطاء، يمكنك تمكين التسجيل المفصل لـ Performance SDK، والذي يوضح المقاييس التي يتم جمعها وإرسالها. في الإنتاج، يُنصح بإبقاء التسجيل على مستوى التحذير لتجنب ازدحام السجلات بمعلومات غير ضرورية. للمشاريع على Flutter أو React Native، قد يكون التتبع التلقائي محدوداً — مزيد من التفاصيل في قسم أمثلة الكود.

الحدود المجانية والتسعير

Firebase Performance متاح على الخطة المجانية Spark دون حدود على عدد التتبعات أو حجم البيانات. الخطة المدفوعة Blaze أيضاً لا تفرض رسوماً على Performance Monitoring — وهي إحدى خدمات Firebase القليلة المجانية تماماً على كلا الخطتين. هناك قيد واحد فقط: يتم تخزين البيانات لمدة 30 يوماً (على Spark) وحتى 365 يوماً (على Blaze). للتحليل طويل المدى، قم بتصدير البيانات عبر BigQuery export.

عدم وجود رسوم يجعل Firebase Performance خياراً مثالياً لأي مشروع — من النموذج الأولي إلى تطبيق المؤسسة بملايين المستخدمين. المصروف الوحيد هو حركة المرور الصادرة من Performance SDK، لكنها ضئيلة مقارنة بعمليات الشبكة الأخرى للتطبيق (أقل من 1 ميجابايت شهرياً لكل جهاز). BigQuery export يفرض رسوماً على التخزين والاستعلامات، لكن Performance SDK نفسه مجاني.

المقاييس التلقائية: ما يتم قياسه بدون كود

Firebase Performance يجمع تلقائياً خمس فئات من المقاييس دون سطر واحد من الكود: وقت بدء تشغيل التطبيق، طلبات HTTP البطيئة، سرعة عرض الشاشات، استخدام الذاكرة (Android فقط) ومعدل الإطارات (Android فقط). هذه المقاييس متاحة في وحدة تحكم Firebase فوراً بعد توصيل SDK وأول جلسة مستخدم.

وقت بدء تشغيل التطبيق — الوقت من بدء العملية حتى اكتمال استعداد واجهة المستخدم للتفاعل. ينقسم إلى بدء تشغيل بارد (يبدأ التطبيق من الصفر) وبدء تشغيل دافئ (يستأنف التطبيق من حالة الخلفية). يشمل بدء التشغيل البارد تحميل ملفات DEX وتهيئة الحقول الثابتة واستدعاء Application.onCreate وActivity.onCreate. يقوم Firebase تلقائياً بتصنيف نوع بدء التشغيل ويظهر توزيع الوقت لكل نوع.

وقت عرض الشاشة — الوقت من بدء تحميل الشاشة (onCreate لنظام Android، viewDidLoad لنظام iOS) حتى لحظة أن تصبح الشاشة جاهزة للتفاعل (onResume، viewDidAppear). يقوم Firebase بتجميع البيانات حسب كل شاشة (باسم الفئة أو اسم الشاشة المخصص)، مما يسمح بتحديد أي شاشة تستغرق وقتاً أطول في التحميل. لنظام Android، يتم قياس الإطارات المسقطة أيضاً — عدد الإطارات التي تم تخطيها أثناء عرض الشاشة (jank).

طلبات الشبكة (HTTP/HTTPS)

Performance SDK يعترض ويقيس تلقائياً كل طلب HTTP/HTTPS مرسل من التطبيق عبر URLSession أو OkHttp أو URLConnection. لكل طلب، يتم تسجيل: URL (المسار بدون معاملات الاستعلام للأمان)، طريقة HTTP، كود الاستجابة، حجم الاستجابة بالبايت، مدة الطلب وسرعة الاتصال (WiFi، خلوي). يتم تجميع البيانات في لوحة معلومات طلبات الشبكة في وحدة تحكم Firebase.

الطلبات البطيئة — الطلبات التي تتجاوز مدتها حداً معيناً. بشكل افتراضي، حد الطلب البطيء هو 4000 مللي ثانية. هذا المقياس بالغ الأهمية لتحديد مشكلات الخادم الخلفي: إذا ارتفع عدد الطلبات البطيئة من 1% إلى 15% بعد تحديث النهاية الخلفية، فهذه إشارة للتحليل الفوري لسجلات الخادم. لن ينتظر المستخدمون أكثر من 5 ثوانٍ للحصول على استجابة — تظهر بيانات Firebase أن 53% من المستخدمين يغلقون التطبيق إذا استغرق الطلب أكثر من 3 ثوانٍ.

قيود التتبع التلقائي

قيود iOS: على iOS، لا يمكن لـ Performance SDK قياس الإطارات المسقطة (هذه واجهة برمجة تطبيقات خاصة). لقياس jank على iOS، استخدم MetricKit أو CADisplayLink. أيضاً، على iOS، لا يعترض SDK الطلبات المنفذة من خلال عملاء HTTP تابعين لجهات خارجية لا يستخدمون URLSession (مثل SwiftNIO). لمثل هذه الحالات، استخدم التتبعات المخصصة مع سمات HTTP.

قيود Android: على Android، قياس الذاكرة التلقائي متاح فقط على الأجهزة التي تعمل بنظام Android 8.0+ (API 26+). للإصدارات الأقدم، استخدم التتبعات المخصصة مع الحصول على البيانات عبر Debug.getMemoryInfo(). أيضاً، لا يعترض SDK اتصالات WebSocket — فهي تتطلب تتبعات منفصلة. على الرغم من هذه القيود، تغطي المقاييس التلقائية 80% من احتياجات مراقبة الأداء.

التتبعات المخصصة وسمات HTTP

التتبعات المخصصة (custom traces) هي فترات زمنية مسماة يقوم المطور بإنشائها يدوياً لقياس أداء سيناريوهات محددة: تحميل خلاصة الأخبار، معالجة صورة، مزامنة البيانات، تنفيذ استعلام معقد لقاعدة البيانات. التتبعات المخصصة تكمل المقاييس التلقائية وتسمح بقياس أجزاء الكود التي يعتبرها المطور حرجة للأداء بالضبط.

كل تتبع له اسم (بحد أقصى 100 حرف) ويمكن أن يحتوي على ما يصل إلى 5 مقاييس مخصصة — قيم رقمية يتم تسجيلها داخل التتبع. على سبيل المثال، في تتبع "image_processing"، يمكنك قياس مقاييس مثل "original_file_size" و"processed_file_size". يتم عرض المقاييس في وحدة تحكم Firebase كتوزيعات (الحد الأدنى، الحد الأقصى، المتوسط، النسب المئوية)، مما يسمح بتحليل ليس فقط المدة ولكن أيضاً خصائص العملية.

سمات HTTP — نوع خاص من التتبعات المخصصة لطلبات الشبكة التي لم يتم اعتراضها تلقائياً بواسطة SDK (على سبيل المثال، عبر WebSocket أو مكتبات الطرف الثالث). تشمل سمات HTTP عنوان URL وطريقة HTTP وكود الاستجابة وحجم الاستجابة. يعرضها Firebase في قسم طلبات الشبكة جنباً إلى جنب مع الطلبات المجمعة تلقائياً، مما يوفر صورة موحدة للتفاعل الشبكي.

متى تستخدم التتبعات المخصصة

التتبعات المخصصة لا غنى عنها لقياس: وقت تحميل البيانات من قاعدة البيانات المحلية (Room، CoreData)، مدة الحسابات المعقدة (التشفير، الضغط)، أداء الرسوم المتحركة والانتقالات، وقت استجابة SDKs التابعة لجهات خارجية (الخرائط، المدفوعات، التحليلات). لكل سيناريو من هذا القبيل، قم بإنشاء تتبع، وقم بتغليف الكود المقاس في start/stop وأضف سمات للتقسيم اللاحق.

لا تفرط في استخدام التتبعات المخصصة. كل تتبع يضيف استهلاكاً إضافياً للبطارية وحركة المرور. يُنصح بعدم وجود أكثر من 10–15 تتبعاً نشطاً في إصدار الإنتاج من التطبيق. لتصحيح الأخطاء، يمكنك إضافة المزيد من التتبعات، ولكن قبل الإصدار، قم بتعطيل الزائدة عبر Remote Config (استخدم العلامة performance_tracing_enabled). هذا يسمح بتمكين التتبع المفصل فقط للمستخدمين أو الجلسات المحددة.

سمات التتبع للتقسيم

السمات المخصصة هي أزواج مفتاح-قيمة يمكن إضافتها إلى تتبع للتصفية اللاحقة في وحدة تحكم Firebase. على سبيل المثال، لتتبع "feed_load"، يمكنك إضافة سمات مثل "feed_type" (main, explore, following) و"cache_status" (cold, warm). في وحدة التحكم، يمكن تصفية بيانات التتبع حسب هذه السمات لتحديد نوع الخلاصة الذي يتم تحميله بشكل أبطأ.

القيود: يمكن أن يحتوي كل تتبع على ما يصل إلى 5 سمات مخصصة. قيمة السمة هي سلسلة تصل إلى 100 حرف. يجب تعيين السمات قبل بدء التتبع؛ تغيير السمة بعد البداية يتم تجاهله. هذا القيد مرتبط بالأداء: تثبيت السمات بعد البداية سيتطلب مزامنة إضافية.

عتبات الأداء والتنبيهات

العتبات (thresholds) هي قيم حدية قابلة للتكوين للمقاييس، عند تجاوزها يقوم Firebase Performance بتوليد تحذير. يتم تعيين العتبات في وحدة تحكم Firebase (Performance > Thresholds) لكل مقياس تلقائي: وقت بدء تشغيل التطبيق (بارد/دافئ)، وقت عرض الشاشة، طلبات HTTP البطيئة، وقت استجابة HTTP. يمكنك تعيين عتبات عامة لجميع إصدارات التطبيق أو عتبات محددة لإصدارات معينة.

التنبيهات (alerts) هي إشعارات تلقائية يرسلها Firebase عند تجاوز العتبة. يمكن تكوين التنبيهات عبر البريد الإلكتروني أو webhook Slack أو PagerDuty أو Cloud Functions (لمعالجة مخصصة). كل تنبيه يحتوي على: اسم المقياس، القيمة الحالية، قيمة العتبة، إصدار التطبيق، الشريحة (الجهاز، الدولة). تسمح التنبيهات بالاستجابة لتدهور الأداء قبل أن يصبح ملحوظاً للمستخدمين.

العتبات الموصى بها وفقاً لمعيار الصناعة (Google I/O 2025): بدء التشغيل البارد — أقل من 2 ثانية، بدء التشغيل الدافئ — أقل من ثانية واحدة، عرض الشاشة — أقل من 500 مللي ثانية، مدة طلب HTTP — أقل من 3000 مللي ثانية (النسبة المئوية 95)، حصة الطلبات البطيئة — أقل من 5%. للتطبيقات شديدة التنافسية (Social، E-commerce)، يمكن أن تكون العتبات المستهدفة أكثر صرامة: بدء التشغيل البارد < 1.5 ثانية، HTTP < 1000 مللي ثانية.

تعيين العتبات في وحدة تحكم Firebase

في وحدة تحكم Firebase، انتقل إلى قسم Performance، وافتح علامة التبويب Thresholds. لكل مقياس، قم بتعيين قيمة العتبة المطلوبة والنسبة المئوية للمستخدمين الذين يجب أن يتأثروا بالتجاوز. على سبيل المثال: "اعتبار بدء التشغيل البارد بطيئاً إذا تجاوز ثانيتين لأكثر من 10% من المستخدمين". سيعرض Firebase القيم الحالية للمقاييس وتاريخ التجاوزات للمساعدة في اختيار عتبات واقعية.

مهم: العتبات لا تؤثر على جمع البيانات، إنها تتحكم فقط في توليد الإشعارات. إذا كانت العتبة منخفضة جداً (على سبيل المثال، بدء التشغيل البارد ثانية واحدة، بينما 50% من الأجهزة تبدأ خلال 3 ثوانٍ)، ستأتي التنبيهات باستمرار وتصبح "ضوضاء" يتوقف المطورون عن ملاحظتها. قم بتعيين العتبات بناءً على الأداء الحالي، ثم شددها تدريجياً مع تحسين التطبيق.

لوحة معلومات الأداء في وحدة تحكم Firebase

لوحة معلومات الأداء تعرض المقاييس الرئيسية كسلاسل زمنية مقسمة حسب إصدار التطبيق والجهاز والدولة ونوع الاتصال وإصدار نظام التشغيل. لكل مقياس، تتوفر: المتوسط، الوسيط، النسبة المئوية 95، النسبة المئوية 99. النسبة المئوية 95 هي المقياس الأكثر إفادة لتقييم الأداء، حيث أنها تظهر كيفية عمل التطبيق على الأجهزة الضعيفة، متجاهلة القيم الشاذة.

لوحة المعلومات تدعم مقارنة الإصدارات: حدد إصدارين من التطبيق (الحالي والسابق) للمقارنة البصرية للمقاييس. إذا زادت النسبة المئوية 95 لوقت بدء التشغيل من 2.1 إلى 3.4 ثانية بعد التحديث — فالتراجع واضح، وتحتاج إلى العثور على الالتزام الذي تسبب في التباطؤ. يتكامل Firebase Performance مع GitHub وGitLab وBitbucket، مما يسمح بربط تغييرات المقاييس بالتزامات محددة.

أمثلة كود لمراقبة الأداء

دعنا نلقي نظرة على أمثلة التكامل لـ Firebase Performance Monitoring في تطبيق Android باستخدام Kotlin. يوضح الكود إنشاء تتبع مخصص لقياس تحميل خلاصة الأخبار، وإضافة سمة HTTP لطلب لم يتم اعتراضه تلقائياً، واستخدام Trace لقياس وقت معالجة الصور. جميع الأمثلة تراعي إمكانية تعطيل التتبع عبر Remote Config.

قبل الاستخدام، أضف التبعية: implementation("com.google.firebase:firebase-perf") عبر Firebase BOM. للتتبع التلقائي، لا يلزم إعداد إضافي — يعترض SDK العمليات القياسية تلقائياً بعد إضافة التبعية.

تتبع مخصص لتحميل الخلاصة

المثال الأول — قياس وقت التحميل لخلاصة الأخبار من الخادم. يغلف التتبع عملية fetchFeed غير المتزامنة، التي تجلب البيانات من الشبكة وتوزع JSON. تمت إضافة سمات مخصصة للتتبع: مصدر البيانات (cache أو network) وعدد المنشورات المستلمة. هذا يسمح بتقسيم البيانات وفهم تحت أي ظروف يتم تحميل الخلاصة بشكل أبطأ.

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

الدالة loadFeedWithTrace تأخذ معامل source ("cache" أو "network")، والذي يُستخدم كسمة للتتبع. بعد اكتمال العملية غير المتزامنة، يتوقف التتبع في كتلة finally، مما يضمن التوقف حتى في حالة الاستثناء. يسمح مقياس items_count بتحليل كيفية تأثير عدد المنشورات على وقت التحميل. في وحدة تحكم Firebase، يمكنك تصفية التتبعات حسب سمة source ورؤية أن التحميل من الشبكة أبطأ 3 مرات من التخزين المؤقت.

سمة HTTP لطلب غير قياسي

المثال الثاني — سمة HTTP لطلب تم تنفيذه عبر WebSocket (لا يتم اعتراضه تلقائياً). يتم استخدام الفئة HttpMetric، التي تسمح بتسجيل طلب URL يدوياً وطريقته وكود الاستجابة وحجمه. سيعرض Firebase هذا الطلب في قسم طلبات الشبكة جنباً إلى جنب مع الطلبات المعترضة تلقائياً.

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

في المثال، sendWithHttpMetric يستخدم newHttpMetric لتسجيل استدعاء HTTP غير قياسي. لا يعترضه SDK تلقائياً، لذلك يقوم المطور بتعيين URL والطريقة وكود الاستجابة والأحجام يدوياً. من المهم تعيين URL بدون معاملات الاستعلام (للأمان والتجميع) — أي /data، وليس /data?token=abc. يقوم Firebase تلقائياً بتجميع أنماط URL المتطابقة.

قياس وقت معالجة الصور

المثال الثالث يوضح قياس وقت معالجة الصور (الضغط، تغيير الحجم) باستخدام تتبع مخصص. في هذه الحالة، يغلف التتبع عملية متزامنة، ولكن للإنتاج استخدم coroutines أو RxJava لتجنب حظر سلسلة UI.

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

الدالة compressImage تقيس وقت ضغط الصورة إلى JPEG بجودة 80%. سمة format تسمح بمقارنة وقت ضغط JPEG مقابل WebP في المستقبل. مقياس output_size_kb يوضح مدى كفاءة الضغط. في وحدة تحكم Firebase، يمكنك رؤية التوزيع: على الأجهزة الضعيفة (Android منخفض التكلفة)، يستغرق الضغط 4 أضعاف الوقت مقارنة بالأجهزة الرائدة، مما قد يكون سبب التأخير عند تحميل الصور إلى الخادم.

كيفية تحسين الأداء بناءً على البيانات

Firebase Performance يوفر البيانات لكنه لا يعطي حلولاً جاهزة. تحليل المقاييس يتطلب فهم الأسباب النموذجية لتدهور الأداء لكل مقياس. دعنا نلقي نظرة على أنماط التدهور الرئيسية وكيفية تشخيصها باستخدام بيانات Performance Monitoring. النهج: اعثر على شذوذ في مقياس → تحقق من الأسباب النموذجية → طبق التحسين → تحقق من النتيجة بعد أسبوع.

بدء التشغيل البارد البطيء (> 2 ثانية): الأسباب — تهيئة SDK ثقيلة في Application.onCreate (التحليلات، تقارير الأعطال، SDK الخرائط)، تحميل موارد كبيرة (الخطوط، السمات)، عمليات متزامنة في سلسلة التوصيل الرئيسية عند بدء التشغيل. الحلول: تهيئة SDK بطيئة، تحميل الموارد المؤجل، استخدام SplashScreen API (Android 12+) لعرض عنصر نائب أثناء التهيئة. سيظهر Firebase Performance أي إصدار من التطبيق بدأ يتباطأ — تحقق من التبعيات التي تمت إضافتها أو تحديثها.

عرض الشاشة البطيء (> 500 مللي ثانية): الأسباب — تسلسل هرمي معقد لـ View (ConstraintLayout متداخل، أجزاء متعددة)، تحميل البيانات في سلسلة UI (شبكة أو قرص)، عمليات رسم ثقيلة (صور كبيرة، طرق عرض مخصصة). الحلول: تحسين التسلسل الهرمي للتخطيط (Layout Inspector في Android Studio)، تفريغ البيانات إلى سلسلة خلفية، تخزين الصور مؤقتاً عبر Glide أو Coil. استخدم عامل تصفية عرض الشاشة في Firebase للعثور على أبطأ شاشة وتحسينها أولاً.

تحسين طلبات الشبكة

طلبات HTTP البطيئة (> 3 ثوانٍ): الأسباب — خادم بطيء، حمولات كبيرة، عدم وجود تخزين مؤقت، بروتوكول غير مثالي (HTTP/1.1 بدلاً من HTTP/2)، تحليل DNS. الحلول: تحقق من جانب الخادم (وقت التشغيل، زمن الوصول)، قلل حجم الاستجابة (التقسيم، GraphQL، protobuf بدلاً من JSON)، فعّل التخزين المؤقت عبر رؤوس HTTP (Cache-Control)، استخدم OkHttp Interceptor لإضافة مهلات ومنطق إعادة المحاولة.

Firebase Performance يظهر توزيع وقت الطلب: تحليل DNS، المصافحة TCP، المصافحة TLS، إرسال الطلب، استلام الاستجابة. إذا كان معظم الوقت يُقضى على DNS — استخدم التحميل المسبق لـ DNS (OkHttp DNS-over-HTTPS). إذا على TLS — استخدم استئناف الجلسة وضبط مجموعات التشفير. إذا على استلام الاستجابة — تحقق من حجم الاستجابة وسرعة شبكة المستخدم. تسمح بيانات Firebase بتحديد المشكلة على مستوى البروتوكول، بدلاً من مجرد قول "الطلب بطيء".

تكامل Remote Config لتعطيل التتبع

للإنتاج، يُنصح بإضافة علامة Remote Config performance_tracing_enabled، التي تسمح بتعطيل التتبعات المخصصة عن بُعد. إذا كان SDK Firebase Performance على العميل يولد الكثير من البيانات أو يؤثر على الأداء (على الأجهزة الضعيفة)، يمكنك تعطيل التتبعات لجميع المستخدمين، مع ترك المقاييس التلقائية فقط، التي لها عبء إضافي أدنى.

مثال على المنطق: عند بدء تشغيل التطبيق، تحقق من معامل Remote Config performance_tracing_enabled. إذا كان false — جميع استدعاءات Firebase.performance.newTrace() تعيد كائناً وهمياً لا يجمع البيانات. يتم تنفيذ ذلك عبر فئة غلاف تتحقق من العلامة قبل إنشاء تتبع. هذا النهج يسمح بتمكين التتبع المفصل لمستخدمين محددين (مختبري بيتا، المطورين) دون التأثير على الجمهور بأكمله.