Firebase A/B Testing — یہ کیا ہے، تجربات کی اقسام اور کیسے ترتیب دیں

موبائل ایپلیکیشنز کے سیاق و سباق میں A/B ٹیسٹنگ کیا ہے

A/B ٹیسٹنگ (اسپلٹ ٹیسٹنگ) — ایک موازنہ تجزیہ کا طریقہ ہے جس میں صارفین کے دو گروپ (کنٹرول اور تجرباتی) ایپلیکیشن کے کسی عنصر کے مختلف ورژن دیکھتے ہیں، اور پھر ہر ورژن کے منتخب میٹرک پر اثر کی پیمائش کی جاتی ہے۔ موبائل ڈیویلپمنٹ میں، A/B ٹیسٹ UI تبدیلیوں، آن بورڈنگ، منیٹائزیشن میکینکس، پش نوٹیفکیشنز اور سفارشی الگورتھم کے بارے میں مفروضوں کی تصدیق کے لیے استعمال ہوتے ہیں۔

A/B ٹیسٹنگ اور سادہ مشاہدے کے درمیان بنیادی فرق علت (causality) ہے۔ اگر آرڈر مکمل کرنے والی اسکرین کی تبدیلی کے بعد کنورژن 15% بڑھ جائے، تو A/B ٹیسٹ ثابت کرتا ہے کہ یہ تبدیلی ہی بڑھوتری کا سبب بنی، نہ کہ بیرونی عنصر (چھٹی، اشتہاری مہم، موسمیت)۔ A/B ٹیسٹ کے بغیر علتی تعلق کا دعویٰ نہیں کیا جا سکتا — صرف ارتباط ممکن ہے۔ Optimizely (2025) کے مطابق، جو کمپنیاں باقاعدگی سے A/B ٹیسٹ کرتی ہیں، وہ سالانہ اوسطاً 30% کنورژن میں اضافہ کرتی ہیں۔

معیاری A/B ٹیسٹ کرنے کے لیے چار اجزاء ضروری ہیں: مفروضہ (کیا اور کیوں تبدیل کر رہے ہیں)، میٹرک (اثر کی پیمائش کیسے کرتے ہیں)، نمونے کا سائز (قابل اعتماد نتیجے کے لیے کتنے صارفین درکار ہیں) اور مدت (ڈیٹا کتنی دیر جمع کرنا ہے)۔ Firebase A/B Testing چاروں اجزاء خودکار طریقے سے کور کرتا ہے، لیکن نتائج کی درست تشریح کے لیے ہر ایک کی سمجھ بوجھ ضروری ہے۔

موبائل ایپلیکیشنز کے لیے A/B ٹیسٹ کیوں اہم ہیں

موبائل ایپلیکیشنز میں خاص خصوصیات ہیں جو A/B ٹیسٹنگ کو خاص طور پر قیمتی بناتی ہیں۔ اول، شدید مقابلہ: Google Play پر 30 لاکھ سے زیادہ ایپلیکیشنز ہیں اور ہر UI فیصلہ retention اور کنورژن کو متاثر کرتا ہے۔ دوم، طویل ریلیز سائیکل: ایپ اسٹور کے ذریعے تبدیلی شائع کرنے میں ریویو کے لیے 1 سے 7 دن لگ سکتے ہیں۔ A/B ٹیسٹ ریلیز کے بغیر (Remote Config کے ذریعے) مفروضے کی تصدیق اور اثر کی تصدیق پر ہی تبدیلی لاگو کرنے کی اجازت دیتا ہے۔

سامعین کی تقسیم — A/B ٹیسٹ کا ایک اور فائدہ۔ نئے صارفین کے لیے کام کرنے والی تبدیلی پرانے صارفین کے لیے نقصان دہ ہو سکتی ہے۔ Firebase A/B Testing ایپ ورژن، ملک، زبان، رجسٹریشن کے وقت اور صارف کی خصوصیات کے مطابق سامعین کو تقسیم کرنے کی اجازت دیتا ہے۔ یہ عالمی رول آؤٹ سے پہلے مخصوص ذیلی گروپ پر تبدیلیاں جانچنے کا موقع فراہم کرتا ہے۔

A/B ٹیسٹ اور فیچر فلیگ (Remote Config) کے درمیان فرق

فیچر فلیگ — تمام صارفین یا ان کے فیصد کے لیے کسی فنکشن کو محض آن یا آف کرنا ہے۔ A/B ٹیسٹ — میٹرکس کی پیمائش اور شماریاتی اہمیت کے حساب کے ساتھ ایک ساختی تجربہ ہے۔ فیچر فلیگ اس سوال کا جواب نہیں دیتا کہ «کیا تبدیلی نے میٹرکس کو متاثر کیا؟»، یہ صرف فنکشن کی دستیابی کو کنٹرول کرتا ہے۔ Firebase A/B Testing Remote Config کو قدر کی ترسیل کے طریقہ کار کے طور پر استعمال کرتا ہے، لیکن تجزیہ اور شماریات کی ایک پرت شامل کرتا ہے۔

عملی طور پر: اگر آپ صرف آہستہ آہستہ 20% صارفین کے لیے نئی فیچر رول آؤٹ کرنا چاہتے ہیں اور یقینی بنانا چاہتے ہیں کہ یہ کریش نہیں کر رہی — random_percent شرط کے ساتھ Remote Config استعمال کریں۔ اگر آپ ثابت کرنا چاہتے ہیں کہ نئی فیچر نے کنورژن ریٹ 10% بڑھایا ہے — Firebase A/B Testing استعمال کریں، جو خود بخود میٹرکس کی پیمائش کرے گا اور p-value دکھائے گا۔

Firebase A/B Testing کیسے کام کرتا ہے

Firebase A/B Testing — Remote Config اور Cloud Messaging کے اوپر ایک ایڈ آن ہے، جو تجربات بنانے اور ان کی نگرانی کے لیے ایک متحد انٹرفیس فراہم کرتا ہے۔ ساختی طور پر، سروس تین اجزاء پر مشتمل ہے: مینجمنٹ کنسول (Firebase کنسول میں A/B Testing سیکشن)، تقسیم کا انجن (مقررہ فیصد کی بنیاد پر صارفین کو گروپوں میں تفویض کرتا ہے) اور شماریاتی انجن (گروپوں کے درمیان میٹرک کے فرق کا تجزیہ کرتا ہے)۔

جب تجربہ بنانے والا تبدیلیاں شائع کرتا ہے، Firebase Remote Config ٹیمپلیٹ کا نیا ورژن محفوظ کرتا ہے، لیکن مختلف صارف گروپوں کے لیے مختلف پیرامیٹر ویلیوز لاگو کرتا ہے۔ کلائنٹ ایپلیکیشن، fetchAndActivate انجام دے کر، اپنے گروپ کے مطابق قدر حاصل کرتی ہے۔ Firebase Analytics تمام گروپوں سے واقعات جمع کرتی ہے اور انہیں شماریاتی انجن کو بھیجتی ہے، جو روزانہ p-value اور اعتماد کے وقفے کے ساتھ رپورٹ اپ ڈیٹ کرتا ہے۔

شماریاتی ماڈل Firebase A/B Testing میٹرکس کی اوسط قدروں کا موازنہ کرنے کے لیے t-ٹیسٹ کے ساتھ Frequentist طریقہ استعمال کرتا ہے۔ بائنری میٹرکس (کنورژن، retention) کے لیے — دو نمونوں کا z-ٹیسٹ تناسب۔ اہمیت کی سطح (alpha) ڈیفالٹ طور پر — 0.05 ہے۔ اگر متعدد بنیادی میٹرکس منتخب کی گئی ہوں تو Firebase Bonferroni correction کے ذریعے متعدد موازنوں کو درست کرتا ہے۔ اہم: شماریاتی اہمیت عملی اہمیت کی ضمانت نہیں دیتی — p-value < 0.05 ہونے پر بھی مطلق اضافہ معاشی طور پر غیر معقول ہو سکتا ہے۔

صارفین کی گروپوں میں تقسیم

Firebase A/B Testing صارف کی شناخت (Analytics App Instance ID) کی بنیاد پر تعین کنندہ تقسیم (deterministic distribution) استعمال کرتا ہے۔ اس کا مطلب ہے کہ وہی صارف ہمیشہ اسی گروپ میں آئے گا تجربے کے دوبارہ چلانے پر، بشرطیکہ تجربے کی ترتیب تبدیل نہ ہوئی ہو۔ تعین کنندگی صارف کے تجربے کے تسلسل کے لیے اہم ہے: صارف کو ایپلیکیشن کے ہر بار چلانے پر انٹرفیس کے مختلف ورژن نہیں دیکھنے چاہئیں۔

فیصد کی تقسیم تجربہ بناتے وقت مقرر کی جاتی ہے: مثال کے طور پر، 50% کنٹرول گروپ، 50% تجرباتی گروپ۔ Firebase بے ترتیب seed کو مدنظر رکھتے ہوئے صارفین کو یکساں طور پر تقسیم کرتا ہے، سائز کے لحاظ سے متوازن گروپوں کو یقینی بناتا ہے۔ متعدد تجرباتی گروپ (A/B/n) استعمال کرتے وقت، فیصد ان کے درمیان برابر تقسیم ہوتا ہے۔ اہم: تجربہ شروع ہونے کے بعد تقسیم کا فیصد تبدیل نہیں کیا جا سکتا — فیصد تبدیل کرنے کے لیے تجربہ روک کر نیا بنانا ہوگا۔

Remote Config اور Cloud Messaging کے ساتھ انضمام

Remote Config تجربے میں تبدیل ہونے والے پیرامیٹر کی قدروں کا ذریعہ ہے۔ A/B ٹیسٹ بناتے وقت، آپ ایک Remote Config پیرامیٹر منتخب کرتے ہیں اور ہر گروپ کے لیے اس کی قدر مقرر کرتے ہیں۔ Firebase خود بخود تجرباتی قدروں کے ساتھ Remote Config ٹیمپلیٹ کی ایک عارضی شاخ بناتا ہے۔ تجربہ کسی گروپ کے حق میں روکنے کے بعد، اس کی قدر Firebase کنسول کے ذریعے پروڈکشن ویلیو کے طور پر لاگو کی جا سکتی ہے۔

Cloud Messaging پش نوٹیفکیشن بھیجنے کے لیے استعمال ہوتا ہے، جو تجربے کا حصہ ہوتے ہیں۔ Firebase A/B Testing مختلف متن، تصاویر اور پش نوٹیفکیشن کے وقت کے ساتھ تجربات بنانے کی حمایت کرتا ہے۔ سروس خود بخود گروپوں کے مطابق نوٹیفکیشن تقسیم کرتی ہے اور میٹرکس پر اثر کی پیمائش کرتی ہے: open rate، کلک کے بعد کنورژن، uninstall rate۔ یہ دستی A/B نیوزلیٹر ٹیسٹنگ کے بغیر صارفین کے ساتھ مواصلات کے بہترین میکینکس تلاش کرنے کی اجازت دیتا ہے۔

تجربہ بنانا اور ترتیب دینا

A/B ٹیسٹ بنانا Firebase Console میں A/B Testing سیکشن میں «Create experiment» بٹن کے ذریعے کیا جاتا ہے۔ بنانے کا وزرڈ کئی مراحل پر مشتمل ہوتا ہے: تجربے کی قسم کا انتخاب (Remote Config یا Notification)، کنٹرول اور تجرباتی گروپ کے لیے پیرامیٹر اور اس کی قدریں بتانا، ہدف سامعین کا تعین (خصوصیات کے مطابق) اور پیمائش کے لیے میٹرکس کا انتخاب۔ ترتیب مکمل ہونے کے بعد، تجربہ شائع ہوتا ہے اور ڈیٹا جمع کرنا شروع کرتا ہے۔

تجربے کی قسم کا انتخاب: Remote Config experiment — ایپلیکیشن کے کسی بھی پیرامیٹر (UI، مواد، منطق) کو تبدیل کرنے کے لیے؛ Notification experiment — مختلف پش نوٹیفکیشن کی افادیت کا موازنہ کرنے کے لیے۔ Remote Config تجربات کے لیے Remote Config میں پہلے سے بنائے گئے پیرامیٹر کی ضرورت ہوتی ہے۔ Notification تجربات آزادانہ طور پر بنائے جاتے ہیں — Firebase خود بخود کلائنٹ پر کوڈ لکھے بغیر ہر گروپ کے لیے پش نوٹیفکیشن تیار اور بھیجے گا۔

سامعین کا تعین — ایک انتہائی اہم مرحلہ۔ ڈیفالٹ طور پر، تجربہ ایپلیکیشن کے تمام صارفین پر چلتا ہے۔ سامعین کو محدود کرنے کے لیے فلٹر استعمال کریں: ایپ ورژن، ملک، زبان، OS ورژن، Analytics صارف کی خصوصیات۔ مثال کے طور پر، آن بورڈنگ کی تبدیلی صرف نئے صارفین (7 دن کے اندر first_open) پر جانچنا معنی خیز ہے۔ غیر متعلقہ سامعین پر جانچ «دھندلا» نتیجہ دیتی ہے، جو تبدیلی کے حقیقی اثر کو چھپا دیتی ہے۔

تجربے کی مدت اور نمونے کا سائز

کم از کم مدت Firebase A/B Testing میں تجربے کی — 3 دن (مکمل ویک اینڈ سمیت، کیونکہ ہفتے کے دنوں اور ویک اینڈ پر صارفین کا رویہ مختلف ہوتا ہے)۔ Firebase ٹریفک اور مقررہ کم از کم قابل دریافت اثر (Minimum Detectable Effect, MDE) کی بنیاد پر تجویز کردہ مدت خود بخود حساب کرتا ہے۔ ڈیفالٹ MDE — میٹرک میں رشتہ دار تبدیلی کا 5%۔ اگر موجودہ ٹریفک 4 ہفتوں میں 5% اثر دریافت کرنے کے لیے ناکافی ہو، Firebase اس بارے میں خبردار کرے گا۔

نمونے کا سائز ان چیزوں کی بنیاد پر حساب کیا جاتا ہے: baseline میٹرک (موجودہ قدر)، MDE، اہمیت کی سطح (alpha = 0.05) اور شماریاتی طاقت (power = 0.8)۔ 50,000 MAU اور baseline conversion rate 10% والی عام ایپلیکیشن کے لیے، 5% رشتہ دار تبدیلی دریافت کرنے کے لیے ہر گروپ میں تقریباً 30,000 صارفین (کل 60,000) درکار ہوں گے۔ اگر نمونے کا سائز ناکافی ہو، نتیجہ شماریاتی اہمیت تک نہیں پہنچ سکتا، چاہے تبدیلی مؤثر ہی کیوں نہ ہو (دوسری قسم کی غلطی)۔

متعدد متغیرات کے ساتھ کام (A/B/n)

کثیر متغیر تجربات (A/B/n) ایک پیرامیٹر کے 3 یا زیادہ ورژن کا موازنہ کرنے کی اجازت دیتے ہیں۔ Firebase ایک تجربے میں 10 تک متغیرات کو سپورٹ کرتا ہے۔ جتنے زیادہ متغیرات، شماریاتی اہمیت حاصل کرنے کے لیے اتنے ہی زیادہ صارفین درکار ہوتے ہیں۔ قاعدہ: ہر اضافی متغیر کے لیے، نمونے کا سائز دو متغیر والے ٹیسٹ کے مقابلے میں 20–30% بڑھ جاتا ہے۔ اگر ٹریفک محدود ہو، ایک کثیر متغیر ٹیسٹ کے بجائے ترتیب وار دو متغیر والے ٹیسٹ ترجیح دی جاتی ہے۔

بونفیرونی تصحیح — Firebase متعدد متغیرات یا میٹرکس کی صورت میں متعدد موازنوں کے لیے تصحیح خود بخود لاگو کرتا ہے۔ خلاصہ: اگر آپ alpha = 0.05 کے ساتھ 5 مفروضے جانچ رہے ہیں، کم از کم ایک جھوٹے مثبت نتیجے کا امکان 1 — (0.95)^5 ≈ 22.6% ہے۔ Bonferroni correction alpha کو موازنوں کی تعداد سے تقسیم کرتا ہے: 5 مفروضوں کے لیے alpha = 0.01۔ یہ اثر دریافت کرنے کو زیادہ قدامت پسند بناتا ہے، لیکن false positive کا خطرہ کم کرتا ہے۔

میٹرکس، نتائج کا تجزیہ اور فیصلہ سازی

میٹرکس کا انتخاب — سب سے اہم مرحلہ، جو تجربے کے معیار کا تعین کرتا ہے۔ Firebase A/B Testing میٹرکس کی کئی اقسام پیش کرتا ہے: مصروفیت (یومیہ فعال صارفین، سیشن کا دورانیہ، فی سیشن اسکرینیں)، منیٹائزیشن (آمدنی، خریداریاں، سبسکرپشنز)، retention (دن 1، دن 7، دن 28)، کنورژن (منتخب واقعہ کے مطابق conversion rate)۔ Firebase Analytics کے کسی بھی واقعے کی بنیاد پر حسب ضرورت میٹرکس بھی دستیاب ہیں۔

بنیادی میٹرک (primary metric) — واحد میٹرک جس کی بنیاد پر تجربے کی کامیابی کا فیصلہ کیا جاتا ہے۔ بنیادی میٹرک کا انتخاب مفروضے کی بنیاد پر تجربہ شروع کرنے سے پہلے کرنا چاہیے۔ اگر مفروضہ ہے «نیا آن بورڈنگ رجسٹریشن پر conversion rate بڑھائے گا»، تو بنیادی میٹرک sign_up_completed واقعے کا conversion rate ہے۔ ثانوی میٹرکس (secondary metrics) — ضمنی اثرات کے تجزیے کے لیے اضافی اشارے: کیا retention کم ہوا، کیا آمدنی گری۔

نتائج کی تشریح: Firebase ہر گروپ کے لیے میٹرک کی قدروں، کنٹرول گروپ سے فیصد فرق، p-value اور 95% اعتماد کے وقفے کے ساتھ ایک جدول دکھاتا ہے۔ اگر p-value < 0.05 اور اعتماد کا وقفہ 0 شامل نہیں کرتا — فرق شماریاتی طور پر اہم ہے۔ اگر p-value > 0.05 — نتیجہ غیر حتمی (inconclusive) ہے، اور تجربے کو بڑھانے یا غیر متعین کے طور پر روکنے کی ضرورت ہے۔

نتائج کی بنیاد پر فیصلہ سازی

Firebase A/B Testing تجربہ ختم ہونے کے بعد تین عمل کے اختیارات پیش کرتا ہے: جیتنے والے متغیر کو تمام صارفین پر لاگو کریں، تجربہ جاری رکھیں (اگر ڈیٹا ناکافی ہو) یا لاگو کیے بغیر تجربہ روکیں (اگر تمام متغیرات کنٹرول سے بدتر ہوں یا نتیجہ غیر متعین ہو)۔ جیتنے والے کا اطلاق خود بخود Remote Config ٹیمپلیٹ کو جیتنے والے متغیر کی پروڈکشن ویلیو سے اپ ڈیٹ کرتا ہے۔

توجہ: کبھی کبھی شماریاتی طور پر اہم نتیجہ کا عملی مطلب نہیں ہوتا۔ مثال کے طور پر، ٹیسٹ نے conversion rate میں 0.5% اضافہ دکھایا (p = 0.03)، لیکن UI کے نئے ورژن کے لیے 2 ہفتے کی ڈیویلپمنٹ درکار ہے۔ لاگت اور فائدے کا تناسب غیر معقول ہو سکتا ہے۔ صرف شماریاتی اہمیت کی بنیاد پر نہیں، بلکہ business impact کی بنیاد پر فیصلہ کریں۔ Firebase صرف p-value ہی نہیں، بلکہ میٹرک کی مطلق تبدیلی بھی دکھاتا ہے، جو عملی اہمیت کا جائزہ لینے میں مدد کرتا ہے۔

اعلیٰ میٹرکس: retention اور LTV

Retention — موبائل ایپلیکیشنز کے لیے سب سے اہم میٹرکس میں سے ایک، کیونکہ یہ براہ راست صارف کی طویل مدتی قیمت (LTV) سے متعلق ہے۔ Firebase A/B Testing خود بخود ہر گروپ کے لیے دن 1، دن 7 اور دن 28 retention کا حساب لگاتا ہے۔ تاہم، قابل اعتماد retention پیمائش کے لیے وقت درکار ہے: دن 7 retention کا اندازہ تجربہ شروع ہونے کے 7 دن بعد، دن 28 retention — 28 دن بعد لگایا جا سکتا ہے۔ retention ڈیٹا جمع کرنے کے لیے درکار وقت کو مدنظر رکھتے ہوئے تجربے کی مدت کی منصوبہ بندی کریں۔

LTV (Lifetime Value) — ایک زیادہ پیچیدہ میٹرک، جس کے لیے Firebase کو Google Analytics for Firebase کے ساتھ اور ضرورت پڑنے پر انتساب پلیٹ فارم (Adjust, AppsFlyer) کے ساتھ انضمام درکار ہے۔ Firebase A/B Testing LTV کو میٹرک کے طور پر استعمال کرنے کی اجازت دیتا ہے، لیکن اس کے حساب کے لیے خریداری اور صارفین کو راغب کرنے کے اخراجات کے ڈیٹا کی درآمد ترتیب دینی ہوگی۔ انتساب کے بغیر LTV غلط ہو سکتا ہے، کیونکہ Firebase اشتہاری ذرائع سے انسٹالیشن کی قیمت نہیں دیکھ سکتا۔

Remote Config کے ذریعے A/B ٹیسٹ کی ترتیب

A/B ٹیسٹ کرنے کے لیے Firebase A/B Testing کے ذریعے کلائنٹ پر خصوصی کوڈ کی ضرورت نہیں — پورا تجربہ Firebase Console میں ترتیب دیا جاتا ہے۔ تاہم، کلائنٹ کوڈ کو Remote Config پیرامیٹرز کو صحیح طریقے سے استعمال کرنا چاہیے تاکہ تجربے کے ذریعے مقرر کردہ قدریں درست طریقے سے لاگو ہوں۔ مثال پر غور کریں: سبسکرپشن کی نئی قیمت کا A/B ٹیسٹ، جہاں کنٹرول گروپ پرانی قیمت ($9.99) دیکھتا ہے اور تجرباتی گروپ نئی قیمت ($7.99) دیکھتا ہے۔

Firebase Console میں ہم ڈیفالٹ قدر «9.99» کے ساتھ ایک Remote Config پیرامیٹر subscription_price بناتے ہیں۔ پھر ایک A/B ٹیسٹ بناتے ہیں، جہاں 50% صارفین کے لیے جیتنے والے متغیر کے طور پر قدر «7.99» بتاتے ہیں۔ Firebase خود بخود ہر صارف کو ایک گروپ تفویض کرتا ہے اور Remote Config کے ذریعے متعلقہ قدر پہنچاتا ہے۔ کلائنٹ کوڈ قیمت حاصل کرنے کے لیے معیاری getString استعمال کرتا ہے۔

A/B ٹیسٹ لاگو کرنے کے لیے کلائنٹ کوڈ

کلائنٹ کوڈ تجربے کے وجود سے بے خبر ہے — یہ صرف Remote Config سے پیرامیٹر کی قدر حاصل کرتا ہے۔ Firebase SDK سرور کی طرف گروپ بندی کو ہینڈل کرتا ہے۔ یہ Firebase A/B Testing کا سب سے بڑا فائدہ ہے: ڈیویلپر کو گروپوں کے مطابق تقسیم کے لیے مشروط منطق لکھنے کی ضرورت نہیں۔ واحد ضرورت — ایپلیکیشن کو تازہ ترین قدریں حاصل کرنے کے لیے باقاعدگی سے fetchAndActivate کال کرنا چاہیے۔

class SubscriptionFragment : Fragment() {

    private fun loadPrice() {
        val remoteConfig = Firebase.remoteConfig
        val priceStr = remoteConfig
            .getString("subscription_price")
        val price = priceStr.toDoubleOrNull() ?: 9.99
        priceView.text = "$$price/month"
    }

    override fun onViewCreated(...) {
        super.onViewCreated(...)
        loadPrice()
    }
}

مثال میں loadPrice Remote Config کے ذریعے subscription_price پیرامیٹر کی قدر حاصل کرتا ہے۔ Firebase SDK خود بخود ایک فعال A/B ٹیسٹ کے فریم ورک میں صارف کے گروپ کے مطابق قدر لوٹاتا ہے۔ اگر تجربہ فعال نہیں ہے یا صارف گروپ میں نہیں آیا — ڈیفالٹ قدر لوٹائی جاتی ہے۔ یہ کوڈ کو تجربات کی موجودگی یا غیر موجودگی سے مکمل طور پر آزاد بناتا ہے۔

میٹرکس کے لیے تجزیاتی واقعات کی لاگنگ

Firebase A/B Testing کے درست کام کے لیے ضروری ہے کہ ایپلیکیشن ان واقعات کو لاگ کرے جو تجربے کے میٹرکس کے طور پر منتخب کیے گئے ہیں۔ Firebase Analytics SDK خود بخود معیاری واقعات (first_open, session_start, in_app_purchase وغیرہ) جمع کرتا ہے، لیکن حسب ضرورت میٹرکس کے لیے لاگنگ شامل کرنی ہوگی۔ نیچے دی گئی مثال میں، صارف سبسکرپشن لینے کی کوشش کرتا ہے تو subscription_started واقعہ لاگ کیا جاتا ہے۔

private fun onSubscribeClick() {
    // A/B ٹیسٹ کے لیے ایونٹ لاگ کر رہے ہیں
    val bundle = Bundle().apply {
        putString(
            FirebaseAnalytics.Param.PRICE,
            remoteConfig.getString("subscription_price")
        )
    }
    FirebaseAnalytics.getInstance(requireContext())
        .logEvent("subscription_started", bundle)

    // ادائیگی کا بہاؤ شروع ہو رہا ہے
    startBillingFlow()
}

اہم: subscription_started واقعہ Firebase Analytics میں ایک حسب ضرورت واقعہ کے طور پر رجسٹرڈ ہونا چاہیے (رپورٹس کے لیے) یا Firebase A/B Testing کے ذریعے استعمال ہونے والا معیاری واقعہ ہونا چاہیے۔ Firebase خود بخود Analytics App Instance ID کے ذریعے واقعہ کو تجربے کے گروپ سے جوڑتا ہے۔ کسی اضافی نشان دہی کی ضرورت نہیں — تمام جادو Firebase سرور کی طرف ہوتا ہے۔

A/B ٹیسٹ کرتے وقت عام غلطیاں

پیک اثر کی غلطی — منصوبہ بند مدت کو مدنظر رکھے بغیر شماریاتی اہمیت کے پہلے ظہور پر تجربہ روک دینا۔ اگر روزانہ p-value چیک کیا جائے اور p < 0.05 ہوتے ہی روک دیا جائے، جھوٹے مثبت نتیجے کا امکان 5% سے 30–40% تک بڑھ جاتا ہے۔ Firebase A/B Testing متعین تجربہ مدت تجویز کرتا ہے۔ حساب شدہ مدت ختم ہونے سے پہلے نتائج نہ دیکھیں۔

غیر مدنظر بیرونی عوامل — موسمیت، اشتہاری مہمات، OS اپ ڈیٹس، حریفوں کا ظہور۔ اگر A/B ٹیسٹ کے دوران آپ نے کوئی اشتہاری مہم شروع کی جس نے ٹریفک کی ساخت بدل دی، تو ٹیسٹ کا نتیجہ مسخ ہو سکتا ہے۔ سفارش کی جاتی ہے کہ بڑی مارکیٹنگ سرگرمیوں کے ساتھ ایک ساتھ A/B ٹیسٹ نہ کریں۔ اگر یہ ناگزیر ہو تو یقینی بنائیں کہ اشتہار سے ٹریفک گروپوں کے درمیان یکساں طور پر تقسیم ہو۔

طبقہ اثر (Simpson's Paradox) — ایسی صورت حال جہاں مجموعی نتیجہ اثر کی عدم موجودگی دکھاتا ہے، لیکن انفرادی طبقات کے اندر اثر موجود ہے اور اس کے برعکس ہے۔ مثال کے طور پر، ٹیسٹ نے دکھایا کہ نئے آرڈر فارم نے اوسطاً کنورژن تبدیل نہیں کیا، لیکن iOS اور Android میں تقسیم کرنے پر پتہ چلا: iOS پر کنورژن 20% بڑھا، اور Android پر 15% گرا۔ ہمیشہ اہم طبقات (پلیٹ فارم، ملک، ایپ ورژن) کے مطابق نتائج چیک کریں۔

متعدد میٹرکس کا مسئلہ

Multiple comparison problem اس وقت پیدا ہوتا ہے جب تجربے میں بہت سے میٹرکس استعمال کیے جائیں۔ اگر آپ alpha = 0.05 کے ساتھ 20 میٹرکس جانچ رہے ہیں، کم از کم ایک جھوٹا اہم فرق (false positive) ملنے کا امکان 1 — (0.95)^20 ≈ 64% ہے۔ Firebase کئی بنیادی میٹرکس کے لیے Bonferroni correction استعمال کرتا ہے، لیکن ثانوی میٹرکس کے لیے نہیں۔ نتیجہ: تجربہ شروع کرنے سے پہلے ایک بنیادی میٹرک منتخب کریں اور فیصلہ کرتے وقت ثانوی میٹرکس کے p-value پر توجہ نہ دیں۔

نیا پن کا اثر (Novelty effect) — صارفین کسی نئی تبدیلی پر مختلف ردعمل ظاہر کر سکتے ہیں صرف اس لیے کہ یہ نئی ہے، نہ کہ اس لیے کہ یہ بہتر ہے۔ تجربے کے پہلے دن جھوٹی بڑھوتری دکھا سکتے ہیں (صارفین تجسس سے نئے بٹن پر کلک کرتے ہیں)، جو وقت کے ساتھ کم ہو جاتی ہے۔ 3 دن کی کم از کم مدت جزوی طور پر اس مسئلے کو حل کرتی ہے، لیکن UI تبدیلیوں کے لیے 7–14 دن کی مدت تجویز کی جاتی ہے تاکہ نیا پن کا اثر مستحکم ہو سکے۔

تجربات کے درمیان مداخلت

نیٹ ورک اثر (network effect) — مسئلہ جب ایک گروپ کے صارفین کا رویہ دوسرے گروپ کے صارفین کو متاثر کرتا ہے۔ مثال کے طور پر، نیوز فیڈ الگورتھم تبدیلی کا A/B ٹیسٹ: اگر تجرباتی گروپ بہتر سفارشات حاصل کرتا ہے، تو وہ زیادہ مواد تخلیق کرتے ہیں جو کنٹرول گروپ کے صارفین بھی دیکھتے ہیں، نتائج کو مسخ کرتے ہوئے۔ ایسے معاملات میں، سماجی گراف کے مطابق تنہائی استعمال کریں یا ملک/علاقہ کی سطح پر ٹیسٹ کریں۔

بیک وقت تجربات ایک ہی Remote Config پیرامیٹر پر — مداخلت کا ایک اور ذریعہ۔ Firebase A/B Testing پہلے سے استعمال شدہ پیرامیٹر پر دوسرا تجربہ شروع کرنے کی اجازت نہیں دیتا، لیکن اگر تجربات مختلف پیرامیٹرز کو متاثر کرتے ہیں لیکن ایک ہی میٹرک کو متاثر کرتے ہیں، تو کراس اثر ممکن ہے۔ سفارش کی جاتی ہے کہ ایک ساتھ 2–3 سے زیادہ فعال A/B ٹیسٹ نہ کیے جائیں اور یہ یقینی بنایا جائے کہ وہ ایک ہی صارف کے منظرناموں کو متاثر نہ کریں۔