عند التواصل مع المستخدمين أو بدء حملة تسويقية جديدة، عليك التأكّد من تنفيذ ذلك بشكل صحيح. يمكن أن يساعدك اختبار A/B في العثور على الصياغة وطريقة العرض الأمثل من خلال اختبار صيغ مختلفة للرسائل على أجزاء محدّدة من قاعدة المستخدمين. سواء كان هدفك هو تحسين معدّل الاحتفاظ بالمستخدمين أو زيادة الإحالات الناجحة من خلال عرض ترويجي، يمكن أن يُجري اختبار A/B تحليلاً إحصائيًا لتحديد ما إذا كانت صيغة الرسالة تحقّق أداءً أفضل من المرجع الأساسي لهدفك المحدّد.
لإجراء اختبار A/B على صيغ الميزات باستخدام قيمة أساسية، اتّبِع الخطوات التالية:
- أنشئ تجربتك.
- التحقّق من صحة تجربتك على جهاز اختباري
- إدارة تجربتك
إنشاء تجربة
تتيح لك التجربة التي تستخدم "منشئ الإشعارات" تقييم صيغ متعددة لرسالة إشعار واحدة.
يُرجى التأكّد من تفعيل Google Analytics في مشروعك لكي تتمكّن التجربة من الوصول إلى بيانات Analytics.
إذا لم تفعّل "Google Analytics" عند إنشاء مشروعك، يمكنك تفعيله في علامة التبويب
الإعدادات > عمليات الدمج ضمن وحدة تحكّم "Firebase".في وحدة تحكّم Firebase، انتقِل إلى DevOps & Engagement > اختبار A/B.
انقر على إنشاء تجربة، ثم اختَر الإشعارات عندما يُطلب منك تحديد الخدمة التي تريد تجربتها.
أدخِل اسمًا ووصفًا اختياريًا لتجربتك، ثم انقر على التالي.
املأ حقول الاستهداف، واختَر أولاً التطبيق الذي يستخدم تجربتك. يمكنك أيضًا استهداف مجموعة فرعية من المستخدمين للمشاركة في تجربتك من خلال تحديد خيارات تشمل ما يلي:
- الإصدار: إصدار واحد أو أكثر من تطبيقك
- شريحة جمهور المستخدمين: شرائح الجمهور (عددها Analytics) المستخدَمة لاستهداف المستخدمين الذين قد يتم تضمينهم في التجربة
- خاصية المستخدم: خاصية مستخدم واحدة أو أكثر في Analytics لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة
- البلد أو المنطقة: بلد أو منطقة واحدة أو أكثر لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة
- لغة الجهاز: لغة واحدة أو أكثر وإعدادات محلية تُستخدَم لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة
- الفتح لأول مرة: يمكنك استهداف المستخدمين استنادًا إلى المرة الأولى التي فتحوا فيها تطبيقك
- آخر تفاعل مع التطبيق: يمكنك استهداف المستخدمين استنادًا إلى آخر مرة تفاعلوا فيها مع تطبيقك
اضبط النسبة المئوية للمستخدمين المستهدَفين: اختَر النسبة المئوية لقاعدة مستخدمي تطبيقك التي تطابق المعايير المحدّدة ضمن المستخدمون المستهدَفون والتي تريد تقسيمها بالتساوي بين الإصدار الأساسي وصيغة واحدة أو أكثر في تجربتك. ويمكن أن تكون أي نسبة مئوية بين %0.01 و%100. تتم إعادة تحديد النِسب المئوية عشوائيًا للمستخدمين في كل تجربة، بما في ذلك التجارب المكرّرة.
في قسم الصيغ، اكتب رسالة لإرسالها إلى المجموعة الأساسية في حقل إدخال نص الرسالة. لعدم إرسال أي رسالة إلى مجموعة المرجع، اترك هذا الحقل فارغًا.
(اختياري) لإضافة أكثر من صيغة واحدة إلى تجربتك، انقر على إضافة صيغة. بشكل تلقائي، تتضمّن التجارب مجموعة أساسية واحدة وصيغة واحدة.
(اختياري) أدخِل اسمًا لكل صيغة في تجربتك لاستبدال الأسماء الصيغة "أ" والصيغة "ب" وما إلى ذلك.
حدِّد مقياسًا لهدف تجربتك لاستخدامه عند تقييم صيغ التجربة، بالإضافة إلى أي مقاييس إضافية مطلوبة من القائمة المنسدلة. وتشمل هذه المقاييس الأهداف المضمّنة (التفاعل وعمليات الشراء والإيرادات والاحتفاظ بالمستخدمين وما إلى ذلك) وأحداث الإحالات الناجحة في "Analytics" وأحداث "Analytics" الأخرى.
حدِّد خيارات لرسالتك:
- تاريخ التسليم: اختَر الإرسال الآن لإطلاق تجربتك فورًا عند الحفظ، أو مجدوَل لتحديد وقت لإطلاق تجربتك في المستقبل.
- الخيارات المتقدّمة: لتحديد الخيارات المتقدّمة لجميع الإشعارات المضمّنة في تجربتك، وسِّع الخيارات المتقدّمة، ثم غيِّر أيًا من خيارات الرسائل المدرَجة.
انقر على مراجعة لحفظ تجربتك.
يُسمح لك بإجراء ما يصل إلى 300 تجربة لكل مشروع (بما في ذلك عمليات الطرح)، ويمكن أن تتألف من 24 تجربة وعملية طرح قيد التشغيل، مع اعتبار الباقي تجارب مكتملة.
التحقّق من صحة تجربتك على جهاز اختباري
بالنسبة إلى كل عملية تثبيت في Firebase، يمكنك استرداد رمز التسجيل المميّز FCM المرتبط بها. يمكنك استخدام هذا الرمز المميّز لاختبار صيغ تجربة معيّنة على جهاز اختباري تم تثبيت تطبيقك عليه. للتحقّق من صحة تجربتك على جهاز اختباري، اتّبِع الخطوات التالية:
- احصل على رمز التسجيل في FCM على النحو التالي:
Swift
Messaging.messaging().token { token, error in if let error = error { print("Error fetching remote FCM registration token: \(error)") } else if let token = token { print("Remote instance ID token: \(token)") } }
Objective-C
[[FIRMessaging messaging] tokenWithCompletion:^(NSString * _Nullable token, NSError * _Nullable error) { if (error != nil) { NSLog(@"Error fetching the remote FCM registration token: %@", error); } else { NSLog(@"Remote FCM registration token: %@", token); NSString* message = [NSString stringWithFormat:@"FCM registration token: %@", token]; // display message NSLog(@"%@", message); } }];
Java
FirebaseMessaging.getInstance().getToken() .addOnCompleteListener(new OnCompleteListener<String>() { @Override public void onComplete(@NonNull Task<String> task) { if (!task.isSuccessful()) { Log.w(TAG, "Fetching FCM registration token failed", task.getException()); return; } // Get new FCM registration token String token = task.getResult(); // Log and toast String msg = getString(R.string.msg_token_fmt, token); Log.d(TAG, msg); Toast.makeText(MainActivity.this, msg, Toast.LENGTH_SHORT).show(); } });
Kotlin
FirebaseMessaging.getInstance().token.addOnCompleteListener(OnCompleteListener { task -> if (!task.isSuccessful) { Log.w(TAG, "Fetching FCM registration token failed", task.exception) return@OnCompleteListener } // Get new FCM registration token val token = task.result // Log and toast val msg = getString(R.string.msg_token_fmt, token) Log.d(TAG, msg) Toast.makeText(baseContext, msg, Toast.LENGTH_SHORT).show() })
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.Messaging.FirebaseMessaging.DefaultInstance.GetTokenAsync().ContinueWith( task => { if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) { UnityEngine.Debug.Log(System.String.Format("FCM registration token {0}", task.Result)); } });
- في وحدة تحكّم Firebase، انتقِل إلى DevOps & Engagement > اختبار A/B.
- انقر على مسودة، ثم مرِّر مؤشر الماوس فوق تجربتك، وانقر على قائمة السياق (more_vert)، ثم انقر على إدارة الأجهزة الاختبارية
- أدخِل الرمز المميّز FCM لجهاز اختبار واختَر صيغة التجربة التي تريد إرسالها إلى جهاز الاختبار هذا.
- شغِّل التطبيق وتأكَّد من تلقّي الصيغة المحدّدة على الجهاز الاختباري.
إدارة تجربتك
Whether you create an experiment with Remote Config, the Notifications composer, or Firebase In-App Messaging, you can then validate and start your experiment, monitor your experiment while it is running, and increase the number of users included in your running experiment.
عند انتهاء التجربة، يمكنك تدوين الإعدادات التي استخدمتها الصيغة الفائزة، ثم تطبيق هذه الإعدادات على جميع المستخدمين. أو يمكنك إجراء تجربة أخرى.
بدء تجربة
- في وحدة تحكّم Firebase، انتقِل إلى DevOps & Engagement > اختبار A/B.
- انقر على مسودة، ثم انقر على عنوان تجربتك.
- للتأكّد من أنّ تطبيقك يضم مستخدمين سيتم تضمينهم في تجربتك، وسِّع تفاصيل المسودة وابحث عن رقم أكبر من 0% في قسم الاستهداف والتوزيع (على سبيل المثال، %1 من المستخدمين المطابقين للمعايير).
- لتغيير تجربتك، انقر على تعديل.
- لبدء تجربتك، انقر على بدء التجربة. يمكنك إجراء ما يصل إلى 24 تجربة لكل مشروع في المرة الواحدة.
مراقبة تجربة
بعد تشغيل التجربة لفترة من الوقت، يمكنك الاطّلاع على مستوى تقدّمها ومعرفة النتائج التي حقّقتها للمستخدمين الذين شاركوا في تجربتك حتى الآن.
- في وحدة تحكّم Firebase، انتقِل إلى DevOps & Engagement > اختبار A/B.
انقر على قيد التشغيل، ثم انقر على عنوان تجربتك أو ابحث عنه. في هذه الصفحة، يمكنك الاطّلاع على إحصاءات مختلفة مرصودة ومستندة إلى نماذج حول تجربتك الجارية، بما في ذلك ما يلي:
- النسبة المئوية للاختلاف عن المرجع: مقياس لتحسين مقياس معيّن لصيغة معيّنة مقارنةً بالمرجع. يتم احتسابها من خلال مقارنة نطاق القيمة لنسخة الإعلان بنطاق القيمة للمجموعة المرجعية.
- احتمالية تجاوز المعدّل المرجعي: الاحتمالية المقدَّرة لتجاوز صيغة معيّنة للمعدّل المرجعي للمقياس المحدّد
- observed_metric لكل مستخدم: استنادًا إلى نتائج التجربة، هذا هو النطاق المتوقّع لقيمة المقياس بمرور الوقت.
- إجمالي observed_metric: القيمة التراكمية التي تم رصدها للإصدار الأساسي أو الصيغة تُستخدم القيمة لقياس مدى جودة أداء كل صيغة تجربة، وتُستخدم لاحتساب التحسين ونطاق القيمة واحتمالية تجاوز المعدّل المرجعي واحتمالية أن تكون الصيغة الأفضل. استنادًا إلى المقياس الذي يتم قياسه، قد يحمل هذا العمود التصنيف "المدة لكل مستخدم" أو "الإيرادات لكل مستخدم" أو "معدل الاحتفاظ بالمستخدمين" أو "معدل الإحالات الناجحة".
بعد تنفيذ تجربتك لفترة من الوقت (7 أيام على الأقل لـ FCM وIn-App Messaging أو 14 يومًا لـ Remote Config)، تشير البيانات في هذه الصفحة إلى الصيغة "الرائدة"، إن وُجدت. تكون بعض القياسات مصحوبة برسم بياني شريطي يعرض البيانات بتنسيق مرئي.
طرح تجربة لجميع المستخدمين
بعد تنفيذ التجربة لمدة كافية للحصول على صيغة "رائدة" أو صيغة تحقّق أفضل أداء في ما يتعلّق بمقياس هدفك، يمكنك طرح التجربة على جميع المستخدمين. يتيح لك ذلك اختيار صيغة لنشرها لجميع المستخدمين من الآن فصاعدًا. حتى في حال لم تُنشئ تجربتك صيغة واضحة تحقّق أفضل أداء، لا يزال بإمكانك اختيار طرح صيغة لجميع المستخدمين.
- في وحدة تحكّم Firebase، انتقِل إلى DevOps & Engagement > اختبار A/B.
- انقر على مكتملة أو قيد التشغيل، ثم انقر على تجربة تريد طرحها لجميع المستخدمين، ثم انقر على قائمة السياق () طرح الصيغة.
يمكنك طرح تجربتك لجميع المستخدمين من خلال تنفيذ أحد الإجراءات التالية:
- بالنسبة إلى التجارب التي تستخدم منشئ الإشعارات، استخدِم مربّع الحوار طرح الرسالة لإرسال الرسالة إلى المستخدمين المستهدَفين المتبقّين الذين لم يشاركوا في التجربة.
- بالنسبة إلى تجربة Remote Config، اختَر صيغة لتحديد قيم مَعلمات Remote Config التي تريد تعديلها. تتم إضافة معايير الاستهداف التي تم تحديدها عند إنشاء التجربة كشرط جديد في نموذجك، وذلك للتأكّد من أنّ عملية الطرح لن تؤثر إلا في المستخدمين الذين تستهدفهم التجربة. بعد النقر على مراجعة في ميزة "الإعداد عن بُعد" للاطّلاع على التغييرات، انقر على نشر التغييرات لإكمال عملية الطرح.
- بالنسبة إلى تجربة In-App Messaging، استخدِم مربّع الحوار لتحديد الصيغة التي يجب طرحها كحملة In-App Messaging مستقلة. بعد اختيار الحملة، ستتم إعادة توجيهك إلى شاشة إنشاء حملات FIAM لإجراء أي تغييرات (إذا لزم الأمر) قبل النشر.
توسيع نطاق تجربة
إذا وجدت أنّ التجربة لا تجذب عددًا كافيًا من المستخدمين لكي يتمكّن A/B Testing من تحديد الصيغة الرائدة، يمكنك زيادة توزيع تجربتك للوصول إلى نسبة أكبر من قاعدة مستخدمي التطبيق.
- في وحدة تحكّم Firebase، انتقِل إلى DevOps & Engagement > اختبار A/B.
- اختَر التجربة الجارية التي تريد تعديلها.
- في نظرة عامة على التجربة، انقر على قائمة السياق ()، ثم انقر على تعديل التجربة قيد التنفيذ.
- يعرض مربّع الحوار الاستهداف خيارًا لزيادة النسبة المئوية للمستخدمين المشاركين في التجربة الجارية. اختَر رقمًا أكبر من النسبة المئوية الحالية وانقر على نشر. سيتم طرح التجربة للنسبة المئوية التي حدّدتها من المستخدمين.
تكرار تجربة أو إيقافها
- في وحدة تحكّم Firebase، انتقِل إلى DevOps & Engagement > اختبار A/B.
- انقر على مكتملة أو قيد التنفيذ، ثم مرِّر المؤشر فوق تجربتك، وانقر على قائمة السياق ()، ثم انقر على إنشاء نسخة طبق الأصل من التجربة أو إيقاف التجربة.
استهداف المستخدمين
يمكنك استهداف المستخدمين لتضمينهم في تجربتك باستخدام معايير استهداف المستخدمين التالية.
| معيار الاستهداف | المشغِّلون | القيم | ملاحظة |
|---|---|---|---|
| الإصدار | يحتوي على،
لا يحتوي على، يتطابق تمامًا، يحتوي على تعبير نمطي (regex) |
أدخِل قيمة لإصدار واحد أو أكثر من إصدارات التطبيق التي تريد تضمينها في التجربة. |
عند استخدام أيّ من عوامل التشغيل يحتوي على أو لا يحتوي على أو يطابق تمامًا، يمكنك تقديم قائمة قيم مفصولة بفاصلة. عند استخدام عامل التشغيل يحتوي على تعبير نمطي، يمكنك إنشاء تعبيرات نمطية بتنسيق RE2. يمكن أن يتطابق التعبير العادي مع سلسلة إصدار الاستهداف بالكامل أو مع جزء منها. يمكنك أيضًا استخدام الرمزين ^ و$ لمطابقة بداية سلسلة مستهدفة أو نهايتها أو السلسلة بأكملها. |
| شرائح الجمهور | يتضمّن كلّاً من،
يتضمّن واحدًا على الأقل من، لا يتضمّن كلّاً من، لا يتضمّن واحدًا على الأقل من |
اختَر شريحة جمهور واحدة أو أكثر من شرائح جمهور "Analytics" لاستهداف المستخدمين الذين قد يتم تضمينهم في تجربتك. | قد تتطلّب بعض التجارب التي تستهدف جماهير Google Analytics بضعة أيام لتجميع البيانات لأنّها تخضع Analytics لوقت استجابة معالجة البيانات. من المرجّح أن تواجه هذا التأخير مع المستخدمين الجدد الذين يتم تسجيلهم عادةً في شرائح الجمهور المؤهَّلة بعد فترة تتراوح بين 24 و48 ساعة من إنشائها، أو مع شرائح الجمهور التي تم إنشاؤها مؤخرًا. |
| خاصيّة المستخدم | بالنسبة إلى النصوص:
يحتوي على، لا يحتوي على، يتطابق تمامًا، يحتوي على تعبير عادي (regex) بالنسبة إلى الأرقام: <، ≤، =، ≥، > |
يتم استخدام سمة مستخدم Analytics لاختيار المستخدمين الذين قد يتم تضمينهم في تجربة، مع مجموعة من الخيارات لتحديد قيم سمات المستخدمين.
في العميل، يمكنك ضبط قيم السلسلة فقط لخصائص المستخدم. بالنسبة إلى الشروط التي تستخدم عوامل تشغيل رقمية، تحوّل خدمة Remote Config قيمة خاصية المستخدم المقابلة إلى عدد صحيح/عشري. |
عند استخدام عامل التشغيل يحتوي على تعبير نمطي، يمكنك إنشاء تعبيرات نمطية بتنسيق RE2. يمكن أن يتطابق التعبير العادي مع سلسلة إصدار الاستهداف بالكامل أو مع جزء منها. يمكنك أيضًا استخدام الرمزين ^ و$ لمطابقة بداية سلسلة مستهدفة أو نهايتها أو السلسلة بأكملها. |
| البلد/المنطقة | لا ينطبق | بلد واحد أو أكثر أو منطقة واحدة أو أكثر يتم استخدامها لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة. | |
| اللغات | لا ينطبق | لغة واحدة أو أكثر ولغات محلية مستخدَمة لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة. | |
| أول فتح |
أكثر من
أقل من بين |
استهداف المستخدمين استنادًا إلى المرة الأولى التي فتحوا فيها تطبيقك، ويتم تحديد ذلك بالأيام | |
| آخر تفاعل مع التطبيق |
أكثر من
أقل من بين |
استهداف المستخدمين استنادًا إلى آخر مرة تفاعلوا فيها مع تطبيقك، محددة بالأيام |
A/B Testing مقياس
عند إنشاء تجربتك، يمكنك اختيار مقياس أساسي أو مقياس هدف يُستخدَم لتحديد الصيغة الفائزة. يجب أيضًا تتبُّع المقاييس الأخرى لمساعدتك في فهم أداء كل صيغة تجربة بشكل أفضل وتتبُّع المؤشرات المهمة التي قد تختلف لكل صيغة، مثل الحفاظ على المستخدمين واستقرار التطبيق وإيرادات عمليات الشراء داخل التطبيق. يمكنك تتبُّع ما يصل إلى خمسة مقاييس غير مرتبطة بالأهداف في تجربتك.
على سبيل المثال، لنفترض أنّك أضفت عمليات شراء جديدة داخل التطبيق وتريد مقارنة فعالية رسالتَي "تنبيه" مختلفتَين. في هذه الحالة، يمكنك اختيار إيرادات الشراء كمقياس لهدفك لأنّك تريد أن تمثّل الصيغة الفائزة الإشعار الذي حقّق أعلى إيرادات من عمليات الشراء داخل التطبيق. ولأنّك تريد أيضًا تتبُّع الصيغة التي أدّت إلى المزيد من الإحالات الناجحة المستقبلية والمستخدمين الذين تم الاحتفاظ بهم، يمكنك إضافة ما يلي في مقاييس أخرى لتتبُّعها:
- إجمالي الإيرادات المقدَّرة لمعرفة مدى اختلاف إيرادات الإعلانات وعمليات الشراء داخل التطبيق بين الصيغتَين
- الحفاظ على المستخدمين (يوم واحد) والحفاظ على المستخدمين (يومان إلى 3 أيام) والحفاظ على المستخدمين (4 إلى 7 أيام) لتتبُّع معدّل الحفاظ على المستخدمين يوميًا أو أسبوعيًا
تقدّم الجداول التالية تفاصيل حول كيفية احتساب مقاييس الأهداف والمقاييس الأخرى.
مقاييس الهدف
| المقياس | الوصف |
|---|---|
| المستخدمون الذين لم يواجههم أي تعطُّل | النسبة المئوية للمستخدمين الذين لم يواجهوا أخطاء في تطبيقك تم رصدها من خلال حزمة تطوير البرامج (SDK) لـ "Firebase Crashlytics" أثناء التجربة.
ملاحظة: لا يتوفّر 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" بشكل مستقل.
للبدء، أكمِل الخطوات التالية كما هو موضّح في هذا الدليل:
- تفعيل عملية تصدير بيانات BigQuery إلى Google Analytics في وحدة تحكّم Firebase
- الوصول إلى بيانات "A/B Testing" باستخدام "BigQuery"
- استكشاف أمثلة على طلبات البحث
تفعيل تصدير بيانات "BigQuery" في "Google Analytics" ضمن "وحدة تحكُّم Firebase"
إذا كنت مشتركًا في خطة Spark، يمكنك استخدام وضع الحماية في BigQuery للوصول إلى BigQuery بدون أي تكلفة، وفقًا لحدود وضع الحماية. لمزيد من المعلومات، يُرجى الاطّلاع على التسعير و"BigQuery".
أولاً، تأكَّد من أنّك تصدّر بياناتك من "Analytics" إلى BigQuery:
في وحدة تحكّم Firebase، انتقِل إلى
الإعدادات > علامة التبويب عمليات الدمج.في بطاقة BigQuery، انقر على إدارة وتأكَّد من أنّ مشروعك يصدّر بيانات "Analytics" إلى "BigQuery".
إذا كانت البطاقة تتضمّن الخيار ربط، عليك إعداد عملية التصدير (انتقِل إلى الخطوة التالية).
إذا أردت إعداد عملية التصدير، اتّبِع الخطوات التالية:
راجِع المقالة لمحة عن ربط Firebase بـ "BigQuery"، ثم انقر على التالي.
في قسم ضبط عملية الدمج، فعِّل Google Analytics.
اختَر منطقة واضبط إعدادات التصدير.
انقر على الربط بـ "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 فبراير 2026 إلى 2 مايو 2026، عليك تحديد_TABLE_SUFFIX between '20260202' AND '20260502'. للاطّلاع على مثال، راجِع اختيار قيم تجربة معيّنة. - أسماء الأحداث: تتوافق عادةً مع
مقاييس الأهداف
التي تم ضبطها في التجربة. على سبيل المثال، أحداث
in_app_purchaseأوad_impressionأو أحداثuser_retention.
بعد جمع المعلومات التي تحتاجها لإنشاء طلب البحث:
- في وحدة تحكّم Google Cloud، انتقِل إلى BigQuery.
- اختَر مشروعك، ثم انقر على إنشاء طلب بحث SQL.
- أضِف طلب البحث. للاطّلاع على أمثلة على طلبات البحث التي يمكن تنفيذها، يُرجى مراجعة استكشاف أمثلة على طلبات البحث.
- انقر على تشغيل.
الاستعلام عن بيانات التجربة باستخدام طلب البحث الذي تم إنشاؤه تلقائيًا في وحدة تحكّم Firebase
إذا كنت تستخدم خطة Blaze، توفّر صفحة نظرة عامة على التجربة نموذج طلب بحث يعرض اسم التجربة والصيغ وأسماء الأحداث وعدد الأحداث للتجربة التي تعرضها.
للحصول على طلب البحث الذي تم إنشاؤه تلقائيًا وتنفيذه:
- في وحدة تحكّم Firebase، انتقِل إلى DevOps & Engagement > اختبار A/B.
- اختَر تجربة A/B Testing التي تريد الاستعلام عنها لفتح نظرة عامة على التجربة.
- من قائمة "الخيارات"، ضِمن دمج 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 '20260202' AND '20260502')
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