عند إنشاء طرح جديد وتحديد نسبة مئوية، يضع Firebase جزءًا متساوي الحجم من جمهورك في مجموعة التحكّم للحصول على نتائج دقيقة عند مقارنة أداء الميزة المفعَّلة، ما يؤدي إلى ظهور المجموعات التالية.
مفعَّلة: تتلقّى أجهزة المستخدمين المخصّصة لهذه المجموعة القيمة التي تحدّدها في عملية الطرح.
التحكّم: تتلقّى أجهزة المستخدمين المخصّصة لهذه المجموعة القيمة التي كانت ستتلقّاها من Remote Config، وليس قيمة الطرح.
لم يتم التعيين: تتلقّى أجهزة المستخدمين في هذه المجموعة القيمة التي كان من المفترض أن تتلقّاها من Remote Config، ولكن لا يتم استخدامها في نتائج مقارنة الطرح.
أي أنّه إذا تم طرح الإصدار على% 2 من المستخدمين، ستتم إضافة هؤلاء المستخدمين إلى مجموعة "المستخدمون الذين تم تفعيل الميزة لهم"، وستتم إضافة% 2 أخرى من المستخدمين إلى مجموعة "المجموعة الضابطة" التي تُستخدَم للمقارنة. يظل% 96 من المستخدمين في "لم يتم التعيين".
يضمن هذا النهج إجراء مقارنة عادلة بين أداء المستخدمين والأجهزة التي تتلقّى قيمة الطرح وتلك التي لا تتلقّاها، كما يتيح لك تحديد ما إذا كان الطرح ناجحًا أو فاشلاً بشكل فعّال في صفحة نتائج الطرح.
يكون تحديد مجموعة الطرح متسقًا في جميع مراحل عملية الطرح. وهذا يعني أنّه ضمن عملية الطرح نفسها، إذا خفّضت النسبة المئوية إلى %0، سيعود جميع المستخدمين إلى تلقّي قيمة المَعلمة المحدّدة في النموذج Remote Config. إذا قررت لاحقًا زيادة النسبة المئوية لطرح الميزة، سيعود المستخدمون الذين كانوا جزءًا من مجموعات "مفعَّلة" أو "مجموعة التحكّم" السابقة إلى المجموعة التي تم تعيينهم إليها في الأصل وسيتلقّون قيمًا تتوافق مع تلك المجموعات.
بعد التأكّد من أنّ الإصدار ناجح وتقرّر إطلاقه بالكامل
لجميع المستخدمين المستهدَفين، لن تستخدم Firebase مجموعة التحكّم، وسيتلقّى جميع المستخدمين والأجهزة المستهدَفة قيمة الطرح.
متى يجب استخدام طرح إصدار مقارنةً باختبار A/B؟
تتلاءم Remote Config وA/B Testing مع حالات استخدام مختلفة قليلاً ويمكن استخدامهما بشكل تكميلي.
عمليات الطرح هي إصدارات تدريجية، وغالبًا ما تُستخدم لطرح ميزة جديدة
لمجموعة محدّدة من المستخدمين. يمكنك استهداف المستخدمين في بلد معيّن أو الذين يستخدمون إصدارًا معيّنًا من تطبيقك. استخدِم عمليات الطرح للحدّ من المخاطر واختبار الميزات الجديدة في بيئة واقعية مع عناصر تحكّم دقيقة، ما يتيح لك معرفة مستوى أداء الميزة. يمكنك أيضًا تتبُّع أداء خدمات الخلفية مع زيادة عدد المستخدمين الذين يستفيدون من الميزة الجديدة، وتقدير معدّل الاستخدام للتأكّد من أنّ التغيير قابل للتوسّع قبل طرحه لجمهور أوسع.
تُعد عمليات الطرح أدوات ممتازة في الحالات التي تنفّذ فيها ميزات جديدة تغيّر الوظائف بشكل كبير، أو التغييرات التي قد تؤدي إلى نتائج غير متوقّعة، أو التغييرات التي قد تؤثر في البنية الأساسية أو الخدمات أو واجهات برمجة التطبيقات الخارجية.
تتيح لك ميزة A/B Testing عرض إصدارات متعددة من ميزة أو عنصر في التطبيق، مثل تعديل شكل واجهة المستخدم، أو تغيير نص الإعلان، أو تعديل مستوى صعوبة اللعبة. يمكنك بعد ذلك عرض صيغ مختلفة على المستخدمين لمعرفة الخيار الذي يحقّق نتائج أفضل استنادًا إلى المقياس الذي اخترته (مثل تفاعل المستخدمين والنقرات على الإعلانات والأرباح).
استخدِم A/B Testing لاتخاذ قرارات مستندة إلى البيانات وتحسين الأداء وفهم تفضيلات المستخدمين. تُعدّ هذه الميزة مثالية للحالات التي تتوفّر فيها خيارات متعدّدة قابلة للمقارنة وأهداف محدّدة جدًا. على سبيل المثال،
تكون ميزة A/B Testing مناسبة للتغييرات التي تريد من خلالها تعديل تطبيقك
لتحسين مقياس محدّد، مثل اختبار موضع عرض إعلان بانر
الذي يؤدي إلى المزيد من النقرات.
من المستحسن أيضًا الجمع بين عمليات Remote Config الطرح وA/B Testing ضمن استراتيجية شاملة: أولاً، أنشئ اختبار A/B مع مجموعة محدودة من المستخدمين لتحديد الصيغة التي تحقّق أفضل النتائج لمقاييسك الرئيسية. بعد أن يحدّد A/B Testingقائدًا، أنشئ طرحًا باستخدام صيغة التحكم الفائزة. ننصحك بمراقبة ثباتها ومقاييسها الرئيسية أثناء زيادة عدد المستخدمين الذين تظهر لهم تدريجيًا، وبعد التأكّد من أدائها، يمكنك طرحها على 100% من المستخدمين.
فهم نتائج الطرح
بعد نشر طرح، من المفترض أن تبدأ في ملاحظة النتائج على الفور تقريبًا.
يمكنك الاطّلاع على النتائج بعدّة طرق:
من صفحة المَعلمات، وسِّع المَعلمة التي أعددتها لعملية الطرح، ثم انقر على عرض النتائج أسفل عملية الطرح.
من صفحة عمليات الطرح، انقر على اسم عملية الطرح.
تتيح لك أداة اختيار التطبيق في أعلى صفحة "النتائج" اختيار طرق عرض لتطبيقات معيّنة. تنقسم النتائج إلى عدة أقسام:
قسم الملخّص الذي يعرض نسبة الطرح التي تم ضبطها ويتيح إمكانية التراجع عن الطرح أو تعديله وعند توسيعه، يعرض نظرة عامة على تفاصيل إعدادات الطرح وسجلّ التغييرات.
قسم المستخدمون الذي يعرض عدد عمليات تثبيت التطبيق الفردية التي تم فيها استرداد نموذج طرح في المجموعات التالية:
مفعَّلة: عدد مثيلات التطبيق التي تتطابق مع شرط الطرح المستهدف وحصلت على قيمة الطرح.
المجموعة الضابطة: عدد مثيلات التطبيق التي تتطابق مع شرط الطرح المستهدف والتي تم استرجاع القيمة غير المتغيرة لها.
الهدف: إجمالي العدد المقدَّر للحالات التي تتطابق مع الشرط الذي تحدّده في عملية الطرح، والتي من المفترض أن تتلقّى عملية الطرح أو قيمة غير متغيّرة.
قسمَا Crashlytics وAnalytics اللذان يعرضان بيانات المقارنة لمجموعتَي "المجموعة الضابطة" و"المجموعة التي تمّت ترقيتها" يمكنك فلترة البيانات التي تم جمعها حسب آخر 24 ساعة أو منذ آخر نشر أو آخر 7 أيام. آخر 24 ساعة هي طريقة العرض التلقائية.
Crashlytics نتيجة عن عمليات الطرح
يمكنك الاطّلاع على إجمالي عدد الأعطال والأخطاء غير المميتة وأخطاء ANR التي حدثت أثناء طرح الإصدار. تعرض كل فئة من فئات النتائج رسمًا بيانيًا شريطيًا يقارن بين إجمالي عدد مستخدمي الميزة المفعّلة ومستخدمي المجموعة الضابطة الذين استوفوا شرط الطرح.
الأعطال: يعرِض هذا القسم عدد الأعطال ونسبتها المئوية وعدد المستخدمين الفريدين الذين واجهوا أعطالاً في المجموعتين "مفعَّلة" و"مجموعة التحكّم".
الأخطاء غير الفادحة: تعرض عدد الأخطاء غير الفادحة ونسبتها المئوية وعدد المستخدمين الفريدين الذين واجهوا أخطاء غير فادحة.
أخطاء ANR (تطبيقات Android فقط): تعرض هذه البطاقة عدد أحداث "التطبيق لا يستجيب" ونسبتها المئوية، بالإضافة إلى عدد المستخدمين الفرديين الذين واجهوا حدثًا واحدًا أو أكثر من أحداث ANR.
للحصول على معلومات أكثر تفصيلاً عن الأعطال، يمكنك النقر على عرض المزيد في
Crashlytics. يؤدي هذا إلى فتح صفحة Crashlytics مع فلتر نشط لعملية الطرح التي كنت تفحص نتائجها. تقيس نتائج الطرح في الصفحة Crashlytics جميع المستخدمين الذين سبق أن شاهدوا الإصدار المعنيّ، سواء مفعَّل أو عنصر التحكّم. يمكنك اختيار عرض الأعطال في مجموعة التحكّم أو الأعطال في المجموعة المفعّلة أو كليهما.
Google Analytics نتيجة عن عمليات الطرح
يقارن قسم نتائج الطرح Google Analytics مقاييس Analytics
جميع المستخدمين الذين تم عرض المجموعتين "مفعَّلة" أو "مجموعة التحكّم" لهم بالتفصيل وفي طرق عرض الرسومات البيانية. يتم توفير ثلاثة مقاييس:
إجمالي الإيرادات: يعرِض إجمالي مبلغ الإيرادات، بما في ذلك إيرادات الإعلانات وإيرادات عمليات الشراء، بالدولار الأمريكي. يمكنك فلترة نتائجك لعرض نتائج خاصة بإيرادات الإعلانات أو إيرادات عمليات الشراء.
إجمالي الإحالات الناجحة: يعرِض العدد الأولي لمجموع كل أحداث الإحالات الناجحة. يمكنك فلترة النتائج حسب الإحالة الناجحة التي تريد إبرازها.
إجمالي مدة التفاعل: يعرِض إجمالي مدة التفاعل التي قضاها المستخدمون مع أحد متغيرات الطرح. يتم عرض إجمالي مدة التفاعل بالتنسيق ساعات:دقائق:ثوانٍ. على سبيل المثال، 01:31:28. يعرض الرسم البياني البيانات من الفترة الزمنية التي اخترتها أعلى القسم Crashlytics.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["\u003cbr /\u003e\n\nThis guide provides information about key concepts related to Remote Config rollouts, so\nthat you can:\n\n- [Understand how rollout group membership works.](#understand-rollout-membership)\n- [Know when to use a rollout and when to use an A/B Test.](#when-use)\n- [Learn how to interpret rollout results.](#understand-rollout-results)\n\nUnderstand rollout group membership\n\nWhen you create a new rollout and assign a percentage, Firebase places an\nequally-sized portion of your audience into a control group for accurate results\nwhen comparing the performance of your enabled feature, resulting in the\nfollowing groups.\n\n- **Enabled**: User devices assigned to this group receive the value you configure in your rollout.\n- **Control** : User devices assigned to this group receive value they otherwise would have received from Remote Config, not the rollout value.\n- **Unassigned:** User devices in this group receive the value they otherwise would have received from Remote Config, but *are not* used in rollout comparison results.\n\nThat is, if you roll out to 2% of your users, they are added to the Enabled\ngroup and an additional 2% of your users are added to the Control\ngroup, which is used for comparison. 96% of your users remain in Unassigned.\n\nThis approach ensures a fair comparison between the performance of users and\ndevices that receive your rollout value and those that do not and lets you\neffectively determine success or failure of the rollout on the [Rollout\nResults](#understand-rollout-results) page.\n| **Note:** In order to achieve equally-sized groups, any rollout you create must be exposed to less than or equal to 50% until and unless you roll out to 100% of your users.\n\nRollout group assignment is consistent across all phases of a rollout. That is,\nwithin the same rollout, if you reduce the percentage to 0%, all users will\nrevert to receiving the parameter value defined in the Remote Config\ntemplate. If you later decide to increase the rollout percentage, users who were\npart of the previous Enabled or Control groups will return to the group they\nwere originally assigned and will receive values consistent with those groups.\n\nWhen you've verified that your release is successful and decide to fully launch\nto 100% of targeted users, Firebase no longer uses the control group and *all*\ntargeted users and devices receive the rollout value.\n\nWhen to use a rollout versus an A/B test?\n\nRemote Config rollouts and A/B Testing are appropriate for slightly different use\ncases and can be used in a complementary manner.\n\n**Rollouts** are gradual releases, and are often used to release a new feature\nto a select group of users. You might want to target users in a specific\ncountry, or using a specific version of your app. Use rollouts to mitigate risk,\nto test new features in a real-world environment, with tight controls, so that\nyou can see how the feature performs. You can also monitor how your backend\nservices perform with the added load of the new feature, and approximate usage\nto ensure your change is scalable before releasing to a wider audience.\n\nRollouts are excellent tools for situations where you're implementing new\nfeatures that significantly change functionality, changes that may result in\nunpredictable results, or changes that may impact your backend infrastructure,\nservices, or external APIs.\n\n[**A/B Testing**](/docs/ab-testing/ab-concepts) gives you the ability to\npresent multiple versions of a feature or app element, for example,\nupdating UI look and feel, changing advertising copy, updating game level\ndifficulty. You can then expose different variations to your users to learn\nwhich option drives better results based on your chosen metric (like user\nengagement, ad clicks, and revenue).\n\nUse A/B Testing for data-driven decision making, optimization, and\nunderstanding your users' preferences. It's perfect for situations where\nyou have multiple comparable options and very specific goals. For example,\nA/B Testing is appropriate for changes where you want to tweak your app\nto improve a specific metric, like testing which banner ad placement\nresults in more clicks.\n\nIt's also a good idea to combine Remote Config rollouts and A/B Testing within an\noverarching strategy: First, create an A/B Test with a constrained set of\nusers to determine the variant that produces the optimal results for your\nkey metrics. Then, after A/B Testing has determined [a\nleader](/docs/ab-testing/ab-concepts#leader-determination), create a\nrollout with the winning variant. Monitor its stability and key metrics as\nyou incrementally increase the number of exposed users and, after you're\nconfident in its performance, roll it out to 100%.\n\nUnderstand rollout results\n\nAfter you publish a rollout, you should start seeing results almost immediately.\n\nYou can view results in multiple ways:\n\n- From the **Parameters** page, expand the parameter you configured for the Rollout and, beneath the rollout, click **View results**.\n- From the **Rollouts** page, click the rollout name.\n\nThe app selector at the top of the Results page lets you select views for\nspecific apps. Results are divided into multiple sections:\n\n- The **Summary** section, which shows the configured **Rollout percentage** and provides the ability to roll back or edit the rollout. When expanded, it shows an **Overview** of your rollout's configuration details and **Change\n history**.\n- The **Users** section, which shows the number of unique app\n installations that have fetched a rollout template in the following\n groups:\n\n - **Enabled:** Number of app instances that match target rollout condition and have fetched the rollout value.\n - **Control:** Number of app instances that match the target rollout condition and have fetched the unchanged value.\n - **Target**: Estimated total number of instances that match the condition you set in your rollout, which should receive either the rollout or an unchanged value.\n\n Learn more at\n [Understand rollout group membership](#understand-rollout-membership).\n- The [**Crashlytics**](#crashlytics-results) and\n [**Analytics**](#analytics-results) sections, which show comparison data\n for Enabled and Control groups. You can filter the collected data for the\n **Last 24 hours** , **Since last publish** , or **Last 7 days**. Last 24 hours\n is the default view.\n\nCrashlytics results for rollouts\n\nYou can see the total number of **Crashes** , **Non-fatals** , and **ANRs** that\noccurred during your rollout. Each result category shows a bar graph that\ncompares the raw totals of the **Enabled** and **Control** users that met the\ncondition of the rollout.\n\n- **Crashes:** Shows the number and percentage of crashes, and the number of unique users who experienced crashes for the Enabled and Control groups.\n- **Non-fatals:** Shows the number and percentage of non-fatal errors, number of unique users who experienced non-fatal errors.\n- **ANRs (Android apps only):** Shows the number and percentage of \"Application Not Responding\" events, as well as the number of unique users who experienced one or more ANR events.\n\nFor more detailed information about crashes, you can click **View more in\nCrashlytics** . This opens the Crashlytics page with an active filter for\nthe rollout whose results you were inspecting. The rollout results on the\nCrashlytics page measures all users who have *ever* been exposed to the\nrespective variant, **Enabled** or **Control**. You can choose to view Control\ngroup crashes, Enabled group crashes, or both.\n| **Tip:** When viewing results in Crashlytics, you can filter for events that happened while a specific rollout was active by selecting **Filter issues** \\\u003e **Rollouts** and then selecting one or more rollout names.\n\nGoogle Analytics results for rollouts\n\nThe Google Analytics rollout results section compares Analytics\nmetrics for all users who have ever been exposed to the Enabled or Control\ngroups in detail and in graph views. Three metrics are provided:\n\n- **Total revenue:** Shows the total amount of revenue, including Ad revenue and Purchase revenue, in USD. You can filter your results to show results specifically for Ad revenue or Purchase revenue.\n- **Total conversions:** Shows the raw count of the sum of all conversion events. You can filter your results by the conversion that you want to highlight.\n- **Total engagement time:** Shows The total engagement time that your users spent with one of the rollout variants. Total engagement time is displayed in the Hours:Minutes:Seconds format. For example, 01:31:28. The graph shows data from the time period you selected above the Crashlytics section.\n\nNext steps\n\n- [Get started with Remote Config rollouts](/docs/remote-config/rollouts)."]]
