Firebase A/B Testing — چیست، انواع آزمایش‌ها و نحوه تنظیم

آزمایش A/B در زمینه اپلیکیشن‌های موبایل چیست

آزمایش A/B (تقسیم‌بندی) — روشی از تحلیل مقایسه‌ای است که در آن دو گروه از کاربران (کنترل و آزمایشی) نسخه‌های متفاوتی از یک عنصر اپلیکیشن را مشاهده می‌کنند، سپس تأثیر هر نسخه بر معیار انتخابی اندازه‌گیری می‌شود. در توسعه اپلیکیشن‌های موبایل، آزمایش‌های A/B برای بررسی فرضیه‌ها درباره تغییرات UI، آموزش onboarding، مکانیک‌های درآمدزایی، اعلان‌های push و الگوریتم‌های توصیه استفاده می‌شوند.

تفاوت کلیدی آزمایش 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 بیش از 3 میلیون اپلیکیشن وجود دارد و هر تصمیم UI بر retention و نرخ تبدیل تأثیر می‌گذارد. ثانیاً، چرخه انتشار طولانی: انتشار تغییر از طریق فروشگاه اپلیکیشن ممکن است 1 تا 7 روز برای بررسی زمان ببرد. آزمایش A/B امکان بررسی فرضیه بدون انتشار (از طریق Remote Config) و اعمال تغییر تنها پس از تأیید اثربخشی را فراهم می‌کند.

بخش‌بندی مخاطب — یکی دیگر از مزایای آزمایش‌های A/B. تغییری که برای کاربران جدید کار می‌کند، ممکن است برای کاربران قدیمی مضر باشد. Firebase A/B Testing امکان بخش‌بندی مخاطبان را بر اساس نسخه اپلیکیشن، کشور، زبان، مدت زمان ثبت‌نام و ویژگی‌های کاربر فراهم می‌کند. این امکان آزمایش تغییرات روی یک زیرگروه خاص را قبل از انتشار جهانی می‌دهد.

تفاوت بین آزمایش A/B و feature flag (Remote Config)

Feature flag (پرچم ویژگی) — فعال یا غیرفعال کردن ساده یک ویژگی برای همه کاربران یا درصدی از آنهاست. آزمایش A/B — یک آزمایش ساختاریافته با اندازه‌گیری معیارها و محاسبه معنی‌داری آماری است. Feature flag به این سؤال پاسخ نمی‌دهد که «آیا تغییر بر معیارها تأثیر گذاشت؟»، فقط بر دسترسی به ویژگی مدیریت می‌کند. Firebase A/B Testing از Remote Config به عنوان مکانیزم تحویل مقادیر استفاده می‌کند، اما لایه تحلیل و آمار را اضافه می‌کند.

در عمل: اگر فقط می‌خواهید به تدریج یک ویژگی جدید را برای 20% کاربران عرضه کنید و مطمئن شوید که خراب نمی‌شود — از Remote Config با شرط random_percent استفاده کنید. اگر می‌خواهید ثابت کنید که ویژگی جدید نرخ تبدیل را 10% افزایش داده است — از Firebase A/B Testing استفاده کنید که به طور خودکار معیارها را اندازه‌گیری کرده و p-value را نشان می‌دهد.

Firebase A/B Testing چگونه کار می‌کند

Firebase A/B Testing — لایه‌ای بالای Remote Config و Cloud Messaging است که یک رابط یکپارچه برای ایجاد و نظارت بر آزمایش‌ها فراهم می‌کند. از نظر معماری، این سرویس از سه مؤلفه تشکیل شده است: کنسول مدیریت (بخش A/B Testing در Firebase Console)، مکانیزم توزیع (کاربران را بر اساس درصد تعیین‌شده به گروه‌ها اختصاص می‌دهد) و موتور آماری (تفاوت معیارها بین گروه‌ها را تحلیل می‌کند).

هنگامی که سازنده آزمایش تغییرات را منتشر می‌کند، Firebase نسخه جدید قالب Remote Config را ذخیره می‌کند، اما مقادیر متفاوتی از پارامترها را برای گروه‌های مختلف کاربران اعمال می‌کند. اپلیکیشن کلاینت با اجرای fetchAndActivate، مقدار متناسب با گروه خود را دریافت می‌کند. Firebase Analytics رویدادها را از همه گروه‌ها جمع‌آوری کرده و به موتور آماری منتقل می‌کند که روزانه گزارش را با p-value و فواصل اطمینان به‌روز می‌کند.

مدل آماری Firebase A/B Testing از رویکرد frequentist با آزمون t برای مقایسه میانگین مقادیر معیارها استفاده می‌کند. برای معیارهای دودویی (نرخ تبدیل، retention) — آزمون z دو نمونه‌ای برای نسبت‌ها. سطح معنی‌داری (alpha) به طور پیش‌فرض — 0.05. Firebase در صورت انتخاب چندین معیار اولیه، مقایسه‌های چندگانه را با تصحیح Bonferroni اصلاح می‌کند. مهم: معنی‌داری آماری معنی‌داری عملی را تضمین نمی‌کند — حتی با p-value < 0.05، افزایش مطلق ممکن است از نظر اقتصادی به‌صرفه نباشد.

توزیع کاربران به گروه‌ها

Firebase A/B Testing از توزیع قطعی بر اساس شناسه کاربر (Analytics App Instance ID) استفاده می‌کند. این بدان معناست که یک کاربر همیشه در اجراهای مکرر آزمایش، در همان گروه قرار می‌گیرد، به شرطی که پیکربندی آزمایش تغییر نکرده باشد. قطعیت برای ثبات تجربه کاربر مهم است: کاربر نباید در هر بار باز کردن اپلیکیشن، نسخه‌های مختلفی از رابط را ببیند.

توزیع درصدی هنگام ایجاد آزمایش تعیین می‌شود: به عنوان مثال، 50% گروه کنترل، 50% گروه آزمایشی. Firebase کاربران را به طور یکنواخت با در نظر گرفتن seed تصادفی توزیع می‌کند و گروه‌های متوازن از نظر اندازه را تضمین می‌کند. هنگام استفاده از چندین گروه آزمایشی (A/B/n)، درصد به طور مساوی بین آنها تقسیم می‌شود. مهم: درصد توزیع پس از شروع آزمایش قابل تغییر نیست — برای تغییر درصد باید آزمایش را متوقف کرده و یک آزمایش جدید ایجاد کنید.

یکپارچگی با Remote Config و Cloud Messaging

Remote Config به عنوان منبع مقادیر پارامترهای تغییر یافته در آزمایش عمل می‌کند. هنگام ایجاد آزمایش A/B، پارامتر Remote Config را انتخاب کرده و مقدار آن را برای هر گروه تعیین می‌کنید. Firebase به طور خودکار یک شاخه موقت از قالب Remote Config با مقادیر آزمایشی ایجاد می‌کند. پس از توقف آزمایش به نفع یکی از گروه‌ها، مقدار آن را می‌توان از طریق کنسول Firebase به عنوان مقدار تولیدی اعمال کرد.

Cloud Messaging برای ارسال اعلان‌های push که بخشی از آزمایش هستند استفاده می‌شود. Firebase A/B Testing از ایجاد آزمایش‌ها با متن‌ها، تصاویر و زمان‌بندی‌های مختلف اعلان‌های push پشتیبانی می‌کند. این سرویس به طور خودکار اعلان‌ها را بین گروه‌ها توزیع کرده و تأثیر بر معیارها را اندازه‌گیری می‌کند: نرخ باز شدن، نرخ تبدیل پس از کلیک، نرخ حذف نصب. این امکان یافتن مکانیک‌های بهینه ارتباط با کاربران را بدون آزمایش دستی A/B ارسال‌ها فراهم می‌کند.

ایجاد و تنظیم آزمایش

ایجاد آزمایش A/B در Firebase Console در بخش A/B Testing از طریق دکمه «Create experiment» انجام می‌شود. جادوگر ایجاد شامل چند مرحله است: انتخاب نوع آزمایش (Remote Config یا Notification)، تعیین پارامتر و مقادیر آن برای گروه‌های کنترل و آزمایش، تعیین مخاطب هدف (بر اساس ویژگی‌ها) و انتخاب معیارهای اندازه‌گیری. پس از اتمام تنظیمات، آزمایش منتشر می‌شود و جمع‌آوری داده‌ها آغاز می‌گردد.

انتخاب نوع آزمایش: Remote Config experiment — برای تغییر هر پارامتر اپلیکیشن (UI، محتوا، منطق)؛ Notification experiment — برای مقایسه اثربخشی اعلان‌های push مختلف. آزمایش‌های Remote Config نیاز به یک پارامتر از پیش ایجاد شده در Remote Config دارند. آزمایش‌های Notification به طور مستقل ایجاد می‌شوند — Firebase به طور خودکار اعلان‌های push را برای هر گروه بدون نوشتن کد در سمت کلاینت آماده و ارسال می‌کند.

تعیین مخاطب — مرحله‌ای بسیار مهم. به طور پیش‌فرض، آزمایش روی همه کاربران اپلیکیشن اجرا می‌شود. برای محدود کردن مخاطب از فیلترها استفاده کنید: نسخه اپلیکیشن، کشور، زبان، نسخه سیستم عامل، ویژگی‌های کاربر Analytics. به عنوان مثال، تغییر onboarding منطقی است فقط روی کاربران جدید (first_open در 7 روز) آزمایش شود. آزمایش روی مخاطب نامرتبط نتیجه‌ای «تار» می‌دهد که اثر واقعی تغییر را پنهان می‌کند.

مدت زمان آزمایش و حجم نمونه

حداقل مدت زمان آزمایش در Firebase A/B Testing — 3 روز (با احتساب آخر هفته کامل، زیرا رفتار کاربران در روزهای هفته و آخر هفته متفاوت است). Firebase به طور خودکار مدت زمان توصیه‌شده را بر اساس ترافیک و حداقل اثر قابل تشخیص (Minimum Detectable Effect, MDE) محاسبه می‌کند. MDE به طور پیش‌فرض — 5% تغییر نسبی معیار. اگر ترافیک فعلی برای تشخیص اثر 5% در 4 هفته کافی نباشد، Firebase در این مورد هشدار می‌دهد.

حجم نمونه بر اساس: معیار پایه (مقدار فعلی)، MDE، سطح معنی‌داری (alpha = 0.05) و توان آماری (power = 0.8) محاسبه می‌شود. برای یک اپلیکیشن معمولی با 50,000 MAU و نرخ تبدیل پایه 10%، تشخیص تغییر نسبی 5% به حدود 30,000 کاربر در هر گروه (در مجموع 60,000) نیاز دارد. اگر حجم نمونه کافی نباشد، ممکن است نتیجه به معنی‌داری آماری نرسد، حتی اگر تغییر مؤثر بوده باشد (خطای نوع دوم).

کار با چندین نوع (A/B/n)

آزمایش‌های چند متغیره (A/B/n) امکان مقایسه 3 و بیشتر نسخه از یک پارامتر را فراهم می‌کنند. Firebase تا 10 نوع را در یک آزمایش پشتیبانی می‌کند. هر چه تعداد انواع بیشتر باشد، کاربران بیشتری برای رسیدن به معنی‌داری آماری نیاز است. قانون: برای هر نوع اضافی، حجم نمونه 20–30% نسبت به آزمایش دو نوعی افزایش می‌یابد. اگر ترافیک محدود است، آزمایش‌های دو نوعی متوالی ترجیح داده می‌شوند تا یک آزمایش چند نوعی.

تصحیح بونفرونی — Firebase به طور خودکار برای مقایسه‌های چندگانه با چندین نوع یا معیار، تصحیح را اعمال می‌کند. اصل: اگر 5 فرضیه را با alpha = 0.05 آزمایش کنید، احتمال حداقل یک نتیجه مثبت کاذب 1 — (0.95)^5 ≈ 22.6% است. تصحیح Bonferroni alpha را بر تعداد مقایسه‌ها تقسیم می‌کند: برای 5 فرضیه alpha = 0.01. این کار تشخیص اثر را محافظه‌کارانه‌تر می‌کند، اما خطر false positive را کاهش می‌دهد.

معیارها، تحلیل نتایج و تصمیم‌گیری

انتخاب معیارها — مهمترین مرحله که کیفیت آزمایش را تعیین می‌کند. Firebase A/B Testing چندین دسته معیار ارائه می‌دهد: تعامل (daily active users, session duration, screens per session)، درآمدزایی (revenue, purchases, subscriptions)، retention (Day 1, Day 7, Day 28)، نرخ تبدیل (conversion rate بر اساس رویداد انتخاب‌شده). معیارهای سفارشی مبتنی بر هر رویداد Firebase Analytics نیز در دسترس هستند.

معیار اولیه (primary metric) — تنها معیاری که بر اساس آن درباره موفقیت آزمایش تصمیم گرفته می‌شود. انتخاب معیار اولیه باید قبل از شروع آزمایش بر اساس فرضیه انجام شود. اگر فرضیه «onboarding جدید نرخ تبدیل ثبت‌نام را افزایش می‌دهد» باشد، معیار اولیه — نرخ تبدیل رویداد sign_up_completed. معیارهای ثانویه (secondary metrics) — شاخص‌های اضافی برای تحلیل عوارض جانبی: آیا retention کاهش نیافته، آیا revenue افت نکرده است.

تفسیر نتایج: Firebase جدولی با مقادیر معیارها برای هر گروه، درصد تفاوت از گروه کنترل، p-value و فاصله اطمینان 95% نمایش می‌دهد. اگر p-value < 0.05 و فاصله اطمینان شامل 0 نباشد — تفاوت از نظر آماری معنی‌دار است. اگر p-value > 0.05 باشد — نتیجه نامشخص (inconclusive) است و آزمایش باید تمدید شود یا به عنوان نامشخص متوقف گردد.

تصمیم‌گیری بر اساس نتایج

Firebase A/B Testing پس از پایان آزمایش سه گزینه ارائه می‌دهد: اعمال نوع برنده برای همه کاربران، ادامه آزمایش (اگر داده‌ها کافی نیست) یا توقف آزمایش بدون اعمال (اگر همه انواع بدتر از کنترل هستند یا نتیجه نامشخص است). اعمال برنده به طور خودکار قالب Remote Config را با مقدار تولیدی نوع برنده به‌روز می‌کند.

توجه: گاهی یک نتیجه معنی‌دار آماری اهمیت عملی ندارد. به عنوان مثال، آزمایش افزایش 0.5% در نرخ تبدیل را نشان داد (p = 0.03)، اما نسخه جدید UI به 2 هفته توسعه نیاز دارد. نسبت هزینه به سود ممکن است به‌صرفه نباشد. تصمیمات را بر اساس تأثیر کسب‌وکار بگیرید، نه فقط معنی‌داری آماری. Firebase نه تنها p-value بلکه تغییر مطلق معیار را نیز نشان می‌دهد که به ارزیابی اهمیت عملی کمک می‌کند.

معیارهای پیشرفته: retention و LTV

Retention — یکی از مهمترین معیارها برای اپلیکیشن‌های موبایل، زیرا مستقیماً با ارزش بلندمدت کاربر (LTV) مرتبط است. Firebase A/B Testing به طور خودکار retention Day 1, Day 7 و Day 28 را برای هر گروه محاسبه می‌کند. اما برای اندازه‌گیری قابل اعتماد retention زمان لازم است: retention Day 7 را می‌توان 7 روز پس از شروع آزمایش ارزیابی کرد، retention Day 28 — پس از 28 روز. مدت زمان آزمایش را با در نظر گرفتن زمان لازم برای جمع‌آوری داده‌های retention برنامه‌ریزی کنید.

LTV (Lifetime Value) — معیار پیچیده‌تری که نیاز به یکپارچگی Firebase با Google Analytics for Firebase و در صورت لزوم با پلتفرم انتساب (Adjust, AppsFlyer) دارد. Firebase A/B Testing امکان استفاده از LTV به عنوان معیار را فراهم می‌کند، اما برای محاسبه آن باید واردات داده‌های خرید و هزینه‌های جذب کاربر را پیکربندی کنید. بدون انتساب، LTV ممکن است نادقیق باشد، زیرا Firebase هزینه نصب از منابع تبلیغاتی را نمی‌بیند.

تنظیم آزمایش A/B از طریق Remote Config

برای انجام آزمایش A/B از طریق Firebase A/B Testing کد خاصی در سمت کلاینت مورد نیاز نیست — کل آزمایش در کنسول Firebase تنظیم می‌شود. با این حال، کد کلاینت باید از پارامترهای Remote Config به درستی استفاده کند تا مقادیر تعیین‌شده توسط آزمایش به درستی اعمال شوند. مثالی را بررسی کنیم: آزمایش A/B قیمت جدید اشتراک، که در آن گروه کنترل قیمت قدیمی (9.99 $) و گروه آزمایشی قیمت جدید (7.99 $) را می‌بینند.

در کنسول Firebase پارامتر Remote Config subscription_price را با مقدار پیش‌فرض «9.99» ایجاد می‌کنیم. سپس آزمایش A/B ایجاد می‌کنیم، جایی که به عنوان نوع برنده مقدار «7.99» را برای 50% کاربران مشخص می‌کنیم. 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 مقدار پارامتر subscription_price را از طریق Remote Config دریافت می‌کند. 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

خطای اثر peek — توقف آزمایش در اولین ظهور معنی‌داری آماری بدون در نظر گرفتن مدت زمان برنامه‌ریزی‌شده. اگر روزانه p-value را بررسی کنید و به محض p < 0.05 متوقف شوید، احتمال نتیجه مثبت کاذب از 5% به 30–40% افزایش می‌یابد. Firebase A/B Testing مدت زمان ثابت آزمایش را توصیه می‌کند. قبل از پایان مهلت محاسبه‌شده به نتایج نگاه نکنید.

عوامل خارجی در نظر گرفته نشده — فصلی بودن، کمپین‌های تبلیغاتی، به‌روزرسانی‌های سیستم عامل، ظهور رقبا. اگر در طول آزمایش A/B یک کمپین تبلیغاتی راه انداخته‌اید که ترکیب ترافیک را تغییر داده است، نتیجه آزمایش ممکن است مخدوش شود. توصیه می‌شود آزمایش‌های A/B را همزمان با فعالیت‌های بازاریابی بزرگ انجام ندهید. اگر اجتناب‌ناپذیر است — مطمئن شوید که ترافیک تبلیغاتی به طور مساوی بین گروه‌ها توزیع می‌شود.

اثر بخش‌بندی (پارادوکس سیمپسون) — وضعیتی که نتیجه کلی عدم وجود اثر را نشان می‌دهد، اما در بخش‌های جداگانه اثر وجود دارد و معکوس است. به عنوان مثال، آزمایش نشان داد که طراحی جدید سفارش به طور متوسط نرخ تبدیل را تغییر نداده است، اما با تقسیم به iOS و Android مشخص شد: در iOS نرخ تبدیل 20% افزایش یافت و در Android 15% کاهش یافت. همیشه نتایج را بر اساس بخش‌های کلیدی بررسی کنید (پلتفرم، کشور، نسخه اپلیکیشن).

مشکل معیارهای متعدد

مشکل مقایسه‌های چندگانه زمانی ایجاد می‌شود که در آزمایش از معیارهای زیادی استفاده شود. اگر 20 معیار را با alpha = 0.05 بررسی کنید، احتمال یافتن حداقل یک تفاوت کاذب معنی‌دار (false positive) برابر 1 — (0.95)^20 ≈ 64% است. Firebase برای چندین معیار اولیه از تصحیح Bonferroni استفاده می‌کند، اما برای معیارهای ثانویه خیر. نتیجه: یک معیار اولیه را قبل از شروع آزمایش انتخاب کنید و در تصمیم‌گیری به p-value معیارهای ثانویه توجه نکنید.

اثر تازگی (Novelty effect) — کاربران ممکن است به تغییر جدید واکنش متفاوتی نشان دهند صرفاً به این دلیل که جدید است، نه به این دلیل که بهتر است. روزهای اول آزمایش ممکن است رشد کاذب نشان دهند (کاربران از روی کنجکاوی دکمه جدید را کلیک می‌کنند) که با گذشت زمان کاهش می‌یابد. حداقل مدت زمان آزمایش 3 روز تا حدی این مشکل را حل می‌کند، اما برای تغییرات UI مدت زمان 7–14 روز توصیه می‌شود تا اثر تازگی تثبیت شود.

تداخل بین آزمایش‌ها

اثر شبکه‌ای (network effect) — مشکل زمانی که رفتار کاربر در یک گروه بر کاربران گروه دیگر تأثیر می‌گذارد. به عنوان مثال، آزمایش A/B تغییر الگوریتم فید خبری: اگر گروه آزمایشی توصیه‌های بهتری دریافت کند، محتوای بیشتری ایجاد می‌کند که کاربران گروه کنترل نیز آن را می‌بینند و نتایج را مخدوش می‌کند. در چنین مواردی از ایزوله‌سازی بر اساس گراف اجتماعی استفاده کنید یا آزمایش را در سطح کشور/منطقه انجام دهید.

آزمایش‌های همزمان روی یک پارامتر Remote Config — منبع دیگری از تداخل. Firebase A/B Testing اجازه راه‌اندازی آزمایش دوم روی پارامتری که قبلاً اشغال شده را نمی‌دهد، اما اگر آزمایش‌ها پارامترهای مختلفی را تحت تأثیر قرار دهند اما روی یک معیار تأثیر بگذارند، اثر متقاطع ممکن است. توصیه می‌شود همزمان بیش از 2–3 آزمایش A/B فعال انجام ندهید و اطمینان حاصل کنید که روی سناریوهای کاربری یکسان تأثیر نمی‌گذارند.