لمحة عن اختبارات A/B من Firebase

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

حجم العيّنة

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

تعديل التجارب

يمكنك تعديل مَعلمات محدّدة للتجارب الجارية، بما في ذلك:

  • اسم التجربة
  • الوصف
  • شروط الاستهداف
  • قيم خيارات المنتج

لتعديل تجربة:

  1. افتح صفحة نتائج التجربة التي تريد تعديلها.
  2. من قائمة المزيد ، انقر على تعديل التجربة الجارية.
  3. أدخِل التغييرات، ثم انقر على نشر.

يُرجى العلم أنّ تغيير سلوك التطبيق أثناء تنفيذ تجربة قد يؤثّر في النتائج.

منطق منح الصيغ في أداة "الإعداد عن بُعد"

يتمّ منح المستخدمين الذين يتطابقون مع جميع شروط استهداف التجربة (بما في ذلك شرط نسبة الظهور) صِيَغ التجربة وفقًا للمعدّلات المتغيرة ودالة التجزئة لرقم تعريف التجربة ورقم تعريف تثبيت Firebase للمستخدِم.

Google Analytics شرائح الجمهور تخضع لوقت الاستجابة ولا تتوفّر على الفور عندما يستوفي المستخدِم في البداية معايير شريحة الجمهور:

  • عند إنشاء شريحة جمهور جديدة، قد يستغرق تجميع المستخدِمين الجدد فترةً تتراوح بين 24 و48 ساعة.
  • يتم عادةً تسجيل المستخدِمين الجدد في شرائح الجمهور المؤهَّلة بعد 24 إلى 48 ساعة من تأهّلهم.

بالنسبة إلى الاستهداف الحسّاس للوقت، ننصحك باستخدام Google Analytics خصائص المستخدمين أو خيارات الاستهداف المضمّنة، مثل البلد أو المنطقة، والّغة، وإصدار التطبيق.

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

أحداث التفعيل

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

أوزان خيارات المنتج

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

تفسير نتائج الاختبار

تستخدِم Firebase A/B Testing استنتاج التكرار لمساعدتك في فهم احتمالية حدوث نتائج تجربتك بسبب الصدفة المبرمَجة فقط. يتم تمثيل هذه الاحتمالية من خلال قيمة الاحتمالية أو القيمة الاحتمالية. القيمة الاحتمالية هي احتمال أن يكون الفرق في الأداء بين الصيغتين قد حدث بسبب صدفة عشوائية، ويتم قياسها باستخدام قيمة تتراوح بين 0 و1. يستخدم A/B Testing مستوى دلالة يبلغ 0.05 لكي:

  • تشير القيمة الاحتمالية التي تقل عن 0.05 إلى وجود فرق ذي دلالة إحصائية بين الصيغ، ما يعني أنّه من غير المرجّح أن يكون قد حدث صدفة عشوائية.
  • تشير قيمة p-value التي تزيد عن 0.05 إلى أنّ الفرق بين الصيغ ليس ذا دلالة إحصائية.

تتم إعادة تحميل بيانات التجربة مرة واحدة في اليوم، ويظهر وقت آخر تعديل في أعلى صفحة نتائج التجربة.

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

يتم تقسيم النتائج إلى البيانات المرصودة وبيانات الاستنتاج. يتم احتساب البيانات المرصودة مباشرةً من بيانات "إحصاءات Google"، وتقدّم بيانات الاستنتاج قيم p وفواصل الثقة لمساعدتك في تقييم الملحظات الإحصائية للبيانات المرصودة.

يتم عرض الإحصاءات التالية لكل مقياس:

البيانات المرصودة

  • إجمالي قيمة المقياس الذي يتم تتبُّعه (عدد المستخدمين الذين تم الاحتفاظ بهم، وعدد المستخدمين الذين حدثت لهم أعطال، وإجمالي الأرباح)
  • معدّل خاص بالمقياس (معدل الاحتفاظ بالمستخدمين، ومعدّل الإحالات الناجحة، والأرباح من كل مستخدم)
  • النسبة المئوية للفرق (تأثير العلامة التجارية) بين السعر المتغير والسعر الأساسي

بيانات الاستنتاج

  • فاصل الثقة بنسبة% 95 (فرق المتوسطات) يعرض فاصلًا يحتوي على القيمة "الحقيقية" للمقياس الذي يتم تتبُّعه بمستوى ثقة% 95. على سبيل المثال، إذا كانت نتائج تجربتك تشير إلى أنّ فاصل الثقة بنسبة% 95 لإجمالي الأرباح المقدَّرة يقع بين 5 و10 دولار أمريكي، هناك احتمال بنسبة% 95 أن يكون الفرق الحقيقي في القيم المتوسّطة يقع بين 5 و10 دولار أمريكي. إذا كان نطاق فاصل الثقة يتضمّن القيمة 0، يعني ذلك أنّه لم يتم رصد اختلاف دالّ إحصائيًا بين السعر المتغير والسعر الأساسي.

    تظهر قيم فاصل الثقة بالتنسيق الذي يتطابق مع المقاييس التي يتم تتبُّعها. على سبيل المثال، الوقت (بوحدة HH:MM:SS) للحفاظ على المستخدِمين، والدولار الأمريكي لإيرادات الإعلانات لكل مستخدِم، والنسبة المئوية لمعدّل الإحالات الناجحة.

  • القيمة الاحتمالية، التي تمثّل احتمال عدم توفّر فرق حقيقي بين السعر المتغير والسعر الأساسي، أي أنّه من المحتمل أن يكون أيّ فرق تم رصده ناتجًا عن صدفة عشوائية. وكلما انخفضت القيمة الاحتمالية، زادت ثقتك في أنّ الأداء المرصود سيظل صحيحًا في المستقبل. تشير القيمة 0.05 أو أقل إلى اختلاف كبير واحتمالية منخفضة لحدوث النتائج عن طريق الصدفة. تستند قيم "p" إلى اختبار أحادي الطرف، حيث تكون قيمة "الصيغة" أكبر من قيمة "الأساس". تستخدِم Firebase اختبار t لدالة التباين غير المتكافئ للمتغيّرات المستمرة (القيم الرقمية، مثل الأرباح) واختبار z للنسب لبيانات الإحالات الناجحة (القيم الثنائية، مثل الحفاظ على المستخدمين، والمستخدمين الذين لم يواجهوا أي أعطال، والمستخدمين الذين يُشغِّلون حدث Google Analytics).

تقدّم نتائج التجربة إحصاءات مهمة لكل صيغة تجربة، بما في ذلك:

  • مقدار ارتفاع أو انخفاض كل مقياس من مقاييس التجربة مقارنةً بمستوى الأداء الأساسي، كما تم قياسه مباشرةً (أي البيانات الفعلية التي تم رصدها)
  • احتمال أن يكون الفرق المرصود بين السعر المتغير والقياس الأساسي قد حدث بسبب الصدفة العشوائية (القيمة الاحتمالية)
  • نطاق يُرجّح أن يحتوي على الفرق "الحقيقي" في الأداء بين الصيغة والمرجع لكل مقياس من مقاييس التجربة، وهي طريقة لفهم سيناريوهات الأداء "الحد الأقصى" و "الحد الأدنى"

تفسير نتائج التجارب المستندة إلى "أدوات تحسين الأداء من Google"

Firebase A/B Testing نتائج التجارب التي بدأت قبل 23 تشرين الأول (أكتوبر) 2023 تم إنشاؤها باستخدام "أدوات تحسين الأداء من Google". استخدَمت أداة Google Optimize الاستنتاج البايزي لمحاولة توليد إحصاءات مفيدة من بيانات تجربتك.

يتم تقسيم النتائج إلى "بيانات قابلة للتتبّع" و "بيانات مستندة إلى نماذج". تم احتساب البيانات المرصودة مباشرةً من بيانات "إحصاءات Google"، وتم الحصول على البيانات المستندة إلى نماذج من تطبيق نموذج "بايزي" على البيانات المرصودة.

يتم عرض الإحصاءات التالية لكل مقياس:

البيانات المرصودة

  • القيمة الإجمالية (مجموع المقياس لجميع المستخدِمين في الصيغة)
  • متوسّط القيمة (متوسّط قيمة المقياس للمستخدمين في الصيغة)
  • الفرق بالنسبة المئوية مقارنةً بقيمة الأساس

البيانات المستنِدة إلى نماذج

  • احتمالية تجاوز المعدّل الأساسي: احتمالية أن يكون المقياس أعلى لهذا السعر المتغير مقارنةً بالمعدّل الأساسي
  • النسبة المئوية للفرق عن الأساس: استنادًا إلى تقديرات النموذج المتوسط للمقياس لكلّ من السعر المتغير والسعر الأساسي
  • نطاقات المقياس: النطاقات التي يُرجّح العثور فيها على قيمة المقياس، مع نسبة تأكّد تتراوح بين% 50 و% 95

بشكل عام، تقدّم لنا نتائج التجربة ثلاث إحصاءات مهمة لكلّ صيغة في التجربة:

  1. مقدار ارتفاع أو انخفاض كل مقياس تجربة مقارنةً بمستوى الأداء الأساسي، كما تم قياسه مباشرةً (أي البيانات الفعلية التي تم رصدها)
  2. مدى احتمالية أن يكون كل مقياس من مقاييس التجربة أعلى من المقياس الأساسي / الأفضل بشكل عام، استنادًا إلى الاستنتاج البايزي (احتمالية أن يكون أفضل / الأفضل على التوالي)
  3. النطاقات المعقولة لكل مقياس تجربة استنادًا إلى الاستنتاج البايزي، أي سيناريوهات "أفضل حالة" و "أسوأ حالة" (الفواصل الزمنية الموثوق بها)

تحديد القائد

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

بالنسبة إلى التجارب التي استخدمت Google Optimize، أعلنت منصة Firebase أنّ الصيغة هي "الأفضل بوضوح" إذا كانت لديها احتمالية تزيد عن ‎95% لتحقيق أداء أفضل من الصيغة الأساسية في المقياس الأساسي. إذا كانت عدة الأسعار المتغيرة تستوفي معايير "السعر الواضح الأفضل أداءً"، يتم تصنيف السعر المتغير الأفضل أداءً فقط على أنّه "السعر الواضح الأفضل أداءً".

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

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

يمكنك طرح أيّ صيغة، وليس فقط صيغة رائدة، استنادًا إلى تقييمك العام للأداء على مستوى المقاييس الأساسية والثانوية.

مدّة التجربة

تنصح Firebase بمواصلة تنفيذ التجربة إلى أن يتم استيفاء الشروط التالية:

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

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

مخطّط 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. في قسم Configure integration (ضبط عملية الدمج)، فعِّل زر التبديل 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 events أو ad_impression أو user_retention events.

بعد جمع المعلومات التي تحتاجها لإنشاء طلب البحث:

  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

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

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

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

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

يمكنك استخدام بيانات نتائج التجربة للتحقّق بشكل مستقل من نتائج Firebase A/B Testing. تستخرج عبارة BigQuery SQL التالية صيغ تجربت ، وعدد المستخدِمين الفريدين في كل صيغة، وتُجمِّع إجمالي الأرباح من حدثَي 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

الحدود

تقتصر A/B Testing على 300 تجربة إجمالاً، و24 تجربة جارية، و24 مسودة تجربة. تتم مشاركة هذه الحدود مع عمليات طرح Remote Config. على سبيل المثال، إذا كان لديك طرحان قيد التنفيذ وثلاث تجارب قيد التنفيذ، يمكنك إجراء ما يصل إلى 19 عملية طرح أو تجربة إضافية.

  • إذا بلغت الحدّ الأقصى لعدد التجارب، وهو 300 تجربة، أو الحدّ الأقصى لعدد مسودّات التجارب، وهو 24 مسودة، يجب حذف تجربة حالية قبل إنشاء تجربة جديدة.

  • إذا بلغت الحدّ الأقصى المسموح به وهو 24 تجربة وطرحًا قيد التنفيذ، عليك إيقاف أحد تجربتك أو عمليات الطرح الجارية قبل بدء تجربة جديدة.

يمكن أن تحتوي التجربة على 8 صيغ كحدّ أقصى (بما في ذلك السعر الأساسي) وما يصل إلى 25 مَعلمة لكل صيغة. يمكن أن يصل حجم التجربة إلى حوالى 200 كيلوبايت. ويشمل ذلك أسماء الأسعار المتغيرة ومَعلمات الأسعار المتغيرة وغيرها من البيانات الوصفية للإعدادات.