إنشاء تجارب "الإعداد عن بُعد في Firebase" باستخدام ميزة "اختبار A/B"

عند استخدام Firebase Remote Config لنشر إعدادات لتطبيق يتضمّن قاعدة مستخدمين نشطة، عليك التأكّد من أنّك تنفّذ ذلك بشكل صحيح. يمكنك استخدام تجارب A/B Testing لتحديد ما يلي على أفضل وجه:

  • أفضل طريقة لتنفيذ ميزة تهدف إلى تحسين تجربة المستخدم في كثير من الأحيان، لا يدرك مطوّرو التطبيقات أنّ المستخدمين لا يفضّلون ميزة جديدة أو تجربة مستخدم معدَّلة إلا بعد انخفاض تقييم التطبيق في متجر التطبيقات. يمكن أن يساعد اختبار A/B في قياس ما إذا كان المستخدمون يفضّلون الإصدارات الجديدة من الميزات أو ما إذا كانوا يفضّلون التطبيق كما هو. بالإضافة إلى ذلك، يضمن إبقاء معظم المستخدمين في مجموعة أساسية استمرار معظم قاعدة المستخدمين في استخدام تطبيقك بدون حدوث أي تغييرات في سلوكه أو مظهره إلى أن تنتهي التجربة.
  • أفضل طريقة لتحسين تجربة المستخدم لتحقيق هدف تجاري في بعض الأحيان، يتم تنفيذ تغييرات على المنتج بهدف زيادة مقياس معيّن إلى أقصى حد، مثل الأرباح أو الاحتفاظ بالمستخدمين. باستخدام اختبار A/B، يمكنك تحديد هدف نشاطك التجاري، وتُجري Firebase التحليل الإحصائي لتحديد ما إذا كانت إحدى الصيغ تتفوّق على الصيغة الأساسية لتحقيق هدفك المحدّد.

لإجراء اختبار A/B على صيغ الميزة باستخدام خط أساس، اتّبِع الخطوات التالية:

  1. أنشئ تجربتك.
  2. اختبِر تجربتك على جهاز اختباري.
  3. إدارة تجربتك

إنشاء تجربة

تتيح لك تجربة Remote Config تقييم عدة صيغ لواحد أو أكثر من Remote Config المَعلمات.

  1. سجِّل الدخول إلى Firebase وحدة التحكّم وتأكَّد من تفعيل Google Analytics في مشروعك لكي يتمكّن الاختبار من الوصول إلى بيانات Analytics.

    إذا لم تفعِّل Google Analytics عند إنشاء مشروعك، يمكنك تفعيله في علامة التبويب عمليات الدمج التي يمكنك الوصول إليها باستخدام > إعدادات المشروع في Firebase.

  2. في قسم التفاعل ضمن قائمة التنقّل في وحدة تحكّم Firebase، انقر على A/B Testing.

  3. انقر على إنشاء تجربة، ثمّ اختَر Remote Config عندما يُطلب منك اختيار الخدمة التي تريد تجربتها.

  4. أدخِل اسمًا ووصفًا اختياريًا لتجربتك، ثم انقر على التالي.

  5. املأ حقول الاستهداف، وابدأ باختيار التطبيق الذي يستخدم تجربتك. يمكنك أيضًا استهداف مجموعة فرعية من المستخدمين للمشاركة في تجربتك من خلال النقر على و، ثم اختيار خيارات من القائمة التالية:

    • الإصدار: إصدار واحد أو أكثر من تطبيقك
    • رقم الإصدار: رمز إصدار التطبيق
    • اللغات: لغة واحدة أو أكثر ولغات محلية مستخدَمة لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة
    • البلد/المنطقة: بلد أو منطقة واحدة أو أكثر لاختيار المستخدمين الذين يجب تضمينهم في التجربة
    • شريحة جمهور المستخدمين: شرائح الجمهور المستخدَمة لاستهداف المستخدمين الذين قد يتم تضمينهم في التجربةAnalytics
    • خاصية المستخدِم: خاصية مستخدِم واحدة أو أكثر Analytics لاختيار المستخدِمين الذين يمكن تضمينهم في التجربة
    • عمليات بدء التشغيل لأول مرة: استهداف المستخدمين استنادًا إلى أول مرة فتحوا فيها تطبيقك

      تتوفّر ميزة استهداف المستخدمين حسب وقت الفتح الأول بعد اختيار تطبيق Android أو iOS. وهي متوافقة مع إصدارات حزمة تطوير البرامج (SDK) التالية: الإصدار 9.0.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) لمنصات Apple والإصدار 21.1.1 أو إصدار أحدث من حزمة تطوير البرامج (SDK) لنظام التشغيل Android (Firebase BoM الإصدار 30.3.0 أو إصدار أحدث).Remote Config

      يجب أيضًا أن يكون الخيار Analytics مفعَّلاً على الجهاز أثناء حدث الفتح الأول.

  6. اضبط النسبة المئوية للمستخدمين المستهدَفين: أدخِل النسبة المئوية لقاعدة مستخدمي تطبيقك الذين يستوفون المعايير المحدّدة ضمن المستخدمون المستهدَفون والتي تريد تقسيمها بالتساوي بين السعر الأساسي وسعر واحد أو أكثر من الأسعار المتغيرة في تجربتك. يمكن أن تكون هذه النسبة المئوية أي قيمة بين% 0.01 و%100. يتم تعيين المستخدمين بشكل عشوائي لكل تجربة، بما في ذلك التجارب المكرّرة.

  7. يمكنك اختياريًا ضبط حدث تفعيل لضمان عدم احتساب البيانات من المستخدمين الذين أطلقوا حدث Analytics لأول مرة إلا في تجربتك. يُرجى العِلم أنّ جميع المستخدمين الذين يستوفون مَعلمات الاستهداف سيتلقّون قيمًا تجريبية Remote Config، ولكن سيتم تضمين المستخدمين الذين يؤدّون حدث تفعيل فقط في نتائج تجربتك.

    لضمان إجراء تجربة صالحة، تأكَّد من أنّ الحدث الذي تختاره يحدث بعد أن يفعّل تطبيقك قيم الإعدادات التي تم جلبها. بالإضافة إلى ذلك، لا يمكن استخدام الأحداث التالية لأنّها تحدث دائمًا قبل تفعيل القيم التي تم جلبها:

    • app_install
    • app_remove
    • app_update
    • dynamic_link_first_open
  8. بالنسبة إلى أهداف التجربة، اختَر المقياس الأساسي الذي تريد تتبُّعه، وأضِف أي مقاييس إضافية تريد تتبُّعها من القائمة. وتشمل هذه المقاييس الأهداف المضمَّنة (عمليات الشراء والأرباح والاحتفاظ بالمستخدمين والمستخدمين الذين لم يواجهوا أعطالاً، وما إلى ذلك). أحداث الإحالات الناجحة Analytics وأحداث Analytics الأخرى عند الانتهاء، انقر على التالي.

  9. في قسم الصيغ، اختَر سعرًا أساسيًا وصيغة واحدة على الأقل للتجربة. استخدِم قائمة اختيار أو إنشاء جديد لإضافة مَعلمة واحدة أو أكثر لتجربتها. يمكنك إنشاء مَعلمة لم يسبق استخدامها في وحدة تحكّم Firebase، ولكن يجب أن تكون هذه المَعلمة متوفّرة في تطبيقك ليكون لها أي تأثير. يمكنك تكرار هذه الخطوة لإضافة مَعلمات متعدّدة إلى تجربتك.

  10. (اختياري) لإضافة أكثر من سعر متغير إلى تجربتك، انقر على إضافة سعر متغير آخر.

  11. تغيير مَعلمة واحدة أو أكثر لخيارات منتج معيّنة تكون أي معلَمات غير متغيرة هي نفسها بالنسبة إلى المستخدمين غير المدرَجين في التجربة.

  12. وسِّع أوزان الصيغة لعرض وزن الصيغة أو تغييره للتجربة. بشكل تلقائي، يتم منح جميع الصيغ قيمًا تقديرية متساوية. يُرجى العلم أنّ القيم التقديرية غير المتساوية يمكن أن تؤدي إلى زيادة الوقت المُستغرَق في جمع البيانات ولا يمكن تغييرها بعد بدء التجربة.

  13. انقر على مراجعة لحفظ تجربتك.

يُسمح لك بإجراء ما يصل إلى 300 تجربة لكل مشروع، ويمكن أن يتضمّن ذلك ما يصل إلى 24 تجربة نشطة، مع بقاء التجارب الأخرى كمسودّة أو مكتملة.

التحقّق من صحة تجربتك على جهاز اختباري

يمكنك استرداد رمز مصادقة التثبيت المرتبط بكل عملية تثبيت في Firebase. يمكنك استخدام هذا الرمز المميز لاختبار صيغ تجريبية محدّدة على جهاز اختباري تم تثبيت تطبيقك عليه. للتحقّق من صحة التجربة على جهاز اختبار، اتّبِع الخطوات التالية:

  1. احصل على رمز المصادقة الخاص بالتثبيت على النحو التالي:

    Swift

    do {
      let result = try await Installations.installations()
        .authTokenForcingRefresh(true)
      print("Installation auth token: \(result.authToken)")
    } catch {
      print("Error fetching token: \(error)")
    }

    Objective-C

    [[FIRInstallations installations] authTokenForcingRefresh:true
                                                   completion:^(FIRInstallationsAuthTokenResult *result, NSError *error) {
      if (error != nil) {
        NSLog(@"Error fetching Installation token %@", error);
        return;
      }
      NSLog(@"Installation auth token: %@", [result authToken]);
    }];

    Java

    FirebaseInstallations.getInstance().getToken(/* forceRefresh */true)
            .addOnCompleteListener(new OnCompleteListener<InstallationTokenResult>() {
        @Override
        public void onComplete(@NonNull Task<InstallationTokenResult> task) {
            if (task.isSuccessful() && task.getResult() != null) {
                Log.d("Installations", "Installation auth token: " + task.getResult().getToken());
            } else {
                Log.e("Installations", "Unable to get Installation auth token");
            }
        }
    });

    Kotlin

    val forceRefresh = true
    FirebaseInstallations.getInstance().getToken(forceRefresh)
        .addOnCompleteListener { task ->
            if (task.isSuccessful) {
                Log.d("Installations", "Installation auth token: " + task.result?.token)
            } else {
                Log.e("Installations", "Unable to get Installation auth token")
            }
        }

    C++‎

    firebase::InitResult init_result;
    auto* installations_object = firebase::installations::Installations::GetInstance(
        firebase::App::GetInstance(), &init_result);
    installations_object->GetToken().OnCompletion(
        [](const firebase::Future<std::string>& future) {
          if (future.status() == kFutureStatusComplete &&
              future.error() == firebase::installations::kErrorNone) {
            printf("Installations Auth Token %s\n", future.result()->c_str());
          }
        });

    Unity

    Firebase.Installations.FirebaseInstallations.DefaultInstance.GetTokenAsync(forceRefresh: true).ContinueWith(
      task => {
        if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
          UnityEngine.Debug.Log(System.String.Format("Installations token {0}", task.Result));
        }
      });
  2. في شريط التنقّل الخاص Firebaseوحدة التحكّم، انقر على اختبار A/B.
  3. انقر على مسودّة (أو قيد التشغيل لتجارب "الإعداد عن بُعد")، مرِّر المؤشر فوق تجربتك، وانقر على قائمة السياق ()، ثم انقر على إدارة الأجهزة الاختبارية.
  4. أدخِل الرمز المميز لمصادقة التثبيت لجهاز اختبار، واختَر صيغة التجربة التي تريد إرسالها إلى جهاز الاختبار هذا.
  5. شغِّل التطبيق وتأكَّد من تلقّي الإصدار المحدّد على الجهاز التجريبي.

لمزيد من المعلومات حول عمليات تثبيت Firebase، يُرجى الاطّلاع على إدارة عمليات تثبيت Firebase.

إدارة تجربتك

سواء أنشأت تجربة باستخدام Remote Config أو &quot;أداة إنشاء الإشعارات&quot; أو Firebase In-App Messaging، يمكنك بعد ذلك التحقّق من صحة التجربة وبدءها، وتتبُّعها أثناء تنفيذها، وزيادة عدد المستخدمين المضمّنين في تجربتك الجارية.

بعد انتهاء تجربتك، يمكنك تدوين الإعدادات التي استخدمتها الصيغة الفائزة، ثم طرح هذه الإعدادات لجميع المستخدمين. أو يمكنك إجراء تجربة أخرى.

بدء تجربة

  1. في قسم التفاعل ضمن قائمة التنقّل في وحدة تحكّم Firebase، انقر على A/B Testing.
  2. انقر على مسودة، ثمّ انقر على عنوان تجربتك.
  3. للتأكّد من أنّ تطبيقك يتضمّن مستخدمين سيتم إدراجهم في تجربتك، وسِّع تفاصيل المسودة وابحث عن رقم أكبر من 0% في قسم الاستهداف والتوزيع (على سبيل المثال، % 1 من المستخدمين الذين يستوفون المعايير).
  4. لتغيير تجربتك، انقر على تعديل.
  5. لبدء تجربتك، انقر على بدء التجربة. يمكنك إجراء ما يصل إلى 24 تجربة لكل مشروع في المرة الواحدة.

مراقبة تجربة

بعد تشغيل التجربة لفترة من الوقت، يمكنك الاطّلاع على مدى تقدّمها ومعرفة شكل النتائج بالنسبة إلى المستخدمين الذين شاركوا في تجربتك حتى الآن.

  1. في قسم التفاعل ضمن قائمة التنقّل في وحدة تحكّم Firebase، انقر على A/B Testing.
  2. انقر على جارٍ التنفيذ، ثم انقر على عنوان تجربتك أو ابحث عنه. في هذه الصفحة، يمكنك الاطّلاع على إحصاءات مختلفة تم رصدها وإحصاءات مستندة إلى نماذج حول تجربتك النشطة، بما في ذلك ما يلي:

    • النسبة المئوية للفرق عن المرجع: مقياس لتحسُّن أحد المقاييس لصيغة معيّنة مقارنةً بالصيغة المرجعية. يتم احتسابها من خلال مقارنة النطاق القيمي لخيارات المنتج بالنطاق القيمي للمنتج الأساسي.
    • احتمالية تجاوز المعدّل المرجعي: الاحتمالية المُقدَّرة لتفوّق صيغة معيّنة على المعدّل المرجعي للمقياس المحدّد.
    • observed_metric لكل مستخدم: استنادًا إلى نتائج التجربة، هذا هو النطاق المتوقّع الذي ستقع فيه قيمة المقياس بمرور الوقت.
    • الإجمالي observed_metric: القيمة التراكمية المرصودة للمقياس الأساسي أو المتغير. تُستخدَم القيمة لقياس مدى جودة أداء كل صيغة من صيغ التجربة، كما تُستخدَم لاحتساب التحسّن ونطاق القيمة واحتمالية التفوق على خط الأساس واحتمالية أن تكون الصيغة الأفضل. واستنادًا إلى المقياس الذي يتم قياسه، قد يتم تصنيف هذا العمود على أنّه "المدة لكل مستخدم" أو "الإيرادات لكل مستخدم" أو "معدل الاحتفاظ بالمستخدمين" أو "معدل الإحالات الناجحة".
  3. بعد إجراء التجربة لفترة من الوقت (7 أيام على الأقل لـ FCM وIn-App Messaging أو 14 يومًا لـ Remote Config)، تشير البيانات الواردة في هذه الصفحة إلى الصيغة "الأفضل"، إن وُجدت. تتضمّن بعض القياسات رسومات بيانية شريطية تعرض البيانات بتنسيق مرئي.

طرح تجربة لجميع المستخدمين

بعد أن تستمر التجربة لفترة كافية وتتوفّر صيغة "رائدة" أو صيغة تحقّق أفضل أداء في ما يتعلّق بمقياس هدفك، يمكنك طرح التجربة على جميع المستخدمين. يتيح لك ذلك اختيار صيغة لنشرها لجميع المستخدمين من الآن فصاعدًا. حتى في حال لم تُنشئ تجربتك صيغة واضحة تحقّق أفضل أداء، لا يزال بإمكانك اختيار طرح صيغة لجميع المستخدمين.

  1. في قسم التفاعل ضمن قائمة التنقّل في وحدة تحكّم Firebase، انقر على A/B Testing.
  2. انقر على مكتملة أو قيد التنفيذ، ثم انقر على التجربة التي تريد طرحها لجميع المستخدمين، وانقر على قائمة السياق () طرح الصيغة.
  3. اطرح تجربتك لجميع المستخدمين من خلال تنفيذ أحد الإجراءات التالية:

    • بالنسبة إلى التجربة التي تستخدم أداة إنشاء الإشعارات، استخدِم مربّع الحوار رسالة الطرح لإرسال الرسالة إلى المستخدمين المستهدَفين المتبقّين الذين لم يكونوا جزءًا من التجربة.
    • بالنسبة إلى تجربة Remote Config، اختَر صيغة لتحديد قيم معلمات Remote Config التي تريد تعديلها. تتم إضافة معايير الاستهداف التي تم تحديدها عند إنشاء التجربة كشرط جديد في نموذجك، وذلك للتأكّد من أنّ عملية الطرح لن تؤثر إلا في المستخدمين الذين تستهدفهم التجربة. بعد النقر على مراجعة في ميزة "الإعداد عن بُعد" للاطّلاع على التغييرات، انقر على نشر التغييرات لإكمال عملية الطرح.
    • بالنسبة إلى تجربة In-App Messaging، استخدِم مربّع الحوار لتحديد نوع الإصدار الذي يجب طرحه كحملة In-App Messaging مستقلة. بعد اختيار هذا الخيار، ستتم إعادة توجيهك إلى شاشة إنشاء الرسالة داخل التطبيق لإجراء أي تغييرات (إذا لزم الأمر) قبل النشر.

توسيع نطاق تجربة

إذا تبيّن لك أنّ إحدى التجارب لا تجذب عددًا كافيًا من المستخدمين لتحديد التجربة الأفضل، يمكنك زيادة نسبة توزيع تجربتك للوصول إلى نسبة أكبر من قاعدة مستخدمي التطبيق.A/B Testing

  1. في قسم التفاعل ضمن قائمة التنقّل في وحدة تحكّم Firebase، انقر على A/B Testing.
  2. اختَر التجربة النشطة التي تريد تعديلها.
  3. في نظرة عامة على التجربة، انقر على قائمة السياق ()، ثم انقر على تعديل التجربة الجارية.
  4. يعرض مربّع الحوار الاستهداف خيارًا لزيادة النسبة المئوية للمستخدمين المشاركين في التجربة الجارية. اختَر رقمًا أكبر من النسبة المئوية الحالية وانقر على نشر. سيتم طرح التجربة على النسبة المئوية للمستخدمين التي حدّدتها.

تكرار تجربة أو إيقافها

  1. في قسم التفاعل ضمن قائمة التنقّل في وحدة تحكّم Firebase، انقر على A/B Testing.
  2. انقر على مكتملة أو جارية، ثم مرِّر المؤشر فوق تجربتك، وانقر على قائمة السياق ()، ثم انقر على تكرار التجربة أو إيقاف التجربة.

استهداف المستخدمين

يمكنك استهداف المستخدمين المطلوب تضمينهم في تجربتك باستخدام معايير استهداف المستخدمين التالية.

معيار الاستهداف المشغِّلون    القيمة(القيم) ملاحظة
الإصدار يحتوي على،
لا يحتوي على،
يطابق تمامًا،
يحتوي على تعبير عادي
أدخِل قيمة واحدة أو أكثر لإصدارات التطبيق التي تريد تضمينها في التجربة.

عند استخدام أي من عوامل التشغيل يتضمّن أو لا يتضمّن أو يطابق تمامًا، يمكنك تقديم قائمة بالقيم مفصولة بفواصل.

عند استخدام عامل التشغيل يحتوي على تعبير عادي، يمكنك إنشاء تعبيرات عادية بتنسيق RE2. يمكن أن يتطابق التعبير العادي مع السلسلة المستهدفة للإصدار بشكل كامل أو جزئي. يمكنك أيضًا استخدام أدوات الربط ^ و$ لمطابقة بداية سلسلة مستهدَفة أو نهايتها أو السلسلة بأكملها.

شرائح جمهور المستخدمين تشمل كل ما يلي:
تشمل واحدًا على الأقل مما يلي:
لا تشمل كل ما يلي:
لا تشمل واحدًا على الأقل مما يلي:
اختَر شريحة جمهور واحدة أو أكثر لاستهداف المستخدمين الذين قد يتم تضمينهم في تجربتك.Analytics قد تتطلّب بعض التجارب التي تستهدف شرائح الجمهور Google Analytics بضعة أيام لتجميع البيانات لأنّها تخضع Analytics لوقت استجابة معالجة البيانات. من المرجّح أن تواجه هذا التأخير مع المستخدمين الجدد الذين يتم عادةً إدراجهم في شرائح الجمهور المؤهّلة بعد 24 إلى 48 ساعة من إنشائها، أو مع شرائح الجمهور التي تم إنشاؤها مؤخرًا.

بالنسبة إلى Remote Config، يعني هذا أنّه حتى إذا كان المستخدم مؤهلاً من الناحية الفنية للانضمام إلى شريحة جمهور، لن يتم تضمينه في التجربة إذا لم يضفه Analytics إلى شريحة الجمهور عند تنفيذ fetchAndActivate()‎.

خاصيّة المستخدم بالنسبة إلى النص:
يحتوي على،
لا يحتوي على،
يطابق تمامًا،
يحتوي على تعبير عادي

بالنسبة إلى الأرقام:
<، ≤، =، ≥، >
يتم استخدام Analytics خاصية مستخدم لاختيار المستخدمين الذين قد يتم تضمينهم في تجربة، مع توفّر مجموعة من الخيارات لاختيار قيم خاصية المستخدم.

على العميل، يمكنك ضبط قيم السلسلة فقط لخصائص المستخدم. بالنسبة إلى الشروط التي تستخدم عوامل تشغيل رقمية، تحوّل خدمة Remote Config قيمة خاصية المستخدم المقابلة إلى عدد صحيح أو عدد عشري.
عند استخدام عامل التشغيل يحتوي على تعبير عادي، يمكنك إنشاء تعبيرات عادية بتنسيق RE2. يمكن أن يتطابق التعبير العادي مع السلسلة المستهدفة للإصدار بشكل كامل أو جزئي. يمكنك أيضًا استخدام أدوات الربط ^ و$ لمطابقة بداية سلسلة مستهدَفة أو نهايتها أو السلسلة بأكملها.
البلد/المنطقة لا ينطبق بلد واحد أو أكثر أو مناطق مستخدَمة لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة  
اللغات لا ينطبق لغة واحدة أو أكثر ولغات محلية مستخدَمة لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة  
أول فتح قبل
بعد

استهداف المستخدمين استنادًا إلى المرة الأولى التي يفتحون فيها تطبيقك:

  • اختَر المستخدمون الجدد لاستهداف المستخدمين الذين يفتحون تطبيقك لأول مرة بعد تاريخ ووقت محدّدين في المستقبل.
  • اختَر النطاق الزمني لاستهداف المستخدمين الذين يفتحون تطبيقك لأول مرة خلال النطاق قبل التاريخ والوقت اللذين تحدّدهما أو بعدهما. يمكنك الجمع بين شرطَي قبل وبعد لاستهداف المستخدمين خلال نطاق زمني محدّد.

تتوفّر ميزة استهداف المستخدمين حسب أول فتح بعد اختيار تطبيق Android أو iOS، وهي متاحة حاليًا في إصدارات Remote Config حزمة تطوير البرامج (SDK) التالية: الإصدار 9.0.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) لمنصات Apple والإصدار 21.1.1 أو إصدار أحدث من حزمة تطوير البرامج (SDK) لنظام التشغيل Android (Firebase BoM الإصدار 30.3.0 أو إصدار أحدث).

يجب أيضًا تفعيل Analytics على الجهاز العميل أثناء حدث فتح التطبيق للمرة الأولى.

A/B Testing مقياس

عند إنشاء تجربتك، عليك اختيار مقياس أساسي أو مقياس هدف يتم استخدامه لتحديد الصيغة الفائزة. عليك أيضًا تتبُّع مقاييس أخرى لمساعدتك في فهم أداء كل صيغة من صيغ التجربة بشكل أفضل وتتبُّع المؤشرات المهمة التي قد تختلف لكل صيغة، مثل معدّل الاحتفاظ بالمستخدمين وثبات التطبيق والإيرادات الناتجة عن عمليات الشراء داخل التطبيق. يمكنك تتبُّع ما يصل إلى خمسة مقاييس غير مرتبطة بالهدف في تجربتك.

على سبيل المثال، لنفترض أنّك تستخدم Remote Config لإطلاق مسارَين مختلفَين للعبة في تطبيقك، وتريد تحسين الأداء من أجل عمليات الشراء داخل التطبيق والإيرادات من الإعلانات، ولكنّك تريد أيضًا تتبُّع ثبات كل صيغة ومعدّل الاحتفاظ بالمستخدمين لكل صيغة. في هذه الحالة، يمكنك اختيار إجمالي الإيرادات المقدَّرة كمقياس هدف لأنّه يشمل الإيرادات من عمليات الشراء داخل التطبيق والإيرادات من الإعلانات، ثم يمكنك إضافة ما يلي إلى مقاييس أخرى لتتبُّعها:

  • لتتبُّع معدّل الاحتفاظ بالمستخدمين يوميًا وأسبوعيًا، أضِف مقياسَي الاحتفاظ بالمستخدمين (من يومَين إلى 3 أيام) والاحتفاظ بالمستخدمين (من 4 إلى 7 أيام).
  • لمقارنة الاستقرار بين مسارَي اللعبة، أضِف مقياس المستخدمون الذين لم يواجهوا أي أعطال.
  • للاطّلاع على طرق عرض أكثر تفصيلاً لكل نوع من أنواع الإيرادات، أضِف إيرادات عمليات الشراء والإيرادات المقدَّرة من الإعلانات.

توفّر الجداول التالية تفاصيل حول كيفية احتساب مقاييس الأهداف والمقاييس الأخرى.

مقاييس الهدف

المقياس الوصف
المستخدمون الذين لم يواجههم أي تعطُّل النسبة المئوية للمستخدمين الذين لم يواجهوا أخطاء في تطبيقك تم رصدها بواسطة حزمة تطوير البرامج (SDK) Firebase Crashlytics أثناء التجربة.
الإيرادات المقدَّرة الناتجة من الإعلانات الأرباح المقدّرة من الإعلانات
إجمالي الأرباح المقدَّرة القيمة المجمّعة لعمليات الشراء والأرباح المقدّرة من الإعلانات
الأرباح من عمليات الشراء القيمة المجمّعة لجميع أحداث purchase وin_app_purchase
الاحتفاظ بالبيانات (يوم واحد) يشير ذلك إلى عدد المستخدمين الذين يعودون إلى تطبيقك يوميًا.
الاحتفاظ بالبيانات (من يومين إلى ثلاثة أيام) يشير ذلك إلى عدد المستخدمين الذين يعودون إلى تطبيقك خلال يومَين إلى 3 أيام.
الاحتفاظ بالبيانات (من 4 إلى 7 أيام) يشير ذلك إلى عدد المستخدمين الذين يعودون إلى تطبيقك خلال مدة تتراوح بين 4 و7 أيام.
الاحتفاظ بالبيانات (من 8 إلى 14 يومًا) يشير ذلك إلى عدد المستخدمين الذين يعودون إلى تطبيقك خلال الفترة من 8 إلى 14 يومًا.
الاحتفاظ بالبيانات (أكثر من 15 يومًا) يشير ذلك إلى عدد المستخدمين الذين يعودون إلى تطبيقك بعد مرور 15 يومًا أو أكثر على آخر استخدام لهم للتطبيق.
first_open هو Analytics حدث يتم تشغيله عندما يفتح المستخدِم تطبيقًا للمرة الأولى بعد تثبيته أو إعادة تثبيته. يتم استخدامها كجزء من مسار الإحالة الناجحة.

المقاييس الأخرى

المقياس الوصف
notification_dismiss حدث Analytics يتم تشغيله عندما يتم تجاهل إشعار مُرسَل بواسطة أداة إنشاء الإشعارات (على Android فقط).
notification_receive حدث Analytics يتم تشغيله عند تلقّي إشعار مُرسَل بواسطة أداة إنشاء الإشعارات أثناء عمل التطبيق في الخلفية (على أجهزة Android فقط).
os_update Analytics حدث يتتبّع وقت تحديث نظام تشغيل الجهاز إلى إصدار جديد.لمزيد من المعلومات، اطّلِع على الأحداث التي يتم جمعها تلقائيًا.
screen_view حدث Analytics يتتبّع الشاشات التي تمّت مشاهدتها داخل تطبيقك. لمزيد من المعلومات، راجِع مقالة تتبُّع مشاهدات الشاشة.
session_start Analytics حدث يتم فيه احتساب جلسات المستخدمين في تطبيقك. لمزيد من المعلومات، اطّلِع على الأحداث المجمّعة تلقائيًا.

تصدير البيانات في BigQuery

بالإضافة إلى عرض بيانات تجربة A/B Testing في وحدة تحكّم Firebase، يمكنك فحص بيانات التجربة وتحليلها في BigQuery. على الرغم من أنّ A/B Testing لا يتضمّن جدولاً منفصلاً BigQuery، يتم تخزين عضويات التجربة والصيغة في كل حدث Google Analytics ضمن جداول أحداث Analytics.

تكون خصائص المستخدِم التي تحتوي على معلومات التجربة بالتنسيق userProperty.key like "firebase_exp_%" أو userProperty.key = "firebase_exp_01"، حيث 01 هو رقم تعريف التجربة، وتحتوي userProperty.value.string_value على الفهرس (المستند إلى الصفر) لصيغة التجربة.

يمكنك استخدام خصائص المستخدمين في التجربة لاستخراج بيانات التجربة. يمنحك ذلك القدرة على تقسيم نتائج تجربتك بطرق مختلفة والتحقّق بشكل مستقل من نتائج A/B Testing.

للبدء، أكمل ما يلي كما هو موضّح في هذا الدليل:

  1. فعِّل عملية تصدير BigQuery إلى Google Analytics في وحدة تحكّم Firebase
  2. الوصول إلى بيانات A/B Testing باستخدام BigQuery
  3. استكشاف نماذج طلبات البحث

تفعيل ميزة BigQuery التصدير إلى Google Analytics في "وحدة تحكّم Firebase"

إذا كنت مشتركًا في خطة Spark، يمكنك استخدام BigQuery وضع الحماية للوصول إلى BigQuery بدون أي تكلفة، مع مراعاة حدود وضع الحماية. لمزيد من المعلومات، يُرجى الاطّلاع على مقالة الأسعار ووضع الحماية BigQuery.

أولاً، تأكَّد من أنّك تصدّر بيانات Analytics إلى BigQuery:

  1. افتح علامة التبويب عمليات الدمج، التي يمكنك الوصول إليها باستخدام > إعدادات المشروع في وحدة تحكّم Firebase.
  2. إذا كنت تستخدم BigQuery مع خدمات Firebase الأخرى، انقر على إدارة. بخلاف ذلك، انقر على ربط.
  3. راجِع لمحة عن ربط Firebase بـ BigQuery، ثمّ انقر على التالي.
  4. في قسم ضبط عملية الدمج، فعِّل زر التبديل Google Analytics.
  5. اختَر منطقة وحدِّد إعدادات التصدير.

  6. انقر على الربط بـ BigQuery.

قد يستغرق توفّر الجداول مدة تصل إلى يوم واحد، وذلك حسب طريقة تصدير البيانات التي اخترتها. لمزيد من المعلومات حول تصدير بيانات المشروع إلى BigQuery، يُرجى الاطّلاع على تصدير بيانات المشروع إلى BigQuery.

الوصول إلى بيانات A/B Testing في BigQuery

قبل طلب بيانات لتجربة معيّنة، عليك الحصول على بعض أو كل ما يلي لاستخدامه في طلب البحث:

  • معرّف التجربة: يمكنك الحصول عليه من عنوان URL الخاص بصفحة نظرة عامة على التجربة. على سبيل المثال، إذا كان عنوان URL يبدو على النحو التالي: https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25، يكون رقم تعريف التجربة هو 25.
  • معرّف الموقع Google Analytics: هو معرّف الموقع المكوّن من 9 أرقام Google Analytics. يمكنك العثور على هذا المعرّف ضمن Google Analytics، ويظهر أيضًا في BigQuery عند توسيع اسم مشروعك لعرض اسم جدول أحداث Google Analytics (project_name.analytics_000000000.events).
  • تاريخ التجربة: لإنشاء طلب بحث أسرع وأكثر فعالية، من الممارسات الجيدة أن تحصر طلبات البحث على أقسام جدول الأحداث اليومية Google Analytics التي تحتوي على بيانات تجربتك، أي الجداول التي يتم تحديدها باللاحقة YYYYMMDD. لذا، إذا كانت تجربتك قد استمرت من 2 شباط (فبراير) 2024 إلى 2 أيار (مايو) 2024، عليك تحديد _TABLE_SUFFIX between '20240202' AND '20240502'. للاطّلاع على مثال، راجِع مقالة اختيار قيم تجربة معيّنة.
  • أسماء الأحداث: تتطابق هذه الأسماء عادةً مع مقاييس الأهداف التي أعددتها في التجربة. على سبيل المثال، أحداث in_app_purchase أو ad_impression أو user_retention.

بعد جمع المعلومات التي تحتاج إليها لإنشاء طلب البحث، اتّبِع الخطوات التالية:

  1. افتح BigQuery في وحدة تحكّم Google Cloud.
  2. اختَر مشروعك، ثم انقر على إنشاء طلب بحث بلغة الاستعلامات البنيوية (SQL).
  3. أضِف طلب البحث. للاطّلاع على أمثلة لطلبات البحث التي يمكن تنفيذها، راجِع استكشاف أمثلة لطلبات البحث.
  4. انقر على تشغيل.

طلب بيانات التجربة باستخدام طلب البحث الذي تم إنشاؤه تلقائيًا في وحدة تحكّم Firebase

إذا كنت تستخدم خطة Blaze، تقدّم صفحة نظرة عامة على التجربة نموذج طلب بحث يعرض اسم التجربة وخياراتها وأسماء الأحداث وعدد الأحداث للتجربة التي تشاهدها.

للحصول على الاستعلام الذي يتم إنشاؤه تلقائيًا وتشغيله، اتّبِع الخطوات التالية:

  1. من وحدة تحكّم Firebase، افتح A/B Testing واختَر تجربة A/B Testing التي تريد طلب البحث عنها لفتح نظرة عامة على التجربة.
  2. من قائمة "الخيارات" (Options)، ضِمن BigQuery التكامل، اختَر الاستعلام عن بيانات التجربة. سيؤدي ذلك إلى فتح مشروعك في BigQuery ضمن وحدة تحكّم Google Cloud، كما سيوفّر طلب بحث أساسيًا يمكنك استخدامه للاستعلام عن بيانات تجربتك.

يعرض المثال التالي طلب بحث تم إنشاؤه لتجربة تتضمّن ثلاث صيغ (بما في ذلك الصيغة الأساسية) باسم "تجربة الترحيب بالشتاء". تعرض هذه السمة اسم التجربة النشطة واسم المتغير والحدث الفريد وعدد الأحداث لكل حدث. يُرجى العِلم أنّ أداة إنشاء طلبات البحث لا تحدّد اسم مشروعك في اسم الجدول، لأنّها تفتح مباشرةً ضِمن مشروعك.

  /*
    This query is auto-generated by Firebase A/B Testing for your
    experiment "Winter welcome experiment".
    It demonstrates how you can get event counts for all Analytics
    events logged by each variant of this experiment's population.
  */
  SELECT
    'Winter welcome experiment' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'Welcome message (1)'
      WHEN '2' THEN 'Welcome message (2)'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_000000000.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN '20240202' AND '20240502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

للاطّلاع على أمثلة إضافية لطلبات البحث، انتقِل إلى استكشاف أمثلة لطلبات البحث.

استكشاف أمثلة على طلبات البحث

تقدّم الأقسام التالية أمثلة على طلبات البحث التي يمكنك استخدامها لاستخراج بيانات التجارب من جداول أحداث Google Analytics.A/B Testing

استخراج قيم الانحراف المعياري لعمليات الشراء والتجارب من جميع التجارب

يمكنك استخدام بيانات نتائج التجربة للتحقّق بشكل مستقل من Firebase A/B Testingالنتائج. يستخرج بيان SQL التالي صيغ التجربة وعدد المستخدِمين الفريدين في كل صيغة ويجمع إجمالي الأرباح من أحداث in_app_purchase وecommerce_purchase والانحرافات المعيارية لجميع التجارب ضمن النطاق الزمني المحدّد كتاريخَي البدء والانتهاء _TABLE_SUFFIX.BigQuery يمكنك استخدام البيانات التي تحصل عليها من طلب البحث هذا مع أداة إنشاء الدلالة الإحصائية لاختبارات t أحادية الطرف للتأكّد من أنّ النتائج التي يقدّمها Firebase تتطابق مع التحليل الخاص بك.

لمزيد من المعلومات حول كيفية احتساب A/B Testing للاستنتاج، اطّلِع على تفسير نتائج الاختبار.

  /*
    This query returns all experiment variants, number of unique users,
    the average USD spent per user, and the standard deviation for all
    experiments within the date range specified for _TABLE_SUFFIX.
  */
  SELECT
    experimentNumber,
    experimentVariant,
    COUNT(*) AS unique_users,
    AVG(usd_value) AS usd_value_per_user,
    STDDEV(usd_value) AS std_dev
  FROM
    (
      SELECT
        userProperty.key AS experimentNumber,
        userProperty.value.string_value AS experimentVariant,
        user_pseudo_id,
        SUM(
          CASE
            WHEN event_name IN ('in_app_purchase', 'ecommerce_purchase')
              THEN event_value_in_usd
            ELSE 0
            END) AS usd_value
      FROM `PROJECT_NAME.analytics_ANALYTICS_ID.events_*`
      CROSS JOIN UNNEST(user_properties) AS userProperty
      WHERE
        userProperty.key LIKE 'firebase_exp_%'
        AND event_name IN ('in_app_purchase', 'ecommerce_purchase')
        AND (_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYMMDD')
      GROUP BY 1, 2, 3
    )
  GROUP BY 1, 2
  ORDER BY 1, 2;

اختيار قيم تجربة معيّنة

يوضّح مثال طلب البحث التالي كيفية الحصول على بيانات لتجربة معيّنة في BigQuery. يعرض نموذج الاستعلام هذا اسم التجربة وأسماء المتغيرات (بما في ذلك "الخيار الأساسي") وأسماء الأحداث وعدد الأحداث.

  SELECT
    'EXPERIMENT_NAME' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'VARIANT_1_NAME'
      WHEN '2' THEN 'VARIANT_2_NAME'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_ANALYTICS_PROPERTY.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN 'YYYMMDD' AND 'YYYMMDD')
    AND userProperty.key = 'firebase_exp_EXPERIMENT_NUMBER'
  GROUP BY
    experimentVariant, eventName