درباره تست های Firebase A/B

برای کمک به شما در به حداکثر رساندن ارتباط و سودمندی نتایج آزمایش خود، این صفحه اطلاعات دقیقی در مورد نحوه عملکرد Firebase A/B Testing ارائه می‌دهد.

حجم نمونه

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

ویرایش آزمایش‌ها

شما می‌توانید پارامترهای انتخاب‌شده‌ی آزمایش‌های در حال اجرا را ویرایش کنید، از جمله:

  • نام آزمایش
  • توضیحات
  • شرایط هدف‌گذاری
  • مقادیر متغیر

برای ویرایش یک آزمایش:

  1. صفحه نتایج آزمایشی را که می‌خواهید تغییر دهید، باز کنید.
  2. از منوی More ، گزینه‌ی Edit running experiment را انتخاب کنید.
  3. تغییرات خود را اعمال کنید، سپس روی انتشار کلیک کنید.

توجه داشته باشید که تغییر رفتار برنامه در طول یک آزمایش در حال اجرا ممکن است بر نتایج تأثیر بگذارد.

منطق انتساب نوع پیکربندی از راه دور

کاربرانی که با تمام شرایط هدف‌گذاری آزمایش (از جمله شرط درصد مواجهه) مطابقت دارند، بر اساس وزن‌های متغیر و هش شناسه آزمایش و شناسه نصب Firebase کاربر، به انواع آزمایش اختصاص داده می‌شوند.

مخاطبان Google Analytics با تأخیر مواجه می‌شوند و وقتی کاربری در ابتدا معیارهای مخاطب را برآورده می‌کند، بلافاصله در دسترس نیستند:

  • وقتی مخاطب جدیدی ایجاد می‌کنید، ممکن است ۲۴ تا ۴۸ ساعت طول بکشد تا کاربران جدید جمع شوند.
  • کاربران جدید معمولاً ۲۴ تا ۴۸ ساعت پس از واجد شرایط شدن، در فهرست مخاطبان واجد شرایط ثبت می‌شوند.

برای هدف‌گذاری حساس به زمان، استفاده از ویژگی‌های کاربر Google Analytics یا گزینه‌های هدف‌گذاری داخلی مانند کشور یا منطقه، زبان و نسخه برنامه را در نظر بگیرید.

وقتی کاربری وارد یک آزمایش می‌شود، تا زمانی که آزمایش فعال باشد، به طور مداوم به نوع آزمایش خود اختصاص داده می‌شود و مقادیر پارامتر را از آزمایش دریافت می‌کند، حتی اگر ویژگی‌های کاربری او تغییر کند و دیگر معیارهای هدف‌گذاری آزمایش را نداشته باشد.

رویدادهای فعال‌سازی

رویدادهای فعال‌سازی آزمایش، اندازه‌گیری آزمایش را به کاربران برنامه که رویداد فعال‌سازی را فعال می‌کنند، محدود می‌کنند. رویداد فعال‌سازی آزمایش هیچ تاثیری بر پارامترهای آزمایشی که توسط برنامه دریافت می‌شوند، ندارد؛ همه کاربرانی که معیارهای هدف‌گذاری آزمایش را برآورده می‌کنند، پارامترهای آزمایش را دریافت خواهند کرد. در نتیجه، انتخاب یک رویداد فعال‌سازی که پس از دریافت و فعال‌سازی پارامترهای آزمایش، اما قبل از استفاده از پارامترهای آزمایش برای تغییر رفتار برنامه رخ دهد، مهم است.

وزن‌های متغیر

در طول ایجاد آزمایش، می‌توان وزن‌های پیش‌فرض متغیرها را تغییر داد تا درصد بیشتری از کاربران آزمایش در یک متغیر قرار گیرند.

تفسیر نتایج آزمایش

Firebase A/B Testing از استنتاج فراوانی‌گرایانه برای کمک به شما در درک احتمال وقوع نتایج آزمایش صرفاً به دلیل شانس تصادفی استفاده می‌کند. این احتمال با مقدار احتمال یا p-value نشان داده می‌شود. p-value احتمال این است که تفاوت در عملکرد به این بزرگی یا بزرگتر، بین دو متغیر، در صورت عدم وجود هیچ تأثیری، می‌توانست به دلیل شانس تصادفی رخ دهد، که با مقداری بین 0 تا 1 اندازه‌گیری می‌شود. A/B Testing از سطح معنی‌داری 0.05 استفاده می‌کند، به طوری که:

  • مقدار p کمتر از 0.05 نشان می‌دهد که اگر تفاوت واقعی صفر باشد، کمتر از 5٪ احتمال وجود دارد که تفاوت مشاهده شده تا این حد به صورت تصادفی رخ دهد. از آنجا که 0.05 آستانه است، هر مقدار p کمتر از 0.05 نشان دهنده تفاوت آماری معنی‌دار بین متغیرها است.
  • مقدار p بزرگتر از 0.05 نشان می‌دهد که تفاوت بین متغیرها از نظر آماری معنی‌دار نیست.

داده‌های آزمایش روزی یک بار به‌روزرسانی می‌شوند و آخرین زمان به‌روزرسانی در بالای صفحه نتایج آزمایش نمایش داده می‌شود.

نمودار نتایج آزمایش، مقادیر میانگین تجمعی معیار انتخاب شده را نمایش می‌دهد. برای مثال، اگر درآمد حاصل از تبلیغات به ازای هر کاربر را به عنوان یک معیار دنبال می‌کنید، درآمد مشاهده شده به ازای هر کاربر را نمایش می‌دهد و اگر کاربران بدون خرابی را دنبال می‌کنید، درصد کاربرانی را که با خرابی مواجه نشده‌اند، دنبال می‌کند. این داده‌ها از ابتدای آزمایش تجمعی هستند.

نتایج به دو بخش داده‌های مشاهده‌شده و داده‌های استنباطی تقسیم می‌شوند. داده‌های مشاهده‌شده مستقیماً از داده‌های گوگل آنالیتیکس محاسبه می‌شوند و داده‌های استنباطی، مقادیر p و فواصل اطمینان را برای کمک به شما در ارزیابی اهمیت آماری داده‌های مشاهده‌شده ارائه می‌دهند.

برای هر معیار، آمار زیر نمایش داده می‌شود:

داده‌های مشاهده‌شده

  • ارزش کل برای معیار ردیابی شده (تعداد کاربران حفظ شده، تعداد کاربرانی که از کار افتاده‌اند، کل درآمد)
  • نرخ ویژه معیار (نرخ حفظ، نرخ تبدیل، درآمد به ازای هر کاربر)
  • درصد اختلاف (افزایش) بین متغیر و پایه

داده‌های استنتاج

  • 95% CI (اختلاف در میانگین‌ها) بازه ای را نشان می‌دهد که شامل مقدار "واقعی" معیار ردیابی شده با اطمینان 95% است. به عنوان مثال، اگر آزمایش شما منجر به 95% CI برای درآمد کل تخمینی بین 5 تا 10 دلار شود، 95% احتمال وجود دارد که اختلاف واقعی در میانگین‌ها بین 5 تا 10 دلار باشد. اگر محدوده CI شامل 0 باشد، تفاوت آماری معنی‌داری بین متغیر و پایه مشاهده نشده است.

    مقادیر فاصله اطمینان در قالبی که با معیار ردیابی شده مطابقت دارد، ظاهر می‌شوند. به عنوان مثال، زمان (به صورت HH:MM:SS ) برای ماندگاری کاربر، دلار آمریکا برای درآمد تبلیغات به ازای هر کاربر و درصد برای نرخ تبدیل.

  • مقدار P ، که نشان دهنده احتمال مشاهده داده‌ها به شدت نتایج به دست آمده در آزمایش است، با توجه به اینکه هیچ تفاوت واقعی بین متغیر و پایه وجود ندارد. هرچه مقدار p کمتر باشد، اطمینان بیشتری وجود دارد که عملکرد مشاهده شده در صورت تکرار آزمایش درست باقی بماند. مقدار 0.05 یا کمتر نشان دهنده تفاوت معنی دار و احتمال کم شانسی بودن نتایج است. مقادیر P بر اساس آزمون یک طرفه هستند، که در آن مقدار متغیر بزرگتر از مقدار پایه است. Firebase از آزمون t با واریانس نابرابر برای متغیرهای پیوسته (مقادیر عددی، مانند درآمد) و از آزمون z نسبت‌ها برای داده‌های تبدیل (مقادیر دودویی، مانند ماندگاری کاربر، کاربران بدون خرابی، کاربرانی که یک رویداد Google Analytics فعال می‌کنند) استفاده می‌کند.

نتایج آزمایش، بینش‌های مهمی را برای هر نوع آزمایش ارائه می‌دهد، از جمله:

  • هر معیار آزمایش در مقایسه با مقدار پایه، که مستقیماً اندازه‌گیری شده است (یعنی داده‌های مشاهده شده واقعی)، چقدر بالاتر یا پایین‌تر است؟
  • احتمال اینکه تفاوت مشاهده‌شده بین متغیر و حالت پایه به دلیل شانس تصادفی رخ داده باشد (مقدار p)
  • محدوده‌ای که احتمالاً شامل تفاوت عملکرد «واقعی» بین متغیر و مقدار پایه برای هر معیار آزمایش باشد --- راهی برای درک سناریوهای عملکرد «بهترین حالت» و «بدترین حالت»

تفسیر نتایج آزمایش‌های ارائه شده توسط Google Optimize

نتایج Firebase A/B Testing برای آزمایش‌هایی که قبل از ۲۳ اکتبر ۲۰۲۳ آغاز شده‌اند، توسط گوگل آپتیمایز پشتیبانی می‌شوند. گوگل آپتیمایز از استنتاج بیزی برای تولید آمار دقیق از داده‌های آزمایش شما استفاده می‌کند.

نتایج به «داده‌های مشاهده‌شده» و «داده‌های مدل‌سازی‌شده» تقسیم می‌شوند. داده‌های مشاهده‌شده مستقیماً از داده‌های تحلیلی محاسبه شدند و داده‌های مدل‌سازی‌شده از اعمال مدل بیزی ما بر روی داده‌های مشاهده‌شده به دست آمدند.

برای هر معیار، آمار زیر نمایش داده می‌شود:

داده‌های مشاهده‌شده

  • مقدار کل (مجموع معیار برای همه کاربران در نوع)
  • مقدار میانگین (مقدار میانگین معیار برای کاربران در نوع)
  • درصد اختلاف از سطح پایه

داده‌های مدل‌سازی‌شده

  • احتمال بالاتر رفتن از خط پایه: چقدر احتمال دارد که معیار برای این متغیر در مقایسه با خط پایه بالاتر باشد
  • درصد اختلاف از سطح پایه: بر اساس تخمین‌های مدل میانه از معیار برای متغیر و سطح پایه
  • محدوده‌های معیار: محدوده‌هایی که احتمال یافتن مقدار معیار در آنها با ۵۰٪ و ۹۵٪ قطعیت بیشتر است.

به طور کلی، نتایج آزمایش سه بینش مهم برای هر نوع در آزمایش به ما می‌دهد:

  1. هر معیار آزمایش در مقایسه با مقدار پایه، که مستقیماً اندازه‌گیری شده است (یعنی داده‌های مشاهده‌شده واقعی)، چقدر بالاتر یا پایین‌تر است؟
  2. چقدر احتمال دارد که هر معیار آزمایش، بر اساس استنتاج بیزی، بالاتر از خط پایه/بهترین حالت کلی باشد (به ترتیب احتمال بهتر/بهترین بودن)
  3. محدوده‌های محتمل برای هر معیار آزمایش بر اساس استنتاج بیزی - سناریوهای «بهترین حالت» و «بدترین حالت» (بازه‌های معتبر)

عزم رهبر

برای آزمایش‌هایی که از استنتاج فراوانی‌گرا استفاده می‌کنند، فایربیس اعلام می‌کند که یک متغیر در صورتی پیشرو است که تفاوت عملکرد آماری معناداری بین متغیر و خط پایه در معیار هدف وجود داشته باشد. اگر چندین متغیر این معیار را داشته باشند، متغیری با کمترین مقدار p انتخاب می‌شود.

برای آزمایش‌هایی که از Google Optimize استفاده کردند، Firebase اعلام کرد که یک متغیر در صورتی «رهبر واضح» است که بیش از ۹۵٪ شانس بهتر بودن از متغیر پایه در معیار اولیه را داشته باشد. اگر چندین متغیر معیارهای «رهبر واضح» را برآورده می‌کردند، تنها متغیری که در کل بهترین عملکرد را داشت، به عنوان «رهبر واضح» برچسب‌گذاری می‌شد.

از آنجایی که تعیین رهبر فقط بر اساس هدف اصلی است، شما باید قبل از تصمیم‌گیری در مورد اجرای یا عدم اجرای یک نوع پیشرو، تمام عوامل مرتبط را در نظر بگیرید و نتایج معیارهای ثانویه را بررسی کنید. ممکن است بخواهید جنبه مثبت مورد انتظار از ایجاد تغییر، ریسک منفی (مانند پایین‌ترین حد فاصله اطمینان برای بهبود) و تأثیر آن بر معیارهایی غیر از هدف اصلی را در نظر بگیرید.

برای مثال، اگر معیار اصلی شما کاربران بدون خرابی است و نوع A به وضوح از حالت پایه جلوتر است، اما معیارهای حفظ کاربر نوع A از حالت پایه پایین‌تر است، بهتر است قبل از انتشار گسترده‌تر نوع A، بررسی‌های بیشتری انجام دهید.

شما می‌توانید بر اساس ارزیابی کلی خود از عملکرد در معیارهای اولیه و ثانویه، هر نوع (و نه فقط یک نوع پیشرو) را راه‌اندازی کنید.

مدت زمان آزمایش

فایربیس توصیه می‌کند که آزمایش تا زمان برآورده شدن شرایط زیر ادامه یابد:

  1. این آزمایش داده‌های کافی برای ارائه یک نتیجه مفید را جمع‌آوری کرده است. داده‌های آزمایش‌ها و نتایج روزانه یک بار به‌روزرسانی می‌شوند. می‌توانید برای ارزیابی حجم نمونه توصیه‌شده برای آزمایش خود، از یک محاسبه‌گر حجم نمونه آنلاین استفاده کنید.
  2. این آزمایش به اندازه کافی طولانی اجرا شده است تا نمونه‌ای نماینده از کاربران شما را تضمین کند و عملکرد بلندمدت را اندازه‌گیری کند. دو هفته حداقل زمان توصیه شده برای یک آزمایش معمول Remote Config است.

داده‌های آزمایش حداکثر تا ۹۰ روز پس از شروع آزمایش پردازش می‌شوند. پس از ۹۰ روز، آزمایش به طور خودکار متوقف می‌شود. نتایج آزمایش دیگر در کنسول Firebase به‌روزرسانی نمی‌شوند و آزمایش ارسال مقادیر پارامترهای خاص آزمایش را متوقف می‌کند. در این مرحله، کلاینت‌ها بر اساس شرایط تعیین شده در الگوی Remote Config شروع به دریافت مقادیر پارامترها می‌کنند. داده‌های آزمایش‌های گذشته تا زمانی که آزمایش را حذف کنید، حفظ می‌شوند.

طرحواره 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 در کنسول فایربیس
  2. دسترسی به داده‌های A/B Testing با استفاده از BigQuery
  3. کاوش در نمونه سوالات

فعال کردن خروجی BigQuery برای Google Analytics در کنسول فایربیس

اگر از طرح Spark استفاده می‌کنید، می‌توانید از محیط سندباکس BigQuery برای دسترسی رایگان BigQuery استفاده کنید، البته با توجه به محدودیت‌های Sandbox . برای اطلاعات بیشتر به بخش قیمت‌گذاری و محیط سندباکس BigQuery مراجعه کنید.

ابتدا مطمئن شوید که داده‌های Analytics خود را به BigQuery منتقل می‌کنید:

  1. تب Integrations را باز کنید، که می‌توانید با استفاده از > Project settings در کنسول Firebase به آن دسترسی پیدا کنید.
  2. اگر از قبل از BigQuery با سایر سرویس‌های Firebase استفاده می‌کنید، روی Manage کلیک کنید. در غیر این صورت، روی Link کلیک کنید.
  3. درباره اتصال Firebase به BigQuery نظر بدهید، سپس روی Next کلیک کنید.
  4. در بخش پیکربندی ادغام ، گزینه‌ی Google Analytics را فعال کنید.

  5. یک منطقه را انتخاب کنید و تنظیمات صادرات را انتخاب کنید.

  6. روی پیوند به BigQuery کلیک کنید.

بسته به نحوه‌ی انتخاب شما برای خروجی گرفتن از داده‌ها، ممکن است تا یک روز طول بکشد تا جداول در دسترس قرار گیرند. برای اطلاعات بیشتر در مورد خروجی گرفتن از داده‌های پروژه به BigQuery ، به بخش خروجی گرفتن از داده‌های پروژه به BigQuery مراجعه کنید.

دسترسی به داده‌های A/B Testing در BigQuery

قبل از جستجوی داده‌ها برای یک آزمایش خاص، باید برخی یا همه موارد زیر را برای استفاده در جستجوی خود به دست آورید:

  • شناسه آزمایش: می‌توانید این را از آدرس اینترنتی صفحه مرور کلی آزمایش دریافت کنید. برای مثال، اگر آدرس اینترنتی شما به شکل https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25 باشد، شناسه آزمایش ۲۵ است.
  • شناسه ویژگی Google Analytics : این شناسه ۹ رقمی ویژگی Google Analytics شماست. می‌توانید آن را در Google Analytics پیدا کنید؛ همچنین در BigQuery وقتی نام پروژه خود را باز می‌کنید تا نام جدول رویداد Google Analytics شما ( project_name.analytics_000000000.events ) نمایش داده می‌شود، ظاهر می‌شود.
  • تاریخ آزمایش: برای نوشتن یک پرس‌وجوی سریع‌تر و کارآمدتر، بهتر است پرس‌وجوهای خود را به پارتیشن‌های جدول رویدادهای روزانه Google Analytics که حاوی داده‌های آزمایش شما هستند - جداولی که با پسوند YYYYMMDD مشخص می‌شوند - محدود کنید. بنابراین، اگر آزمایش شما از ۲ فوریه ۲۰۲۴ تا ۲ مه ۲۰۲۴ انجام شده است، باید یک _TABLE_SUFFIX between '20240202' AND '20240502' تعیین کنید. برای مثال، به بخش « مقادیر یک آزمایش خاص را انتخاب کنید » مراجعه کنید.
  • نام رویدادها: معمولاً این نام‌ها با معیارهای هدف شما که در آزمایش پیکربندی کرده‌اید، مطابقت دارند. برای مثال، رویدادهای in_app_purchase ، ad_impression یا user_retention .

پس از جمع‌آوری اطلاعات مورد نیاز برای ایجاد پرس‌وجو:

  1. BigQuery در کنسول Google Cloud باز کنید.
  2. پروژه خود را انتخاب کنید، سپس گزینه Create SQL query را انتخاب کنید.
  3. پرس‌وجوی خود را اضافه کنید. برای مثال‌هایی از پرس‌وجوهایی که باید اجرا شوند، به بخش «پرس‌وجوهای نمونه را کاوش کنید» مراجعه کنید.
  4. روی اجرا کلیک کنید.

داده‌های آزمایش را با استفاده از کوئری تولید شده خودکار کنسول Firebase جستجو کنید

اگر از طرح Blaze استفاده می‌کنید، صفحه مرور کلی آزمایش ، یک نمونه پرس‌وجو ارائه می‌دهد که نام آزمایش، انواع آن، نام رویدادها و تعداد رویدادهای آزمایشی که مشاهده می‌کنید را برمی‌گرداند.

برای دریافت و اجرای کوئری تولید شده خودکار:

  1. از کنسول Firebase ، A/B Testing را باز کنید و آزمایش A/B Testing مورد نظر خود را برای پرس و جو انتخاب کنید تا نمای کلی آزمایش باز شود.
  2. از منوی Options، در زیر BigQuery integration ، گزینه Query experiment data را انتخاب کنید. این کار پروژه شما را در 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 تک‌طرفه استفاده کنید تا تأیید کنید که نتایج ارائه شده توسط فایربیس با تحلیل شما مطابقت دارد.

برای اطلاعات بیشتر در مورد نحوه محاسبه استنتاج 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 را نشان می‌دهد. این نمونه پرس‌وجو نام آزمایش، نام‌های مختلف (از جمله Baseline)، نام رویدادها و تعداد رویدادها را برمی‌گرداند.

  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

محدودیت‌ها

A/B Testing به ۳۰۰ آزمایش در کل، ۲۴ آزمایش در حال اجرا و ۲۴ آزمایش در حال پیش‌نویس محدود شده است. این محدودیت‌ها با تنظیمات Remote Config نیز مشترک هستند. برای مثال، اگر دو تنظیمات در حال اجرا و سه آزمایش در حال اجرا دارید، می‌توانید تا ۱۹ تنظیمات یا آزمایش اضافی داشته باشید.

  • اگر به محدودیت ۳۰۰ آزمایش در کل یا محدودیت ۲۴ آزمایش پیش‌نویس برسید، باید قبل از ایجاد یک آزمایش جدید، یک آزمایش موجود را حذف کنید.

  • اگر به محدودیت ۲۴ آزمایش یا انتشار در حال اجرا رسیدید، قبل از شروع یک آزمایش یا انتشار جدید، باید آن را متوقف کنید.

یک آزمایش می‌تواند حداکثر ۸ نوع (شامل خط پایه) و تا ۲۵ پارامتر برای هر نوع داشته باشد. یک آزمایش می‌تواند حجمی تا حدود ۲۰۰ کیلوبایت داشته باشد. این شامل نام انواع، پارامترهای انواع و سایر فراداده‌های پیکربندی می‌شود.