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

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

اندازه نمونه

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

آزمایش ها را ویرایش کنید

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

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

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

1. صفحه نتایج آزمایشی را که می خواهید تغییر دهید باز کنید.
2. از منوی More_vert more_vert ویرایش آزمایش در حال اجرا را انتخاب کنید.
3. تغییرات خود را انجام دهید، سپس روی انتشار کلیک کنید.

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

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

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

مخاطبان Google Analytics در معرض تأخیر هستند و زمانی که کاربر در ابتدا معیارهای مخاطب را داشته باشد، فوراً در دسترس نیستند:

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

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

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

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

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

وزن های مختلف

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

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

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

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

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

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

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

برای هر متریک، آمار زیر نمایش داده می شود:

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

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

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

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

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

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

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

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

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

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

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

برای هر متریک، آمار زیر نمایش داده می شود:

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

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

داده های مدل شده

• احتمال شکست خط پایه: چقدر احتمال دارد که معیار برای این نوع در مقایسه با خط پایه بالاتر باشد
• درصد تفاوت با خط پایه: بر اساس برآوردهای مدل میانه متریک برای متغیر و خط پایه
• محدوده های متریک: محدوده هایی که به احتمال زیاد مقدار متریک در آنها یافت می شود، با اطمینان 50٪ و 95٪

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

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

عزم رهبر

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

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

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

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

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

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

Firebase توصیه می کند که یک آزمایش تا زمانی که شرایط زیر برآورده شود به اجرا ادامه یابد:

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

داده های آزمایش حداکثر تا 90 روز پس از شروع آزمایش پردازش می شوند. پس از 90 روز، آزمایش به طور خودکار متوقف می شود. نتایج آزمایش دیگر در کنسول 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 در کنسول Firebase فعال کنید
2. با استفاده از BigQuery به داده های A/B Testing دسترسی پیدا کنید
3. پرس و جوهای نمونه را کاوش کنید

صادرات BigQuery برای Google Analytics در کنسول Firebase فعال کنید

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

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

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

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

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

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

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

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

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

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

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

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

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

برای به دست آوردن و اجرای پرس و جو تولید شده خودکار:

1. از کنسول Firebase ، A/B Testing باز کنید و آزمایش A/B Testing را که می‌خواهید پرس و جو کنید انتخاب کنید تا نمای کلی آزمایش باز شود.
2. از منوی گزینه‌ها، در زیر ادغام BigQuery ، Query experience 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 استفاده کنید. بیانیه BigQuery SQL زیر انواع آزمایش، تعداد کاربران منحصربه‌فرد در هر گونه را استخراج می‌کند و کل درآمد حاصل از رویدادهای 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

محدودیت ها

A/B Testing به 300 آزمایش کل، 24 آزمایش در حال اجرا و 24 آزمایش پیش نویس محدود شده است. این محدودیت‌ها با نسخه‌های Remote Config مشترک هستند. به عنوان مثال، اگر دو نسخه در حال اجرا و سه آزمایش در حال اجرا دارید، می توانید تا 19 نسخه یا آزمایش اضافی داشته باشید.

• اگر به حداکثر 300 آزمایش آزمایشی یا 24 آزمایش پیش‌نویس رسیدید، باید قبل از ایجاد آزمایش جدید، آزمایش موجود را حذف کنید.

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

یک آزمایش می تواند حداکثر 8 نوع (شامل خط پایه) و حداکثر 25 پارامتر برای هر نوع داشته باشد. یک آزمایش می تواند تا حدود 200 کیلو بایت اندازه داشته باشد. این شامل نام انواع، پارامترهای متغیر، و سایر متادیتاهای پیکربندی است.