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

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

حجم العينة

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

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

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

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

لتعديل تجربة، اتّبِع الخطوات التالية:

  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 إلى أنّه إذا كان الفرق الحقيقي صفرًا، هناك فرصة أقل من% 5 لحدوث فرق ملحوظ بهذا التطرف بشكل عشوائي. بما أنّ 0.05 هو الحدّ الأدنى، فإنّ أي قيمة احتمالية أقل من 0.05 تشير إلى اختلاف ذي دلالة إحصائية بين الصيغ.
  • تشير القيمة الاحتمالية الأكبر من 0.05 إلى أنّ الفرق بين الصيغ ليس ذا دلالة إحصائية.

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

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

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

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

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

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

بيانات الاستدلال

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

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

  • القيمة الاحتمالية، التي تمثّل احتمال ملاحظة بيانات متطرفة مثل النتائج التي تم الحصول عليها في التجربة، بافتراض عدم وجود فرق حقيقي بين السعر المتغير والسعر الأساسي كلما كانت القيمة الاحتمالية أقل، زادت الثقة في أنّ الأداء المرصود سيظل صحيحًا إذا كرّرنا التجربة. تشير القيمة 0.05 أو أقل إلى وجود فرق كبير وانخفاض احتمالية أن تكون النتائج ناتجة عن الصدفة. تستند القيم الاحتمالية إلى اختبار أحادي الطرف، حيث تكون قيمة "السعر المتغير" أكبر من قيمة "السعر الأساسي". تستخدِم 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. في قسم ضبط عملية الدمج، فعِّل زر التبديل 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

الحدود

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

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

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

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