تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
باستخدام Remote Config التخصيص، يمكنك تلقائيًا اختيار Remote Config المَعلمات لكل مستخدم لتحسين الأداء من أجل تحقيق هدف معيّن. تخصيص مَعلمة يشبه إجراء اختبار A/B تلقائي ومخصّص ومستمر التحسين ودائم.
عند استخدام ميزة Remote Config التخصيص في تطبيقاتك، يمكنك إنشاء تجارب أكثر جاذبية لكل مستخدم من خلال تزويده تلقائيًا بإحدى تجارب المستخدم البديلة المتعددة، وهي التجربة البديلة التي تحسّن الهدف الذي تختاره. يمكنك استهداف Remote Configالمَعلمات المخصّصة لمجموعات مستخدمين معيّنة باستخدام Remote Configشروط الاستهداف.
يمكنك تحسين الأداء لتحقيق أي هدف قابل للقياس باستخدام Google Analytics، ويمكنك تحسين الأداء حسب عدد الأحداث أو حسب القيمة المجمّعة (المجموع) لمَعلَمة حدث. ويشمل ذلك المقاييس المضمّنة التالية:
مدة تفاعل المستخدم، والتي يتم تحسينها حسب مدة تفاعل المستخدم
النقرات على الإعلانات، التي يتم تحسينها حسب إجمالي عدد أحداث النقرات على الإعلانات
مرات ظهور الإعلان، التي يتم تحسينها حسب عدد مرات ظهور الإعلان
أو يمكنك تحسين الأداء استنادًا إلى مقاييس مخصّصة بناءً على أيّ حدث Analytics. في ما يلي بعض الاحتمالات:
إرسال التقييمات على "متجر Play" أو App Store
نجاح المستخدم في تنفيذ مهام معيّنة، مثل إكمال مستويات اللعبة
أحداث الشراء داخل التطبيق
أحداث التجارة الإلكترونية، مثل إضافة سلع إلى سلة التسوّق أو بدء عملية الدفع أو إكمالها
تستخدِم ميزة التخصيص تكنولوجيا تعلُّم الآلة لتحديد التجربة المثالية لكل مستخدم من مستخدميك. توازن الخوارزمية بكفاءة بين التعرّف على أفضل تجربة لأنواع مختلفة من المستخدمين والاستفادة من هذه المعرفة لتحقيق الحد الأقصى من مقياس هدفك. تتم تلقائيًا مقارنة نتائج التخصيص بمجموعة مراقبة من المستخدمين الذين يتلقّون تجربة عشوائية ثابتة مستمدّة من البدائل التي تقدّمها، وتوضّح هذه المقارنة مقدار "التحسّن" (القيمة المتزايدة) الذي يحقّقه نظام التخصيص.
فعِّل التخصيص للمَعلمة. ستحدّد Remote Config التجربة الأنسب لكل مستخدم. راجِع دليل البدء.
التخصيص مقارنةً باختبار A/B
على عكس اختبارات A/B المصمَّمة لمعرفة تجربة المستخدم التي تحقّق أفضل أداء، يحاول خيار التخصيص تحقيق الهدف بأفضل شكل ممكن من خلال اختيار أنسب تجربة لكل مستخدم بشكلٍ ديناميكي. بالنسبة إلى العديد من أنواع المشاكل، يحقّق التخصيص أفضل النتائج، ولكن لا يزال لاختبار A/B استخداماته:
يُفضّل استخدام التخصيص
يُفضّل استخدام اختبار A/B
عندما تريد أن يستفيد كل مستخدم من تجربة مخصّصة له
عندما تريد تقديم تجربة واحدة مثالية لجميع المستخدمين أو لمجموعة فرعية محدّدة من المستخدمين
عندما تريد تحسين نموذج التخصيص بشكل مستمر
عندما تريد إجراء اختبارات خلال فترة زمنية ثابتة
عندما يمكن التعبير عن هدف التحسين كقيمة مُرجّحة لأحداث الإحصاءات
عندما يتطلّب هدف التحسين تقييمًا مدروسًا لعدة مقاييس مختلفة متنافِسة
عندما تريد التحسين من أجل تحقيق هدف محدّد بصرف النظر عن المفاضلات
عندما تريد تحديد ما إذا كان أحد المتغيّرات يحقّق تحسُّنًا ذا دلالة إحصائية مقارنةً بمتغيّر آخر، وذلك قبل طرحه
عندما لا تكون مراجعة النتائج يدويًا مطلوبة
الحالات التي تكون فيها مراجعة النتائج يدويًا مرغوبة
على سبيل المثال، لنفترض أنّك تريد زيادة عدد المستخدمين الذين يقيّمون تطبيقك في "متجر Play" عندما تطلب منهم ذلك. أحد العوامل التي قد تساهم في تحقيق النجاح هو توقيت ظهور طلب التقييم: هل تعرضه عندما يفتح المستخدم تطبيقك للمرة الأولى أو الثانية أو الثالثة؟ أو هل تقدّم لهم إشعارات عند إكمال مهام معيّنة بنجاح؟ من المحتمل أن يعتمد التوقيت المثالي على المستخدم الفردي، إذ قد يكون بعض المستخدمين مستعدين لتقييم تطبيقك على الفور، بينما قد يحتاج آخرون إلى مزيد من الوقت.
يُعدّ تحسين توقيت ظهور طلب تقديم الملاحظات حالة استخدام مثالية للتخصيص، وذلك للأسباب التالية:
من المحتمل أن يختلف الإعداد الأمثل لكل مستخدم.
يمكن قياس النجاح بسهولة باستخدام Analytics.
التغيير المطلوب في تجربة المستخدم منخفض المخاطر بما يكفي لعدم الحاجة إلى مراعاة أي حلول وسط أو إجراء مراجعة يدوية.
تاريخ التعديل الأخير: 2025-08-23 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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-08-23 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["\u003cbr /\u003e\n\nWith Remote Config personalization, you can automatically select\nRemote Config parameters for each user to optimize for an objective.\nPersonalizing a parameter is like performing an automatic, individualized,\ncontinuously-improving, and perpetual A/B test.\n\nWhen you use Remote Config personalization in your apps, you create more\nengaging experiences for each of your users by automatically providing them with\none of several alternative user experiences---the alternative that optimizes\nfor the objective you choose. You can target your personalized Remote Config\nparameters to specific user groups using\n[Remote Config targeting conditions](/docs/remote-config/parameters#conditions_rules_and_conditional_values).\n\nYou can optimize for any objective that's measurable using\nGoogle Analytics, and optimize by number of events or by the aggregated\nvalue (sum) of an event parameter. This includes the following built-in metrics:\n\n- User engagement time, which optimizes by user engagement time\n- Ad clicks, which optimizes by total number of ad click events\n- Ad impressions, which optimizes by the number of ad impressions\n\nOr, you can optimize for custom metrics based on any Analytics event. Some\npossibilities include:\n\n- Play Store or App Store rating submissions\n- User success at particular tasks, like completing game levels\n- In-app purchase events\n- E-commerce events, like adding items to a cart, or beginning or completing checkout\n- In-app purchase and ad revenue\n- Virtual currency spend\n- Link and content sharing and social networking activity\n\nFor more information about potential personalization use cases, see\n[What can I do with Remote Config personalization?](/docs/remote-config/personalization/use-cases)\n\n[Get started](/docs/remote-config/personalization/get-started)\n\nHow does it work?\n\nPersonalization uses machine learning to determine the optimal experience for\neach of your users. The algorithm efficiently trades off between learning the\nbest experience for different types of users and making use of that knowledge to\nmaximize your objective metric. Personalization results are automatically\ncompared to a holdout group of users who receive a persistent random experience\ndrawn from your provided alternatives---this comparison shows how much\n\"lift\" (incremental value) is generated by the personalization system.\n\nFor more information about Remote Config personalization algorithm and concepts,\nsee\n[About Remote Config personalization](/docs/remote-config/personalization/about).\n\nImplementation path\n\n1. Implement two or more alternative user experiences that you expect will be optimal for some users but not others.\n2. Make these alternatives remotely configurable with a Remote Config parameter. See [Get started with Remote Config](/docs/remote-config/get-started) and [Remote Config loading strategies](/docs/remote-config/loading).\n3. Enable personalization for the parameter. Remote Config will assign each of your users the experience that's optimal for them. See the [Getting started](/docs/remote-config/personalization/get-started) guide.\n\nPersonalization vs. A/B testing\n\nUnlike A/B tests, which are designed to find a single best performing user\nexperience, personalization attempts to maximize an objective by dynamically\nchoosing an optimal user experience for each user. For many types of problems,\npersonalization produces the best results, but A/B testing still has its uses:\n\n| Personalization preferred | A/B testing preferred |\n|-------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|\n| When each user could benefit from a personalized user experience | When you want a single optimum experience for all users or a defined subset of users |\n| When you want to continuously optimize the personalization model | When you want to conduct tests during a fixed time window |\n| When your optimization goal can be expressed simply as a weighted sum of analytics events | When your optimization goal requires thoughtful evaluation of several different competing metrics |\n| When you want to optimize for an objective regardless of any trade-offs | When you want to determine if one variant shows a statistically significant improvement over another before rolling it out |\n| When manual review of results is not required or desired | When manual review of results is desirable |\n\nFor example, suppose you want to maximize the number of users who rate your app\nin the Play Store when you prompt them to. One factor that might contribute to\nsuccess is the timing of your prompt: do you show it when the user opens your\napp for the first, second, or third time? Or do you prompt them when they\nsuccessfully complete certain tasks? The ideal timing likely depends on the\nindividual user: some users might be ready to rate your app right away, while\nothers might need more time.\n\nOptimizing the timing of your feedback prompt is an ideal use case for\npersonalization:\n\n- The optimal setting is likely different for each user.\n- Success is easily measurable using Analytics.\n- The UX change in question is low risk enough that you probably don't need to consider trade-offs or conduct a manual review.\n\nTry it\n\n[Get started](/docs/remote-config/personalization/get-started)"]]
