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

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

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

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

1. أنشئ تجربتك.
2. إدارة تجربتك

إنشاء تجربة

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

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

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

2. في وحدة تحكّم Firebase، انتقِل إلى عمليات التطوير والتشغيل والتفاعل > A/B Testing

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

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

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

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

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

8. حدِّد معايير الاستهداف لتجربتك باستخدام شروط Remote Config:

   • إعادة استخدام شرط حالي: إذا كان هناك شرط حالي في نموذج Remote Config يتطابق مع جمهورك المستهدَف، اختَر الشرط من القائمة.

   • التأكّد من ترتيب تقييم الشروط: تأكَّد من ترتيب الشروط في صفحة الشروط حسب الأولوية الصحيحة. بما أنّ Remote Config يقيّم الشروط بالتسلسل من الأعلى إلى الأسفل، يمكن أن تمنع الشروط الأخرى ذات الأولوية الأعلى وصول عدد كافٍ من المستخدمين إلى الشرط المرتبط بتجربتك.

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

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

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

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

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

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

    • app_install
    • app_remove
    • app_update

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

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

12. انقر على حفظ لحفظ تجربتك. يجب نشر النموذج لبدء تنفيذ التجربة.

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

إدارة تجربتك

عند إنشاء تجربة باستخدام Remote Config، يمكنك بدء تجربتك ومراقبتها أثناء تنفيذها وزيادة عدد المستخدمين المضمّنين في تجربتك الجارية.

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

تعديل تجربة

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

مراقبة تجربة

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

1. في قسم DevOps والتفاعل ضمن قائمة التنقّل في Firebase وحدة التحكّم، انقر على Remote Config.
2. انقر على علامة التبويب اختبارات A/B.

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

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

4. بعد تنفيذ تجربتك لفترة من الوقت (14 يومًا في Remote Config)، تشير البيانات في هذه الصفحة إلى الصيغة "الأفضل"، إن وُجدت. تتضمّن بعض القياسات رسومات بيانية شريطية تعرض البيانات بتنسيق مرئي.

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

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

1. في قسم DevOps والتفاعل ضمن قائمة التنقّل في Firebase وحدة التحكّم، انقر على Remote Config.
2. انقر على علامة التبويب اختبارات A/B.
3. انقر على مكتملة أو قيد التنفيذ، ثم انقر على تجربة تريد طرحها لجميع المستخدمين، وانقر على قائمة السياق (more_vert) طرح الصيغة.
4. اطرح تجربتك على جميع المستخدمين من خلال اتّباع الخطوات التالية:
   • بالنسبة إلى تجربة Remote Config، اختَر صيغة لتحديد قيم مَعلمات Remote Config التي تريد تعديلها. تتم إضافة معايير الاستهداف التي تم تحديدها عند إنشاء التجربة كشرط جديد في نموذجك، وذلك للتأكّد من أنّ عملية الطرح لن تؤثر إلا في المستخدمين الذين تستهدفهم التجربة. بعد النقر على مراجعة في ميزة "الإعداد عن بُعد" للاطّلاع على التغييرات، انقر على نشر التغييرات لإكمال عملية الطرح.

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

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

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

تكرار تجربة

1. في قسم DevOps والتفاعل ضمن قائمة التنقّل في Firebase وحدة التحكّم، انقر على Remote Config.
2. انقر على علامة التبويب اختبارات A/B.
3. اختَر التجربة الجارية أو المكتملة التي تريد إيقافها.
4. انقر على مكتملة أو جارية، ثم مرِّر المؤشر فوق تجربتك، وانقر على قائمة السياق (more_vert)، ثم انقر على تكرار التجربة أو إيقاف التجربة.

إيقاف تجربة

1. في قسم DevOps والتفاعل ضمن قائمة التنقّل في Firebase وحدة التحكّم، انقر على Remote Config.
2. انقر على علامة التبويب اختبارات A/B.
3. اختَر التجربة الجارية أو المكتملة التي تريد إيقافها.
4. انقر على مكتملة أو جارية، ثم مرِّر المؤشر فوق تجربتك، وانقر على قائمة السياق (more_vert)، ثم انقر على إيقاف التجربة.

تحديد هوية عميل الويب واستمرار التجربة

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

تستخدِم Firebase A/B Testing معرّف FID لتحديد صيغ التجربة التي سيتم عرضها للمستخدمين، وتستخدِم Google Analytics معرّف FID لتجميع الأحداث من أجل قياس سلوك المستخدم وتحليله في كل صيغة.

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

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

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

تتوفّر أنواع القواعد التالية في وحدة تحكّم Firebase. تتوفّر ميزات مكافئة في واجهة برمجة تطبيقات Remote Config REST، كما هو موضّح بالتفصيل في مرجع التعبير الشرطي.

‫A/B Testing مقياس

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

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

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

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

مقاييس الهدف

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

تصدير البيانات في 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، انتقِل إلى علامة التبويب عمليات الدمج ضمن settings الإعدادات.

2. في بطاقة BigQuery، انقر على إدارة وتأكَّد من أنّ مشروعك يصدّر بيانات Analytics إلى BigQuery.

   إذا كانت البطاقة تعرض ربط، عليك إعداد عملية التصدير (انتقِل إلى الخطوة التالية).

3. إذا كنت بحاجة إلى إعداد عملية التصدير، اتّبِع الخطوات التالية:

   1. راجِع لمحة عن ربط Firebase بـ BigQuery، ثم انقر على التالي.

   2. في قسم ضبط عملية الدمج، فعِّل Google Analytics.

   3. اختَر منطقة وحدِّد إعدادات التصدير.

   4. انقر على الربط بـ 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: هو معرّف الموقع Google Analytics المكوّن من 9 أرقام. يمكنك العثور على هذا الخيار ضمن 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. في وحدة تحكّم Google Cloud، انتقِل إلى BigQuery.
2. اختَر مشروعك، ثم انقر على إنشاء طلب بحث بلغة الاستعلامات البنيوية (SQL).
3. أضِف طلب البحث. للاطّلاع على أمثلة على طلبات البحث التي يمكنك تنفيذها، راجِع استكشاف أمثلة على طلبات البحث.
4. انقر على تشغيل.

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

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

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

1. في Firebase console، انتقِل إلى DevOps & Engagement > اختبار A/B.
2. اختَر التجربة A/B Testing التي تريد طلب البحث عنها لفتح لمحة عن التجربة.
3. من قائمة "الخيارات" (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

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

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

تقدّم الأقسام التالية أمثلة على طلبات البحث التي يمكنك استخدامها لاستخراج بيانات تجربة 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