إنشاء تجارب "الإعداد عن بُعد في 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. وهو مدعوم من قبل متابعة Remote Config إصدار من حزمة تطوير البرامج (SDK): الإصدار 9.0.0 أو الإصدارات الأحدث من حزمة تطوير البرامج (SDK) لمنصّات Apple والإصدار 21.1.1 من حزمة تطوير البرامج (SDK) لنظام التشغيل Android والإصدارات الأحدث (Firebase BoM الإصدار 30.3.0 والإصدارات الأحدث).

      يجب أيضًا تفعيل 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+KTX

    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& 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 أو منشئ الإشعارات أو 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 مستقلة. بعد اختياره، ستتم إعادة توجيهك إلى شاشة إنشاء FIAM لإجراء أي التغييرات (إذا لزم الأمر) قبل النشر.

توسيع التجربة

إذا تبيّن لك أنّ إحدى التجارب لا تجذب عددًا كافيًا من المستخدمين للحملة 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. التطبيق. يتوافق التطبيق حاليًا مع حزمة تطوير البرامج (SDK) التالية من "Remote Config". الإصدارات: حزمة تطوير البرامج (SDK) لنظام التشغيل Apple الإصدار 9.0.0 أو الإصدارات الأحدث والإصدار 21.1.1 من حزمة تطوير البرامج (SDK) لنظام التشغيل Android أو الإصدارات الأحدث (Firebase BoM الإصدار 30.3.0 والإصدارات الأحدث).

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

مقياسان (A/B Testing)

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

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

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

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

مقاييس الهدف

المقياس الوصف
المستخدمون الذين لم يواجههم أي تعطُّل يشير هذا المقياس إلى النسبة المئوية للمستخدمين الذين لم تواجههم أي أخطاء في تطبيقك. تم رصدها بواسطة حزمة تطوير البرامج (SDK) Firebase Crashlytics أثناء التجربة.
الأرباح المقدّرة الناتجة عن الإعلانات أرباح الإعلانات المقدّرة.
إجمالي الأرباح المقدَّرة القيمة المجمّعة لعملية الشراء وأرباح الإعلانات المقدّرة.
الأرباح من عمليات الشراء القيمة المُجمَّعة لكل purchase حدثان (in_app_purchase).
الاحتفاظ بالبيانات (يوم واحد) يشير ذلك إلى عدد المستخدمين الذين يعودون إلى تطبيقك يوميًا.
الاحتفاظ بالاشتراكات (من يومَين إلى 3 أيام) يشير ذلك إلى عدد المستخدمين الذين يعودون إلى تطبيقك في غضون يومَين إلى 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. من قائمة الخيارات، ضمن دمج 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

للحصول على أمثلة إضافية على طلبات البحث، انتقِل إلى الاطّلاع على نماذج طلبات البحث

الاطّلاع على أمثلة طلبات البحث

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

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

يمكنك استخدام بيانات نتائج التجربة لإثبات الهوية بشكل مستقل. Firebase A/B Testing نتيجة عبارة SQL التالية: BigQuery استخراج تجربة الصيغ، وعدد المستخدمين الفريدين في كل صيغة، وحساب إجمالي الأرباح من الحدثَين in_app_purchase وecommerce_purchase، والانحرافات المعيارية لجميع التجارب ضمن النطاق الزمني المحدّد على أنه _TABLE_SUFFIX يبدأ وتواريخ الانتهاء. يمكنك استخدام البيانات التي تحصل عليها من هذا الاستعلام منشئ الدلالة الإحصائية لاختبارات 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