عند التواصل مع المستخدمين أو بدء حملة تسويقية جديدة، عليك التأكّد من تنفيذ ذلك بشكل صحيح. يمكن أن يساعدك اختبار A/B في العثور على الصياغة وطريقة العرض الأمثل من خلال اختبار صيغ مختلفة للرسائل على أجزاء محدّدة من قاعدة المستخدمين. سواء كان هدفك هو تحسين معدّل الاحتفاظ بالمستخدمين أو زيادة الإحالات الناجحة من خلال عرض ترويجي، يمكن أن يُجري اختبار A/B تحليلاً إحصائيًا لتحديد ما إذا كانت صيغة الرسالة تحقّق أداءً أفضل من المرجع الأساسي لهدفك المحدّد.
لإجراء اختبار A/B على صيغ الميزات باستخدام قيمة أساسية، اتّبِع الخطوات التالية:
- أنشئ تجربتك.
- التحقّق من صحة تجربتك على جهاز اختباري
- إدارة تجربتك
إنشاء تجربة
تتيح لك التجربة التي تستخدم Firebase In-App Messaging تقييم صيغ متعددة لرسالة واحدة داخل التطبيق.
يُرجى التأكّد من تفعيل Google Analytics في مشروعك لكي تتمكّن التجربة من الوصول إلى بيانات Analytics.
إذا لم تفعّل "Google Analytics" عند إنشاء مشروعك، يمكنك تفعيلها في علامة التبويب
الإعدادات > عمليات الدمج ضمن وحدة تحكّم Firebase.في وحدة تحكّم Firebase، ابدأ تجربة Firebase In-App Messaging باستخدام أحد الخيارات التالية:
من "A/B Testing":
انتقِل إلى DevOps & Engagement > اختبار A/B.
انقر على إنشاء تجربة، ثم اختَر المراسلة داخل التطبيق عندما يُطلب منك تحديد الخدمة التي تريد تجربتها.
من "In-App Messaging":
انتقِل إلى عمليات التطوير والتفاعل > المراسلة.
انقر على In-App Messaging، ثم على تجربة جديدة.
أدخِل اسمًا ووصفًا اختياريًا لتجربتك، ثم انقر على التالي.
املأ حقول الاستهداف، واختَر أولاً التطبيق الذي يستخدم تجربتك. يمكنك أيضًا استهداف مجموعة فرعية من المستخدمين للمشاركة في تجربتك من خلال تحديد خيارات تشمل ما يلي:
- الإصدار: إصدار واحد أو أكثر من تطبيقك
- شريحة الجمهور المستهدَفة: Analytics شرائح جمهور مستخدَمة لاستهداف المستخدمين الذين قد يتم تضمينهم في التجربة
- خاصية المستخدم: خاصية مستخدم واحدة أو أكثر في Analytics لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة
- البلد أو المنطقة: بلد أو منطقة واحدة أو أكثر لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة
- لغة الجهاز: لغة واحدة أو أكثر وإعدادات محلية تُستخدَم لاختيار المستخدمين الذين قد يتم تضمينهم في التجربة
- الفتح لأول مرة: يمكنك استهداف المستخدمين استنادًا إلى المرة الأولى التي فتحوا فيها تطبيقك
- آخر تفاعل مع التطبيق: يمكنك استهداف المستخدمين استنادًا إلى آخر مرة تفاعلوا فيها مع تطبيقك
اضبط النسبة المئوية للمستخدمين المستهدَفين: اختَر النسبة المئوية لقاعدة مستخدمي تطبيقك التي تطابق المعايير المحدّدة ضمن المستخدمون المستهدَفون والتي تريد تقسيمها بالتساوي بين الإصدار الأساسي وصيغة واحدة أو أكثر في تجربتك. ويمكن أن تكون أي نسبة مئوية بين% 0.01 و%100. تتم إعادة تخصيص النسب المئوية بشكل عشوائي للمستخدمين في كل تجربة، بما في ذلك التجارب المكرّرة.
في قسم الصيغ، اضبط رسالة أساسية داخل التطبيق لإرسالها إلى المجموعة الأساسية باستخدام واجهة تصميم الرسائل التي تستخدمها لحملة عادية للمراسلة داخل التطبيق.
لإضافة صيغة إلى تجربتك، انقر على إضافة صيغة. بشكل تلقائي، تتضمّن التجارب مجموعة أساسية واحدة وصيغة واحدة.
(اختياري) أدخِل اسمًا أكثر وصفًا لكل صيغة.
(اختياري) في أعلى قسم خيارات المنتج، انقر على الزر مقارنة خيارات المنتج لمقارنة خيار واحد أو أكثر من خيارات الرسائل جنبًا إلى جنب مع الرسالة الأساسية.
حدِّد مقياسًا لهدف تجربتك لاستخدامه عند تقييم صيغ التجربة، بالإضافة إلى أي مقاييس إضافية تريد استخدامها من القائمة. وتشمل هذه المقاييس الأهداف المضمّنة (التفاعل وعمليات الشراء والإيرادات والاحتفاظ بالمستخدمين وما إلى ذلك) وأحداث الإحالات الناجحة في "Analytics" وأحداث "Analytics" الأخرى.
اضبط الجدول الزمني للتجربة:
- اضبط تاريخَي البدء والانتهاء للتجربة.
- يمكنك ضبط كيفية ظهور الرسائل داخل التطبيق في جميع الصيغ.
انقر على مراجعة لحفظ تجربتك.
يُسمح لك بإجراء ما يصل إلى 300 تجربة لكل مشروع (بما في ذلك عمليات الطرح)، ويمكن أن تتألف من 24 تجربة وعملية طرح قيد التشغيل، مع اعتبار الباقي تجارب مكتملة.
التحقّق من صحة تجربتك على جهاز اختباري
لكل عملية تثبيت في Firebase، يمكنك استرداد الرمز المميّز للمصادقة على عملية التثبيت المرتبط بها. يمكنك استخدام هذا الرمز المميّز لاختبار صيغ تجربة معيّنة على جهاز اختبار مثبَّت عليه تطبيقك. للتحقّق من صحة تجربتك على جهاز اختباري، اتّبِع الخطوات التالية:
- احصل على رمز مصادقة التثبيت على النحو التالي:
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
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") } }
الويب
import { getInstallations, getToken } from "firebase/installations"; const installations = getInstallations(app); const installationAuthToken = getToken(installations);
- في وحدة تحكّم Firebase، انتقِل إلى DevOps & Engagement > اختبار A/B.
- انقر على مسودة (و/أو قيد التشغيل لتجارب "الإعداد عن بُعد")، ثم مرِّر مؤشر الماوس فوق تجربتك، وانقر على قائمة السياق (more_vert)، ثم انقر على إدارة الأجهزة الاختبارية.
- أدخِل الرمز المميّز لمصادقة التثبيت لجهاز اختباري واختَر صيغة التجربة لإرسالها إلى هذا الجهاز الاختباري.
- شغِّل التطبيق وتأكَّد من تلقّي الصيغة المحدّدة على الجهاز الاختباري.
لمزيد من المعلومات عن عمليات تثبيت Firebase، يُرجى الاطّلاع على إدارة عمليات تثبيت Firebase.
إدارة تجربتك
سواء أنشأت تجربة باستخدام Remote Config أو "منشئ الإشعارات" أو Firebase In-App Messaging، يمكنك بعد ذلك التحقّق من صحة تجربتك وبدؤها ومراقبتها أثناء تشغيلها وزيادة عدد المستخدمين المشمولين في تجربتك قيد التشغيل.
عند انتهاء التجربة، يمكنك تدوين الإعدادات التي استخدمتها الصيغة الفائزة، ثم تطبيق هذه الإعدادات على جميع المستخدمين. أو يمكنك إجراء تجربة أخرى.
بدء تجربة
- في وحدة تحكّم 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 يحتسب جلسات المستخدمين في تطبيقك. لمزيد من المعلومات، اطّلِع على الأحداث المجمّعة تلقائيًا. |