آزمایش‌های پیکربندی از راه دور Firebase را با آزمایش A/B ایجاد کنید

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

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

برای انواع ویژگی های تست A/B با خط مبنا، موارد زیر را انجام دهید:

  1. آزمایش خود را ایجاد کنید
  2. آزمایش خود را روی دستگاه آزمایشی تأیید کنید.
  3. آزمایش خود را مدیریت کنید

یک آزمایش ایجاد کنید

آزمایش Remote Config به شما امکان می‌دهد چندین نوع را روی یک یا چند پارامتر Remote Config ارزیابی کنید.

  1. به کنسول Firebase وارد شوید و بررسی کنید که Google Analytics در پروژه شما فعال است تا آزمایش به داده های Analytics دسترسی داشته باشد.

    اگر Google Analytics هنگام ایجاد پروژه خود فعال نکرده اید، می توانید آن را در برگه Integrations فعال کنید، که می توانید با استفاده از > تنظیمات پروژه در کنسول Firebase به آن دسترسی داشته باشید.

  2. در بخش Engage از منوی پیمایش کنسول Firebase ، روی A/B Testing کلیک کنید.

  3. روی ایجاد آزمایش کلیک کنید و سپس هنگامی که از سرویسی که می خواهید آزمایش کنید از شما خواسته شد Remote Config را انتخاب کنید.

  4. یک نام و توضیحات اختیاری برای آزمایش خود وارد کنید و روی Next کلیک کنید.

  5. فیلدهای Targeting را پر کنید، ابتدا برنامه ای را انتخاب کنید که از آزمایش شما استفاده می کند. همچنین می‌توانید زیرمجموعه‌ای از کاربران خود را برای شرکت در آزمایش خود با کلیک کردن و سپس انتخاب گزینه‌هایی از لیست زیر هدف قرار دهید:

    • نسخه: یک یا چند نسخه از برنامه شما
    • شماره ساخت: کد نسخه برنامه
    • زبان‌ها: یک یا چند زبان و منطقه مورد استفاده برای انتخاب کاربرانی که ممکن است در آزمایش گنجانده شوند
    • کشور/منطقه: یک یا چند کشور یا منطقه برای انتخاب کاربرانی که باید در آزمایش گنجانده شوند
    • مخاطبان کاربر: مخاطبان Analytics برای هدف قرار دادن کاربرانی که ممکن است در آزمایش گنجانده شوند استفاده می شود
    • ویژگی کاربر: یک یا چند ویژگی کاربر Analytics برای انتخاب کاربرانی که ممکن است در آزمایش گنجانده شوند
    • اولین باز: کاربران را بر اساس اولین باری که برنامه شما را باز کرده اند مورد هدف قرار دهید

      پس از انتخاب یک برنامه Android یا iOS، هدف‌گیری کاربر بر اساس اولین زمان باز در دسترس است. توسط نسخه‌های Remote Config SDK زیر پشتیبانی می‌شود: پلتفرم‌های Apple SDK v9.0.0+ و Android SDK v21.1.1+ ( Firebase BoM v30.3.0+).

      Analytics همچنین باید در اولین رویداد باز روی مشتری فعال شده باشد.

  6. تنظیم درصد کاربران هدف: درصدی از پایگاه کاربر برنامه خود را وارد کنید که با معیارهای تعیین شده در زیر کاربران هدف مطابقت دارد که می‌خواهید به طور مساوی بین خط مبنا و یک یا چند نوع در آزمایش خود تقسیم کنید. این می تواند هر درصدی بین 0.01٪ و 100٪ باشد. کاربران به طور تصادفی به هر آزمایش، از جمله آزمایش‌های تکراری، اختصاص داده می‌شوند.

  7. در صورت تمایل، یک رویداد فعال‌سازی تنظیم کنید تا مطمئن شوید که فقط داده‌های کاربرانی که برای اولین بار برخی رویدادهای Analytics را راه‌اندازی کرده‌اند در آزمایش شما شمارش می‌شوند. توجه داشته باشید که همه کاربرانی که با پارامترهای هدف شما مطابقت دارند مقادیر آزمایشی Remote Config را دریافت خواهند کرد، اما فقط کسانی که یک رویداد فعال‌سازی را راه‌اندازی می‌کنند در نتایج آزمایش شما لحاظ می‌شوند.

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

    • app_install
    • app_remove
    • app_update
    • dynamic_link_first_open
  8. برای اهداف آزمایش، معیار اصلی را برای ردیابی انتخاب کنید، و هر معیار دیگری را که می‌خواهید ردیابی کنید از فهرست اضافه کنید. اینها شامل اهداف داخلی (خرید، درآمد، حفظ، کاربران بدون خرابی و غیره)، رویدادهای تبدیل Analytics و سایر رویدادهای Analytics است. پس از اتمام، روی Next کلیک کنید.

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

  10. (اختیاری) برای افزودن بیش از یک نوع به آزمایش خود، روی افزودن یک نوع دیگر کلیک کنید.

  11. یک یا چند پارامتر را برای انواع خاص تغییر دهید. هر پارامتر بدون تغییر برای کاربرانی که در آزمایش گنجانده نشده اند یکسان است.

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

  13. برای ذخیره آزمایش خود، روی Review کلیک کنید.

شما مجاز به 300 آزمایش در هر پروژه هستید که می تواند شامل حداکثر 24 آزمایش در حال اجرا باشد و بقیه به صورت پیش نویس یا تکمیل شده باشد.

آزمایش خود را روی دستگاه آزمایشی تأیید کنید

برای هر نصب Firebase، می‌توانید نشانه تأیید اعتبار نصب مرتبط با آن را بازیابی کنید. می‌توانید از این نشانه برای آزمایش انواع آزمایشی خاص در دستگاه آزمایشی با نصب برنامه خود استفاده کنید. برای تأیید آزمایش خود بر روی یک دستگاه آزمایشی، موارد زیر را انجام دهید:

  1. رمز تأیید نصب را به صورت زیر دریافت کنید:
    do {
      let result = try await Installations.installations()
        .authTokenForcingRefresh(true)
      print("Installation auth token: \(result.authToken)")
    } catch {
      print("Error fetching token: \(error)")
    }
    [[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]);
    }];
    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");
            }
        }
    });
    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")
            }
        }
    firebase::InitResult init_result;
    auto* installations_object = firebase::installations::Installations::GetInstance(
        firebase::App::GetInstance(), &init_result);
    installations_object->GetToken().OnCompletion(
        [](const firebase::Future<std::string>& future) {
          if (future.status() == kFutureStatusComplete &&
              future.error() == firebase::installations::kErrorNone) {
            printf("Installations Auth Token %s\n", future.result()->c_str());
          }
        });
    Firebase.Installations.FirebaseInstallations.DefaultInstance.GetTokenAsync(forceRefresh: true).ContinueWith(
      task => {
        if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
          UnityEngine.Debug.Log(System.String.Format("Installations token {0}", task.Result));
        }
      });
  2. در نوار پیمایش کنسول Firebase ، روی A/B Testing کلیک کنید.
  3. روی پیش‌نویس (و/یا اجرای آزمایش‌های پیکربندی از راه دور) کلیک کنید، نشانگر را روی آزمایش خود نگه دارید، روی منوی زمینه ( ) و سپس روی مدیریت دستگاه‌های آزمایشی کلیک کنید.
  4. رمز تأیید نصب را برای یک دستگاه آزمایشی وارد کنید و نوع آزمایشی را برای ارسال به آن دستگاه آزمایشی انتخاب کنید.
  5. برنامه را اجرا کنید و تأیید کنید که نوع انتخاب شده در دستگاه آزمایشی دریافت می شود.

برای کسب اطلاعات بیشتر در مورد نصب های Firebase ، به مدیریت نصب های Firebase مراجعه کنید.

آزمایش خود را مدیریت کنید

چه با Remote Config ، اعلان‌ها یا Firebase In-App Messaging آزمایشی ایجاد کنید، سپس می‌توانید آزمایش خود را تأیید کرده و شروع کنید، آزمایش خود را در حین اجرا نظارت کنید و تعداد کاربرانی را که در آزمایش در حال اجرا گنجانده شده‌اند افزایش دهید.

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

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

  1. در بخش Engage از منوی پیمایش کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. روی پیش نویس کلیک کنید و سپس روی عنوان آزمایش خود کلیک کنید.
  3. برای تأیید اینکه برنامه شما دارای کاربرانی است که در آزمایش شما گنجانده می‌شوند، جزئیات پیش‌نویس را گسترش دهید و عددی بیشتر از 0 درصد را در بخش هدف‌گیری و توزیع بررسی کنید (به عنوان مثال، 1 درصد از کاربران با معیارها مطابقت دارند ).
  4. برای تغییر آزمایش خود، روی ویرایش کلیک کنید.
  5. برای شروع آزمایش، روی شروع آزمایش کلیک کنید. شما می توانید تا 24 آزمایش را در هر پروژه در یک زمان اجرا کنید.

نظارت بر یک آزمایش

وقتی آزمایشی برای مدتی اجرا شد، می‌توانید پیشرفت آن را بررسی کنید و ببینید نتایج شما برای کاربرانی که تاکنون در آزمایش شما شرکت کرده‌اند چگونه است.

  1. در بخش Engage از منوی پیمایش کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. روی Running کلیک کنید و سپس روی عنوان آزمایش خود کلیک کنید یا آن را جستجو کنید. در این صفحه می‌توانید آمارهای مشاهده‌شده و مدل‌سازی‌شده‌ای در مورد آزمایش در حال اجرا خود مشاهده کنید، از جمله موارد زیر:

    • درصد تفاوت با خط مبنا : معیاری برای بهبود یک متریک برای یک نوع معین در مقایسه با خط پایه. با مقایسه محدوده مقدار برای متغیر با محدوده ارزش برای خط مبنا محاسبه می شود.
    • احتمال شکست خط پایه : احتمال تخمین زده شده که یک نوع معین از خط مبنا برای متریک انتخاب شده عبور کند.
    • observed_metric برای هر کاربر : بر اساس نتایج آزمایش، این محدوده پیش‌بینی‌شده‌ای است که مقدار متریک در طول زمان در آن قرار می‌گیرد.
    • مجموع observed_metric : مقدار تجمعی مشاهده شده برای خط مبنا یا متغیر. این مقدار برای اندازه‌گیری عملکرد هر یک از انواع آزمایش استفاده می‌شود و برای محاسبه بهبود ، محدوده ارزش ، احتمال شکست خط پایه و احتمال بهترین نوع استفاده می‌شود. بسته به معیاری که اندازه‌گیری می‌شود، این ستون ممکن است دارای برچسب «مدت هر کاربر»، «درآمد به ازای هر کاربر»، «نرخ حفظ» یا «نرخ تبدیل» باشد.
  3. پس از اینکه آزمایش شما برای مدتی اجرا شد (حداقل ۷ روز برای FCM و In-App Messaging یا ۱۴ روز برای Remote Config )، داده‌های این صفحه نشان می‌دهد که کدام نوع، در صورت وجود، «رهبر» است. برخی از اندازه‌گیری‌ها با نمودار میله‌ای همراه هستند که داده‌ها را در قالب تصویری ارائه می‌کند.

آزمایشی را برای همه کاربران اجرا کنید

پس از اینکه یک آزمایش به اندازه کافی طولانی شد که یک "رهبر" یا نوع برنده برای معیار هدف خود داشته باشید، می توانید آزمایش را برای 100٪ از کاربران منتشر کنید. این به شما امکان می دهد یک نوع را برای انتشار برای همه کاربران در حال حرکت انتخاب کنید. حتی اگر آزمایش شما برنده مشخصی ایجاد نکرده باشد، همچنان می توانید انتخاب کنید که یک نسخه برای همه کاربران خود منتشر کنید.

  1. در بخش Engage از منوی پیمایش کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. روی Completed یا Running کلیک کنید، آزمایشی را که می‌خواهید برای همه کاربران منتشر کنید، روی منوی زمینه ( ) Roll out variant کلیک کنید.
  3. با انجام یکی از موارد زیر، آزمایش خود را برای همه کاربران عرضه کنید:

    • برای آزمایشی که از سازنده اعلان‌ها استفاده می‌کند، از گفتگوی ارسال پیام استفاده کنید تا پیام را به سایر کاربران هدفمندی که بخشی از آزمایش نبودند ارسال کنید.
    • برای آزمایش Remote Config ، یک متغیر را انتخاب کنید تا مشخص شود کدام مقادیر پارامتر Remote Config باید به‌روزرسانی شود. معیارهای هدف‌یابی که هنگام ایجاد آزمایش تعریف شده‌اند، به‌عنوان یک شرط جدید در الگوی شما اضافه می‌شوند تا اطمینان حاصل شود که عرضه فقط بر کاربران هدف آزمایش تأثیر می‌گذارد. پس از کلیک بر روی Review in Remote Config برای بررسی تغییرات، روی انتشار تغییرات کلیک کنید تا عرضه کامل شود.
    • برای آزمایش In-App Messaging ، از کادر گفتگو برای تعیین اینکه کدام نوع باید به‌عنوان یک کمپین In-App Messaging مستقل عرضه شود، استفاده کنید. پس از انتخاب، به صفحه نوشتن FIAM هدایت می شوید تا قبل از انتشار هرگونه تغییری (در صورت لزوم) ایجاد کنید.

یک آزمایش را گسترش دهید

اگر متوجه شدید که آزمایشی کاربران کافی برای A/B Testing برای اعلام یک رهبر وارد نمی‌کند، می‌توانید توزیع آزمایش خود را افزایش دهید تا به درصد بیشتری از پایگاه کاربر برنامه برسید.

  1. در بخش Engage از منوی پیمایش کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. آزمایش در حال اجرا را که می خواهید ویرایش کنید انتخاب کنید.
  3. در نمای کلی آزمایش ، روی منوی زمینه ( ) و سپس ویرایش آزمایش در حال اجرا را کلیک کنید.
  4. گفتگوی Targeting گزینه ای را برای افزایش درصد کاربرانی که در آزمایش در حال اجرا هستند نمایش می دهد. عددی بزرگتر از درصد فعلی را انتخاب کنید و روی انتشار کلیک کنید. آزمایش به درصد کاربرانی که مشخص کرده‌اید منتقل می‌شود.

یک آزمایش را کپی یا متوقف کنید

  1. در بخش Engage از منوی پیمایش کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. روی Completed یا Running کلیک کنید، نشانگر را روی آزمایش خود نگه دارید، روی منوی زمینه ( ) کلیک کنید و سپس روی آزمایش تکراری یا توقف آزمایش کلیک کنید.

هدف گذاری کاربر

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

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

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

هنگام استفاده از عملگر contain regex ، می توانید عبارات منظم در قالب RE2 ایجاد کنید. عبارت منظم شما می تواند با تمام یا بخشی از رشته نسخه هدف مطابقت داشته باشد. همچنین می‌توانید از لنگرهای ^ و $ برای مطابقت با شروع، پایان یا کل یک رشته هدف استفاده کنید.

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

برای Remote Config ، این بدان معناست که حتی اگر کاربر از نظر فنی واجد شرایط یک مخاطب باشد، اگر Analytics هنوز کاربر را به هنگام اجرای «fetchAndActivate()» به مخاطب اضافه نکرده باشد، کاربر در آزمایش گنجانده نخواهد شد.

دارایی کاربر برای متن:
حاوی،
شامل نمی شود،
دقیقا مطابقت دارد
حاوی regex است

برای اعداد:
<، ≤، =، ≥، >
ویژگی کاربر Analytics برای انتخاب کاربرانی که ممکن است در یک آزمایش گنجانده شوند، با طیف وسیعی از گزینه‌ها برای انتخاب مقادیر ویژگی کاربر استفاده می‌شود.

در کلاینت، می توانید فقط مقادیر رشته ای را برای ویژگی های کاربر تنظیم کنید. برای شرایطی که از عملگرهای عددی استفاده می کنند، سرویس Remote Config مقدار ویژگی کاربر مربوطه را به یک عدد صحیح/فلوت تبدیل می کند.
هنگام استفاده از عملگر contain regex ، می توانید عبارات منظم در قالب RE2 ایجاد کنید. عبارت منظم شما می تواند با تمام یا بخشی از رشته نسخه هدف مطابقت داشته باشد. همچنین می‌توانید از لنگرهای ^ و $ برای مطابقت با شروع، پایان یا کل یک رشته هدف استفاده کنید.
کشور/منطقه N/A یک یا چند کشور یا منطقه برای انتخاب کاربرانی که ممکن است در آزمایش گنجانده شوند استفاده می شود.
زبان ها N/A یک یا چند زبان و منطقه برای انتخاب کاربرانی که ممکن است در آزمایش گنجانده شوند استفاده می شود.
ابتدا باز کنید قبل از
بعد از

کاربران را بر اساس اولین باری که برنامه شما را باز می کنند، هدف قرار دهید:

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

پس از انتخاب یک برنامه Android یا iOS، هدف‌گیری کاربر با اولین باز شدن در دسترس است. در حال حاضر توسط نسخه‌های Remote Config SDK زیر پشتیبانی می‌شود: پلتفرم‌های Apple SDK v9.0.0+ و Android SDK v21.1.1+ ( Firebase BoM v30.3.0+).

Analytics همچنین باید در اولین رویداد باز روی مشتری فعال شده باشد.

معیارهای A/B Testing

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

برای مثال، فرض کنید از Remote Config برای راه‌اندازی دو جریان بازی مختلف در برنامه‌تان استفاده می‌کنید و می‌خواهید برای خریدهای درون‌برنامه‌ای و درآمد تبلیغاتی بهینه‌سازی کنید، اما همچنین می‌خواهید پایداری و حفظ کاربر هر نسخه را دنبال کنید. در این مورد، می‌توانید درآمد کل تخمینی را به‌عنوان معیار هدف خود انتخاب کنید زیرا شامل درآمد خرید درون‌برنامه و درآمد تبلیغاتی می‌شود، و سپس، برای ردیابی سایر معیارها ، می‌توانید موارد زیر را اضافه کنید:

  • برای پیگیری حفظ روزانه و هفتگی کاربر خود، Retention (2-3 روز) و Retention (4-7 روز) را اضافه کنید.
  • برای مقایسه ثبات بین دو جریان بازی، کاربران بدون خرابی را اضافه کنید.
  • برای مشاهده نماهای دقیق تر از هر نوع درآمد، درآمد خرید و درآمد تخمینی تبلیغات را اضافه کنید.

جداول زیر جزئیاتی در مورد نحوه محاسبه معیارهای هدف و سایر معیارها ارائه می دهد.

معیارهای هدف

متریک توضیحات
کاربران بدون خرابی درصد کاربرانی که در طول آزمایش با خطاهایی در برنامه شما مواجه نشده‌اند که توسط Firebase Crashlytics SDK شناسایی شده است.
درآمد تخمینی تبلیغات درآمد تخمینی تبلیغات
کل درآمد تخمینی ارزش ترکیبی برای خرید و درآمد تخمینی تبلیغات.
درآمد خرید ارزش ترکیبی برای همه رویدادهای purchase و in_app_purchase .
نگهداری (1 روز) تعداد کاربرانی که به صورت روزانه به برنامه شما باز می گردند.
نگهداری (2-3 روز) تعداد کاربرانی که ظرف 2 تا 3 روز به برنامه شما بازگشته اند.
نگهداری (4-7 روز) تعداد کاربرانی که ظرف 4 تا 7 روز به برنامه شما بازگشته اند.
نگهداری (8-14 روز) تعداد کاربرانی که ظرف 8 تا 14 روز به برنامه شما بازگشته اند.
نگهداری (بیش از 15 روز) تعداد کاربرانی که 15 روز یا بیشتر پس از آخرین استفاده از برنامه شما به آن بازگشته اند.
first_open یک رویداد Analytics که وقتی کاربر برای اولین بار یک برنامه را پس از نصب یا نصب مجدد آن باز می کند، فعال می شود. به عنوان بخشی از یک قیف تبدیل استفاده می شود.

سایر معیارها

متریک توضیحات
notification_dismiss یک رویداد Analytics که وقتی اعلان ارسال شده توسط سازنده Notifications رد می‌شود (فقط Android) فعال می‌شود.
notification_receive یک رویداد Analytics که هنگام دریافت اعلان ارسال شده توسط Notifications Composer در حالی که برنامه در پس‌زمینه است (فقط اندروید) شروع می‌شود.
os_update یک رویداد Analytics که زمان به‌روزرسانی سیستم عامل دستگاه به نسخه جدید را ردیابی می‌کند. برای اطلاعات بیشتر، رویدادهای جمع‌آوری شده خودکار را ببینید.
screen_view یک رویداد Analytics که صفحه‌های مشاهده شده در برنامه شما را ردیابی می‌کند. برای کسب اطلاعات بیشتر، ردیابی نماهای صفحه را ببینید.
جلسه_شروع یک رویداد Analytics که جلسات کاربر را در برنامه شما شمارش می کند. برای کسب اطلاعات بیشتر، به رویدادهای جمع آوری خودکار مراجعه کنید.

صادرات داده 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 را باز کنید، که می توانید با استفاده از > تنظیمات پروژه در کنسول 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
،

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

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

برای انواع ویژگی های تست A/B با خط مبنا، موارد زیر را انجام دهید:

  1. آزمایش خود را ایجاد کنید
  2. آزمایش خود را روی دستگاه آزمایشی تأیید کنید.
  3. آزمایش خود را مدیریت کنید

یک آزمایش ایجاد کنید

آزمایش Remote Config به شما امکان می‌دهد چندین نوع را روی یک یا چند پارامتر Remote Config ارزیابی کنید.

  1. به کنسول Firebase وارد شوید و بررسی کنید که Google Analytics در پروژه شما فعال است تا آزمایش به داده های Analytics دسترسی داشته باشد.

    اگر Google Analytics هنگام ایجاد پروژه خود فعال نکرده اید، می توانید آن را در برگه Integrations فعال کنید، که می توانید با استفاده از > تنظیمات پروژه در کنسول Firebase به آن دسترسی داشته باشید.

  2. در بخش Engage از منوی پیمایش کنسول Firebase ، روی A/B Testing کلیک کنید.

  3. روی ایجاد آزمایش کلیک کنید و سپس هنگامی که از سرویسی که می خواهید آزمایش کنید از شما خواسته شد Remote Config را انتخاب کنید.

  4. یک نام و توضیحات اختیاری برای آزمایش خود وارد کنید و روی Next کلیک کنید.

  5. فیلدهای Targeting را پر کنید، ابتدا برنامه ای را انتخاب کنید که از آزمایش شما استفاده می کند. همچنین می‌توانید زیرمجموعه‌ای از کاربران خود را برای شرکت در آزمایش خود با کلیک کردن و سپس انتخاب گزینه‌هایی از لیست زیر هدف قرار دهید:

    • نسخه: یک یا چند نسخه از برنامه شما
    • شماره ساخت: کد نسخه برنامه
    • زبان‌ها: یک یا چند زبان و منطقه مورد استفاده برای انتخاب کاربرانی که ممکن است در آزمایش گنجانده شوند
    • کشور/منطقه: یک یا چند کشور یا منطقه برای انتخاب کاربرانی که باید در آزمایش گنجانده شوند
    • مخاطبان کاربر: مخاطبان Analytics برای هدف قرار دادن کاربرانی که ممکن است در آزمایش گنجانده شوند استفاده می شود
    • ویژگی کاربر: یک یا چند ویژگی کاربر Analytics برای انتخاب کاربرانی که ممکن است در آزمایش گنجانده شوند
    • اولین باز: کاربران را بر اساس اولین باری که برنامه شما را باز کرده اند مورد هدف قرار دهید

      پس از انتخاب یک برنامه Android یا iOS، هدف‌گیری کاربر بر اساس اولین زمان باز در دسترس است. توسط نسخه‌های Remote Config SDK زیر پشتیبانی می‌شود: پلتفرم‌های Apple SDK v9.0.0+ و Android SDK v21.1.1+ ( Firebase BoM v30.3.0+).

      Analytics همچنین باید در اولین رویداد باز روی مشتری فعال شده باشد.

  6. تنظیم درصد کاربران هدف: درصدی از پایگاه کاربر برنامه خود را وارد کنید که با معیارهای تعیین شده در زیر کاربران هدف مطابقت دارد که می‌خواهید به طور مساوی بین خط مبنا و یک یا چند نوع در آزمایش خود تقسیم کنید. این می تواند هر درصدی بین 0.01٪ و 100٪ باشد. کاربران به طور تصادفی به هر آزمایش، از جمله آزمایش‌های تکراری، اختصاص داده می‌شوند.

  7. در صورت تمایل، یک رویداد فعال‌سازی تنظیم کنید تا مطمئن شوید که فقط داده‌های کاربرانی که برای اولین بار برخی رویدادهای Analytics را راه‌اندازی کرده‌اند در آزمایش شما شمارش می‌شوند. توجه داشته باشید که همه کاربرانی که با پارامترهای هدف شما مطابقت دارند مقادیر آزمایشی Remote Config را دریافت خواهند کرد، اما فقط کسانی که یک رویداد فعال‌سازی را راه‌اندازی می‌کنند در نتایج آزمایش شما لحاظ می‌شوند.

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

    • app_install
    • app_remove
    • app_update
    • dynamic_link_first_open
  8. برای اهداف آزمایش، معیار اصلی را برای ردیابی انتخاب کنید، و هر معیار دیگری را که می‌خواهید ردیابی کنید از فهرست اضافه کنید. اینها شامل اهداف داخلی (خرید، درآمد، حفظ، کاربران بدون خرابی و غیره)، رویدادهای تبدیل Analytics و سایر رویدادهای Analytics است. پس از اتمام، روی Next کلیک کنید.

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

  10. (اختیاری) برای افزودن بیش از یک نوع به آزمایش خود، روی افزودن یک نوع دیگر کلیک کنید.

  11. یک یا چند پارامتر را برای انواع خاص تغییر دهید. هر پارامتر بدون تغییر برای کاربرانی که در آزمایش گنجانده نشده اند یکسان است.

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

  13. برای ذخیره آزمایش خود، روی Review کلیک کنید.

شما مجاز به 300 آزمایش در هر پروژه هستید که می تواند شامل حداکثر 24 آزمایش در حال اجرا باشد و بقیه به صورت پیش نویس یا تکمیل شده باشد.

آزمایش خود را روی دستگاه آزمایشی تأیید کنید

برای هر نصب Firebase، می‌توانید نشانه تأیید اعتبار نصب مرتبط با آن را بازیابی کنید. با نصب برنامه خود می توانید از این نشانه برای آزمایش انواع آزمایش خاص در یک دستگاه تست استفاده کنید. برای اعتبارسنجی آزمایش خود در یک دستگاه آزمایش ، موارد زیر را انجام دهید:

  1. نصب Auth را به شرح زیر دریافت کنید:
    do {
      let result = try await Installations.installations()
        .authTokenForcingRefresh(true)
      print("Installation auth token: \(result.authToken)")
    } catch {
      print("Error fetching token: \(error)")
    }
    [[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]);
    }];
    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");
            }
        }
    });
    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")
            }
        }
    firebase::InitResult init_result;
    auto* installations_object = firebase::installations::Installations::GetInstance(
        firebase::App::GetInstance(), &init_result);
    installations_object->GetToken().OnCompletion(
        [](const firebase::Future<std::string>& future) {
          if (future.status() == kFutureStatusComplete &&
              future.error() == firebase::installations::kErrorNone) {
            printf("Installations Auth Token %s\n", future.result()->c_str());
          }
        });
    Firebase.Installations.FirebaseInstallations.DefaultInstance.GetTokenAsync(forceRefresh: true).ContinueWith(
      task => {
        if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
          UnityEngine.Debug.Log(System.String.Format("Installations token {0}", task.Result));
        }
      });
  2. در نوار ناوبری کنسول Firebase ، روی آزمایش A/B کلیک کنید.
  3. روی پیش نویس (و/یا اجرای آزمایش های پیکربندی از راه دور) کلیک کنید ، روی آزمایش خود حرکت کنید ، روی منوی زمینه ( ) کلیک کنید و سپس روی مدیریت دستگاه های تست کلیک کنید.
  4. برای یک دستگاه تست ، توکن Auth را وارد کنید و نوع آزمایش را برای ارسال به آن دستگاه تست انتخاب کنید.
  5. برنامه را اجرا کنید و تأیید کنید که نوع انتخاب شده در دستگاه تست دریافت می شود.

برای کسب اطلاعات بیشتر در مورد تاسیسات Firebase ، به مدیریت نصب Firebase مراجعه کنید.

آزمایش خود را مدیریت کنید

این که آیا شما آزمایشی را با Remote Config ، آهنگساز اعلان ها یا Firebase In-App Messaging ایجاد کرده اید ، می توانید سپس آزمایش خود را تأیید کرده و شروع کنید ، آزمایش خود را در حالی که در حال اجرا است نظارت کنید و تعداد کاربران موجود در آزمایش در حال اجرا را افزایش دهید.

هنگامی که آزمایش شما انجام شد ، می توانید به تنظیمات مورد استفاده در نوع برنده توجه داشته باشید و سپس آن تنظیمات را برای همه کاربران جمع کنید. یا می توانید آزمایش دیگری را انجام دهید.

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

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. روی پیش نویس کلیک کنید ، و سپس بر روی عنوان آزمایش خود کلیک کنید.
  3. برای تأیید اینکه برنامه شما دارای کاربرانی است که در آزمایش شما گنجانده شده اند ، پیش نویس جزئیات را گسترش داده و تعداد بیشتری از 0 ٪ را در بخش هدفگذاری و توزیع بررسی می کنند (به عنوان مثال ، 1 ٪ کاربران مطابق با معیارها ).
  4. برای تغییر آزمایش خود ، روی ویرایش کلیک کنید.
  5. برای شروع آزمایش خود ، روی شروع آزمایش کلیک کنید. شما می توانید حداکثر 24 آزمایش در هر پروژه را به طور همزمان انجام دهید.

نظارت بر یک آزمایش

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

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. روی Running کلیک کنید و سپس بر روی عنوان آزمایش خود کلیک کنید یا جستجو کنید. در این صفحه ، می توانید آمار مختلف مشاهده شده و مدل شده در مورد آزمایش در حال اجرا خود را مشاهده کنید ، از جمله موارد زیر:

    • اختلاف ٪ از پایه : اندازه گیری بهبود یک متریک برای یک نوع معین در مقایسه با پایه. با مقایسه دامنه مقدار برای نوع با دامنه مقدار برای پایه محاسبه می شود.
    • احتمال ضرب و شتم پایه : احتمال تخمین زده شده که یک نوع خاص پایه را برای متریک انتخاب شده ضرب می کند.
    • observed_metric برای هر کاربر : بر اساس نتایج آزمایش ، این محدوده پیش بینی شده است که مقدار متریک با گذشت زمان به آن می رسد.
    • کل observed_metric : مقدار تجمعی مشاهده شده برای پایه یا نوع. از این مقدار برای اندازه گیری چگونگی عملکرد هر نوع آزمایش استفاده می شود و برای محاسبه بهبود ، دامنه ارزش ، احتمال ضرب و شتم پایه و احتمال بهترین نوع استفاده می شود. بسته به اندازه گیری متریک ، این ستون ممکن است با عنوان "مدت زمان در کاربر" ، "درآمد برای هر کاربر" ، "نرخ نگهداری" یا "نرخ تبدیل" برچسب گذاری شود.
  3. بعد از اینکه آزمایش شما برای مدتی اجرا شد (حداقل 7 روز برای پیام رسانی FCM و In-App Messaging یا 14 روز برای Remote Config ) ، داده های موجود در این صفحه نشان می دهد که در صورت وجود کدام نوع ، "رهبر" است. برخی از اندازه گیری ها با یک نمودار نوار همراه هستند که داده ها را با فرمت بصری ارائه می دهد.

آزمایشی را برای همه کاربران انجام دهید

بعد از اینکه یک آزمایش به اندازه کافی طولانی انجام شد که شما یک "رهبر" یا نوع برنده دارید ، برای معیار هدف خود ، می توانید این آزمایش را به 100 ٪ از کاربران آزاد کنید. این به شما امکان می دهد یک نوع را برای انتشار برای همه کاربرانی که به جلو حرکت می کنند ، انتخاب کنید. حتی اگر آزمایش شما یک برنده واضح ایجاد نکرده باشد ، هنوز هم می توانید یک نوع را برای همه کاربران خود منتشر کنید.

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. بر روی تکمیل یا اجرا کلیک کنید ، روی آزمایشی که می خواهید برای همه کاربران منتشر کنید ، کلیک کنید ، بر روی منوی Context ( ) Roll Out کلیک کنید.
  3. با انجام یکی از موارد زیر ، آزمایش خود را به همه کاربران منتقل کنید:

    • برای آزمایشی که از آهنگساز Notifications استفاده می کند ، از گفتگوی پیام Roll Out استفاده کنید تا پیام را به کاربران هدفمند باقیمانده که جزئی از این آزمایش نبودند ، ارسال کنید.
    • برای یک آزمایش Remote Config ، یک نوع را انتخاب کنید تا تعیین کنید که مقادیر پارامتر Remote Config برای به روزرسانی چیست. معیارهای هدفمند که هنگام ایجاد آزمایش تعریف شده است به عنوان یک شرایط جدید در الگوی شما اضافه می شود ، تا اطمینان حاصل شود که این روند فقط بر کاربران مورد هدف آزمایش تأثیر می گذارد. پس از کلیک بر روی بررسی در Remote Config برای بررسی تغییرات ، روی انتشار تغییرات کلیک کنید تا بتوانید Rollout را تکمیل کنید.
    • برای یک آزمایش In-App Messaging ، از گفتگو استفاده کنید تا مشخص کنید کدام نوع باید به عنوان یک کمپین In-App Messaging مستقل انجام شود. پس از انتخاب ، شما به صفحه نمایش FIAM هدایت می شوید تا قبل از انتشار هرگونه تغییر (در صورت لزوم) ایجاد کنید.

یک آزمایش را گسترش دهید

اگر فهمیدید که یک آزمایش به اندازه کافی کاربران را برای A/B Testing برای اعلام یک رهبر وارد نمی کند ، می توانید توزیع آزمایش خود را افزایش دهید تا به درصد بیشتری از پایگاه کاربر برنامه برسید.

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. آزمایش در حال اجرا را که می خواهید ویرایش کنید انتخاب کنید.
  3. در بررسی اجمالی آزمایش ، روی منوی زمینه ( ) کلیک کنید و سپس روی Edit Running Experiment کلیک کنید.
  4. گفتگوی هدفمند گزینه ای را برای افزایش درصد کاربرانی که در آزمایش در حال اجرا هستند ، نشان می دهد. یک عدد بیشتر از درصد فعلی را انتخاب کرده و روی انتشار کلیک کنید. این آزمایش به درصد کاربرانی که شما مشخص کرده اید منتقل می شود.

کپی یا متوقف کردن یک آزمایش

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. بر روی تکمیل یا اجرای ، کلیک کنید ، نشانگر را روی آزمایش خود نگه دارید ، بر روی منوی زمینه ( ) کلیک کنید و سپس روی آزمایش کپی یا آزمایش Stop کلیک کنید.

هدف گیری کاربر

شما می توانید کاربران را هدف قرار دهید تا با استفاده از معیارهای هدف گیری کاربر زیر ، آزمایش خود را در آزمایش خود قرار دهند.

معیار هدفمند اپراتور(های) ارزش(های) توجه داشته باشید
نسخه حاوی،
حاوی نیست ،
دقیقاً مطابقت دارد ،
حاوی regex است
برای یک یا چند نسخه برنامه که می خواهید در آزمایش قرار دهید ، یک مقدار را وارد کنید.

هنگام استفاده از هر یک از این موارد ، حاوی ، یا دقیقاً با اپراتورها مطابقت ندارد ، می توانید یک لیست از مقادیر جدا از کاما تهیه کنید.

هنگام استفاده از اپراتور REGEX ، می توانید عبارات منظم را با فرمت RE2 ایجاد کنید. بیان منظم شما می تواند با تمام یا بخشی از رشته نسخه هدف مطابقت داشته باشد. همچنین می توانید از لنگرهای ^ و $ برای مطابقت با ابتدا ، پایان یا کلیت یک رشته هدف استفاده کنید.

مخاطبان (های) کاربر شامل همه ،
شامل حداقل یکی از ،
شامل همه ،
حداقل یکی از آنها را شامل نمی شود
برای هدف قرار دادن کاربرانی که ممکن است در آزمایش شما گنجانده شوند ، یک یا چند مخاطب Analytics را انتخاب کنید. برخی از آزمایشاتی که مخاطبان Google Analytics را هدف قرار می دهند ممکن است چند روز برای جمع آوری داده ها نیاز داشته باشند زیرا آنها در معرض تأخیر پردازش داده های Analytics قرار دارند. شما به احتمال زیاد با کاربران جدید ، که به طور معمول 24-48 ساعت پس از ایجاد یا برای مخاطبان اخیراً ایجاد شده اند ، با این تأخیر روبرو می شوید.

برای Remote Config ، این بدان معنی است که حتی اگر یک کاربر از نظر فنی برای مخاطب واجد شرایط باشد ، اگر Analytics هنوز کاربر را به مخاطب اضافه نکرده باشد وقتی "FetchandActivate ()" اجرا می شود ، کاربر در آزمایش قرار نمی گیرد.

دارایی کاربر برای متن:
حاوی،
حاوی نیست ،
دقیقاً مطابقت دارد ،
حاوی regex است

برای اعداد:
<، ≤ ، = ، ≥ ،>
یک ویژگی کاربر Analytics برای انتخاب کاربرانی که ممکن است در یک آزمایش گنجانده شوند ، با طیف وسیعی از گزینه ها برای انتخاب مقادیر خاصیت کاربر استفاده می شود.

در مشتری ، می توانید فقط مقادیر رشته ای را برای خصوصیات کاربر تنظیم کنید. برای شرایطی که از اپراتورهای عددی استفاده می کنند ، سرویس Remote Config مقدار خاصیت کاربر مربوطه را به یک عدد صحیح/شناور تبدیل می کند.
هنگام استفاده از اپراتور REGEX ، می توانید عبارات منظم را با فرمت RE2 ایجاد کنید. بیان منظم شما می تواند با تمام یا بخشی از رشته نسخه هدف مطابقت داشته باشد. همچنین می توانید از لنگرهای ^ و $ برای مطابقت با ابتدا ، پایان یا کلیت یک رشته هدف استفاده کنید.
کشور/منطقه N/A یک یا چند کشور یا منطقه ای که برای انتخاب کاربرانی که ممکن است در این آزمایش گنجانده شوند استفاده می شود.
زبان ها N/A یک یا چند زبان و محلی برای انتخاب کاربرانی که ممکن است در این آزمایش گنجانده شوند استفاده می شود.
اول باز قبل از
بعد از

کاربران را بر اساس اولین باری که برنامه شما را باز می کنند هدف قرار دهید:

  • کاربران جدید را برای هدف قرار دادن کاربرانی که ابتدا برنامه شما را پس از تاریخ و زمان مشخص آینده باز می کنند انتخاب کنید.
  • محدوده زمانی را برای هدف قرار دادن کاربرانی که ابتدا برنامه شما را در محدوده قبل یا بعد از تاریخ و زمان مشخص شده باز می کنند ، انتخاب کنید. قبل و بعد از شرایط را برای هدف قرار دادن کاربران در یک محدوده زمانی خاص ترکیب کنید.

هدف قرار دادن کاربر توسط First Open پس از انتخاب یک برنامه Android یا iOS در دسترس است. در حال حاضر توسط نسخه های Remote Config SDK زیر پشتیبانی می شود: Apple Platforms SDK V9.0.0+ و Android SDK V21.1.1+ ( Firebase BoM v30.3.0+).

Analytics نیز باید در اولین رویداد باز روی مشتری فعال شود.

معیارهای A/B Testing

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

به عنوان مثال ، بگویید که از Remote Config برای راه اندازی دو جریان بازی مختلف در برنامه خود استفاده می کنید و می خواهید برای خریدهای درون برنامه و درآمد AD بهینه سازی کنید ، اما همچنین می خواهید ثبات و حفظ کاربر هر نوع را پیگیری کنید. در این حالت ، شما ممکن است انتخاب کل تخمین زده شده را به عنوان متریک هدف خود در نظر بگیرید زیرا این شامل درآمد خرید درون برنامه و درآمد AD است ، و سپس ، برای ردیابی سایر معیارها ، ممکن است موارد زیر را اضافه کنید:

  • برای ردیابی حفظ روزانه و هفتگی کاربر ، حفظ (2-3 روز) و نگهداری (4-7 روز) اضافه کنید.
  • برای مقایسه پایداری بین دو جریان بازی ، کاربران بدون تصادف را اضافه کنید.
  • برای دیدن نماهای دقیق تر از هر نوع درآمد ، درآمد خرید و درآمد آگهی تخمین زده شده را اضافه کنید.

جداول زیر جزئیات مربوط به چگونگی محاسبه معیارهای هدف و سایر معیارها را ارائه می دهد.

معیارهای هدف

متریک توضیحات
کاربران بدون خرابی درصد کاربرانی که در برنامه شما با خطایی روبرو نشده اند که در طول آزمایش توسط Firebase Crashlytics SDK شناسایی شده اند.
درآمد تبلیغاتی تخمین زده شده درآمد آگهی تخمین زده شده.
کل درآمد تخمینی ارزش ترکیبی برای خرید و درآمد آگهی تخمین زده شده.
درآمد خرید ارزش ترکیبی برای همه رویدادهای purchase و in_app_purchase .
احتباس (1 روز) تعداد کاربرانی که روزانه به برنامه شما باز می گردند.
احتباس (2-3 روز) تعداد کاربرانی که ظرف 2-3 روز به برنامه شما باز می گردند.
احتباس (4-7 روز) تعداد کاربرانی که طی 4-7 روز به برنامه شما باز می گردند.
احتباس (8-14 روز) تعداد کاربرانی که ظرف 8-14 روز به برنامه شما باز می گردند.
احتباس (15+ روز) تعداد کاربرانی که 15 یا بیشتر از آخرین استفاده از آن به برنامه شما باز می گردند.
اول_ش یک رویداد Analytics که باعث می شود وقتی کاربر برای اولین بار پس از نصب یا نصب مجدد آن ، یک برنامه را باز کند. به عنوان بخشی از قیف تبدیل استفاده می شود.

سایر معیارها

متریک توضیحات
notification_dismiss یک رویداد Analytics که باعث می شود هنگامی که اعلان ارسال شده توسط آهنگساز اعلان ها ارسال شود ، رد می شود (فقط اندروید).
NOTIFICIVE_RECEIVE یک رویداد Analytics که هنگام اعلان ارسال شده توسط آهنگساز اعلان ها در حالی که برنامه در پس زمینه است دریافت می شود (فقط Android).
os_update یک رویداد Analytics که هنگام به روزرسانی سیستم عامل دستگاه به نسخه جدید ، ردیابی می کند. برای کسب اطلاعات بیشتر ، به رویدادهای جمع آوری شده خودکار مراجعه کنید.
نمای_ نمایشگر یک رویداد Analytics که صفحه نمایش های مشاهده شده در برنامه شما را ردیابی می کند. برای کسب اطلاعات بیشتر ، به صفحه نمایش ScreenViews مراجعه کنید.
جلسه_شروع یک رویداد Analytics که جلسات کاربر را در برنامه شما حساب می کند. برای کسب اطلاعات بیشتر ، به وقایع جمع آوری شده خودکار مراجعه کنید.

صادرات داده های 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. Export BigQuery را برای Google Analytics در کنسول Firebase فعال کنید
  2. دسترسی به داده های A/B Testing با استفاده از BigQuery
  3. نمایش داده های مثال را کاوش کنید

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

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

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

  1. برگه Integrations را باز کنید که می توانید با استفاده از > تنظیمات پروژه در کنسول Firebase به آن دسترسی پیدا کنید.
  2. اگر در حال حاضر از BigQuery با سایر خدمات Firebase استفاده می کنید ، روی مدیریت کلیک کنید. در غیر این صورت ، روی پیوند کلیک کنید.
  3. بررسی در مورد پیوند Firebase به BigQuery ، سپس روی Next کلیک کنید.
  4. در بخش ادغام پیکربندی ، ضامن Google Analytics را فعال کنید.
  5. یک منطقه را انتخاب کنید و تنظیمات صادرات را انتخاب کنید.

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

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

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

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

  • آزمایش آزمایش: می توانید این مورد را از URL صفحه نمای کلی آزمایش بدست آورید. به عنوان مثال ، اگر URL شما مانند 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. پروژه خود را انتخاب کنید ، سپس ایجاد SQL Query را انتخاب کنید.
  3. درخواست خود را اضافه کنید به عنوان مثال پرس و جو برای اجرای ، به نمایش داده های نمونه کاوش مراجعه کنید.
  4. روی Run کلیک کنید.

داده های آزمایش پرس و جو با استفاده از پرس و جو تولید شده توسط کنسول Firebase

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

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

  1. از کنسول Firebase ، A/B Testing باز کنید و آزمایش A/B Testing که می خواهید برای باز کردن نمای کلی آزمایش کنید انتخاب کنید.
  2. از منوی گزینه ها ، در زیر ادغام BigQuery ، داده های آزمایش پرس و جو را انتخاب کنید. این پروژه شما را در BigQuery در کنسول کنسول Google Cloud باز می کند و یک پرس و جو اساسی را که می توانید برای پرس و جو از داده های آزمایش خود استفاده کنید ، ارائه می دهد.

مثال زیر یک پرس و جو تولید شده برای آزمایش با سه نوع (از جمله پایه) به نام "آزمایش خوش آمدید زمستان" را نشان می دهد. این نام آزمایش فعال ، نام متفاوت ، رویداد منحصر به فرد و شمارش رویداد را برای هر رویداد برمی گرداند. توجه داشته باشید که سازنده Query نام پروژه شما را در نام جدول مشخص نمی کند ، زیرا مستقیماً در پروژه شما باز می شود.

  /*
    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
،

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

  • بهترین راه برای اجرای یک ویژگی برای بهینه سازی تجربه کاربر. غالباً ، توسعه دهندگان برنامه نمی آموزند که کاربران خود از ویژگی جدید یا تجربه کاربر به روز شده تا زمانی که رتبه برنامه خود در فروشگاه برنامه کاهش یابد ، دوست ندارند. آزمایش A/B می تواند به اندازه گیری اینکه کاربران شما انواع مختلفی از ویژگی ها را دوست دارند ، کمک کند یا اینکه آیا آنها برنامه را به عنوان موجود ترجیح می دهند. بعلاوه ، نگه داشتن بیشتر کاربران خود در یک گروه پایه تضمین می کند که بیشتر پایگاه کاربر شما می تواند بدون تجربه تغییر در رفتار یا ظاهر آن ، تا زمان نتیجه گیری آزمایش ، از برنامه شما استفاده کند.
  • بهترین راه برای بهینه سازی تجربه کاربر برای یک هدف تجاری. بعضی اوقات شما در حال اجرای تغییرات محصول برای به حداکثر رساندن یک متریک مانند درآمد یا حفظ هستید. با آزمایش A/B ، شما هدف کسب و کار خود را تعیین می کنید ، و Firebase تجزیه و تحلیل آماری را انجام می دهد تا مشخص کند که آیا یک نوع از پایه برای هدف انتخاب شده شما بهتر است یا خیر.

به انواع ویژگی های تست A/B با یک پایه ، موارد زیر را انجام دهید:

  1. آزمایش خود را ایجاد کنید.
  2. آزمایش خود را در یک دستگاه آزمایشی تأیید کنید.
  3. آزمایش خود را مدیریت کنید.

یک آزمایش ایجاد کنید

یک آزمایش Remote Config به شما امکان می دهد انواع مختلف را در یک یا چند پارامتر Remote Config ارزیابی کنید.

  1. وارد کنسول Firebase شوید و تأیید کنید که Google Analytics در پروژه شما فعال شده است تا آزمایش به داده های Analytics دسترسی داشته باشد.

    اگر هنگام ایجاد پروژه خود Google Analytics را فعال نکردید ، می توانید آن را در برگه Integrations فعال کنید که می توانید با استفاده از > تنظیمات پروژه در کنسول Firebase به آن دسترسی پیدا کنید.

  2. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.

  3. بر روی ایجاد آزمایش کلیک کنید و سپس از طریق سرویس دهی که می خواهید با آن آزمایش کنید ، Remote Config انتخاب کنید.

  4. یک نام و توضیحات اختیاری را برای آزمایش خود وارد کنید و روی Next کلیک کنید.

  5. قسمتهای هدفمند را پر کنید ، ابتدا برنامه ای را که از آزمایش شما استفاده می کند انتخاب کنید. همچنین می توانید زیر مجموعه ای از کاربران خود را برای شرکت در آزمایش خود با کلیک کردن و سپس انتخاب گزینه ها از لیست زیر هدف قرار دهید:

    • نسخه: یک یا چند نسخه از برنامه شما
    • شماره ساخت: کد نسخه برنامه
    • زبانها: یک یا چند زبان و محلی برای انتخاب کاربرانی که ممکن است در این آزمایش گنجانده شوند استفاده می شوند
    • کشور/منطقه: یک یا چند کشور یا منطقه برای انتخاب کاربرانی که باید در این آزمایش گنجانده شوند
    • مخاطبان کاربر: مخاطبان Analytics که برای هدف قرار دادن کاربرانی که ممکن است در این آزمایش قرار بگیرند استفاده می شود
    • خاصیت کاربر: یک یا چند ویژگی کاربر Analytics برای انتخاب کاربرانی که ممکن است در این آزمایش گنجانده شوند
    • First Open: کاربران هدف را بر اساس اولین باری که برنامه شما را باز کرده اند

      هدف قرار دادن کاربر توسط اولین زمان باز پس از انتخاب یک برنامه Android یا iOS در دسترس است. این نسخه توسط نسخه های SDK Remote Config زیر پشتیبانی می شود: سیستم عامل های اپل SDK v9.0.0+ و Android SDK V21.1.1+ ( Firebase BoM v30.3.0+).

      Analytics نیز باید در اولین رویداد باز روی مشتری فعال شود.

  6. درصد کاربران هدف را تنظیم کنید: درصد از پایه کاربر برنامه خود را متناسب با معیارهای تعیین شده در زیر کاربران هدف که می خواهید به طور مساوی بین پایه و یک یا چند نوع در آزمایش خود تقسیم کنید ، وارد کنید. این می تواند هر درصد بین 0.01 ٪ تا 100 ٪ باشد. کاربران به طور تصادفی به هر آزمایش ، از جمله آزمایش های تکراری اختصاص داده می شوند.

  7. به صورت اختیاری ، یک رویداد فعال سازی را تنظیم کنید تا اطمینان حاصل شود که فقط داده های کاربرانی که برای اولین بار برخی از رویدادهای Analytics ایجاد کرده اند در آزمایش شما شمارش می شوند. توجه داشته باشید که کلیه کاربران مطابق پارامترهای هدفمند شما مقادیر آزمایشی Remote Config را دریافت می کنند ، اما فقط کسانی که یک رویداد فعال سازی را ایجاد می کنند در نتایج آزمایش شما گنجانده می شوند.

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

    • app_install
    • app_remove
    • app_update
    • dynamic_link_first_open
  8. برای اهداف آزمایش ، متریک اصلی را برای ردیابی انتخاب کنید و معیارهای اضافی را که می خواهید از لیست ردیابی کنید ، اضافه کنید. این موارد شامل اهداف داخلی (خریدها ، درآمد ، حفظ ، کاربران بدون تصادف و غیره) ، رویدادهای تبدیل Analytics و سایر رویدادهای Analytics است. پس از اتمام، روی Next کلیک کنید.

  9. در بخش Variants ، یک پایه و حداقل یک نوع برای آزمایش را انتخاب کنید. برای اضافه کردن یک یا چند پارامتر برای آزمایش از لیست انتخاب یا ایجاد جدید استفاده کنید. شما می توانید پارامتری را ایجاد کنید که قبلاً در کنسول Firebase مورد استفاده قرار نگرفته است ، اما باید در برنامه شما وجود داشته باشد تا بتواند تاثیری داشته باشد. می توانید این مرحله را تکرار کنید تا چندین پارامتر به آزمایش خود اضافه کنید.

  10. (اختیاری) برای اضافه کردن بیش از یک نوع به آزمایش خود ، روی اضافه کردن یک نوع دیگر کلیک کنید.

  11. یک یا چند پارامتر را برای انواع خاص تغییر دهید. هر پارامتر بدون تغییر برای کاربرانی که در آزمایش گنجانده نشده اند یکسان است.

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

  13. برای ذخیره آزمایش خود روی بررسی کلیک کنید.

به شما اجازه داده می شود تا 300 آزمایش در هر پروژه ، که می تواند شامل 24 آزمایش در حال اجرا باشد ، با بقیه به عنوان پیش نویس یا تکمیل شده باشد.

آزمایش خود را در یک دستگاه آزمایشی تأیید کنید

برای هر نصب Firebase ، می توانید توکن Auth را که در ارتباط با آن است ، بازیابی کنید. با نصب برنامه خود می توانید از این نشانه برای آزمایش انواع آزمایش خاص در یک دستگاه تست استفاده کنید. برای اعتبارسنجی آزمایش خود در یک دستگاه آزمایش ، موارد زیر را انجام دهید:

  1. نصب Auth را به شرح زیر دریافت کنید:
    do {
      let result = try await Installations.installations()
        .authTokenForcingRefresh(true)
      print("Installation auth token: \(result.authToken)")
    } catch {
      print("Error fetching token: \(error)")
    }
    [[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]);
    }];
    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");
            }
        }
    });
    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")
            }
        }
    firebase::InitResult init_result;
    auto* installations_object = firebase::installations::Installations::GetInstance(
        firebase::App::GetInstance(), &init_result);
    installations_object->GetToken().OnCompletion(
        [](const firebase::Future<std::string>& future) {
          if (future.status() == kFutureStatusComplete &&
              future.error() == firebase::installations::kErrorNone) {
            printf("Installations Auth Token %s\n", future.result()->c_str());
          }
        });
    Firebase.Installations.FirebaseInstallations.DefaultInstance.GetTokenAsync(forceRefresh: true).ContinueWith(
      task => {
        if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
          UnityEngine.Debug.Log(System.String.Format("Installations token {0}", task.Result));
        }
      });
  2. در نوار ناوبری کنسول Firebase ، روی آزمایش A/B کلیک کنید.
  3. روی پیش نویس (و/یا اجرای آزمایش های پیکربندی از راه دور) کلیک کنید ، روی آزمایش خود حرکت کنید ، روی منوی زمینه ( ) کلیک کنید و سپس روی مدیریت دستگاه های تست کلیک کنید.
  4. برای یک دستگاه تست ، توکن Auth را وارد کنید و نوع آزمایش را برای ارسال به آن دستگاه تست انتخاب کنید.
  5. برنامه را اجرا کنید و تأیید کنید که نوع انتخاب شده در دستگاه تست دریافت می شود.

برای کسب اطلاعات بیشتر در مورد تاسیسات Firebase ، به مدیریت نصب Firebase مراجعه کنید.

آزمایش خود را مدیریت کنید

این که آیا شما آزمایشی را با Remote Config ، آهنگساز اعلان ها یا Firebase In-App Messaging ایجاد کرده اید ، می توانید سپس آزمایش خود را تأیید کرده و شروع کنید ، آزمایش خود را در حالی که در حال اجرا است نظارت کنید و تعداد کاربران موجود در آزمایش در حال اجرا را افزایش دهید.

هنگامی که آزمایش شما انجام شد ، می توانید به تنظیمات مورد استفاده در نوع برنده توجه داشته باشید و سپس آن تنظیمات را برای همه کاربران جمع کنید. یا می توانید آزمایش دیگری را انجام دهید.

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

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. روی پیش نویس کلیک کنید ، و سپس بر روی عنوان آزمایش خود کلیک کنید.
  3. برای تأیید اینکه برنامه شما دارای کاربرانی است که در آزمایش شما گنجانده شده اند ، پیش نویس جزئیات را گسترش داده و تعداد بیشتری از 0 ٪ را در بخش هدفگذاری و توزیع بررسی می کنند (به عنوان مثال ، 1 ٪ کاربران مطابق با معیارها ).
  4. برای تغییر آزمایش خود ، روی ویرایش کلیک کنید.
  5. برای شروع آزمایش خود ، روی شروع آزمایش کلیک کنید. شما می توانید حداکثر 24 آزمایش در هر پروژه را به طور همزمان انجام دهید.

نظارت بر یک آزمایش

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

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. روی Running کلیک کنید و سپس بر روی عنوان آزمایش خود کلیک کنید یا جستجو کنید. در این صفحه ، می توانید آمار مختلف مشاهده شده و مدل شده در مورد آزمایش در حال اجرا خود را مشاهده کنید ، از جمله موارد زیر:

    • اختلاف ٪ از پایه : اندازه گیری بهبود یک متریک برای یک نوع معین در مقایسه با پایه. با مقایسه دامنه مقدار برای نوع با دامنه مقدار برای پایه محاسبه می شود.
    • احتمال ضرب و شتم پایه : احتمال تخمین زده شده که یک نوع خاص پایه را برای متریک انتخاب شده ضرب می کند.
    • observed_metric برای هر کاربر : بر اساس نتایج آزمایش ، این محدوده پیش بینی شده است که مقدار متریک با گذشت زمان به آن می رسد.
    • کل observed_metric : مقدار تجمعی مشاهده شده برای پایه یا نوع. از این مقدار برای اندازه گیری چگونگی عملکرد هر نوع آزمایش استفاده می شود و برای محاسبه بهبود ، دامنه ارزش ، احتمال ضرب و شتم پایه و احتمال بهترین نوع استفاده می شود. بسته به اندازه گیری متریک ، این ستون ممکن است با عنوان "مدت زمان در کاربر" ، "درآمد برای هر کاربر" ، "نرخ نگهداری" یا "نرخ تبدیل" برچسب گذاری شود.
  3. بعد از اینکه آزمایش شما برای مدتی اجرا شد (حداقل 7 روز برای پیام رسانی FCM و In-App Messaging یا 14 روز برای Remote Config ) ، داده های موجود در این صفحه نشان می دهد که در صورت وجود کدام نوع ، "رهبر" است. برخی از اندازه گیری ها با یک نمودار نوار همراه هستند که داده ها را با فرمت بصری ارائه می دهد.

آزمایشی را برای همه کاربران انجام دهید

بعد از اینکه یک آزمایش به اندازه کافی طولانی انجام شد که شما یک "رهبر" یا نوع برنده دارید ، برای معیار هدف خود ، می توانید این آزمایش را به 100 ٪ از کاربران آزاد کنید. این به شما امکان می دهد یک نوع را برای انتشار برای همه کاربرانی که به جلو حرکت می کنند ، انتخاب کنید. حتی اگر آزمایش شما یک برنده واضح ایجاد نکرده باشد ، هنوز هم می توانید یک نوع را برای همه کاربران خود منتشر کنید.

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. بر روی تکمیل یا اجرا کلیک کنید ، روی آزمایشی که می خواهید برای همه کاربران منتشر کنید ، کلیک کنید ، بر روی منوی Context ( ) Roll Out کلیک کنید.
  3. با انجام یکی از موارد زیر ، آزمایش خود را به همه کاربران منتقل کنید:

    • برای آزمایشی که از آهنگساز Notifications استفاده می کند ، از گفتگوی پیام Roll Out استفاده کنید تا پیام را به کاربران هدفمند باقیمانده که جزئی از این آزمایش نبودند ، ارسال کنید.
    • برای یک آزمایش Remote Config ، یک نوع را انتخاب کنید تا تعیین کنید که مقادیر پارامتر Remote Config برای به روزرسانی چیست. معیارهای هدفمند که هنگام ایجاد آزمایش تعریف شده است به عنوان یک شرایط جدید در الگوی شما اضافه می شود ، تا اطمینان حاصل شود که این روند فقط بر کاربران مورد هدف آزمایش تأثیر می گذارد. پس از کلیک بر روی بررسی در Remote Config برای بررسی تغییرات ، روی انتشار تغییرات کلیک کنید تا بتوانید Rollout را تکمیل کنید.
    • برای یک آزمایش In-App Messaging ، از گفتگو استفاده کنید تا مشخص کنید کدام نوع باید به عنوان یک کمپین In-App Messaging مستقل انجام شود. پس از انتخاب ، شما به صفحه نمایش FIAM هدایت می شوید تا قبل از انتشار هرگونه تغییر (در صورت لزوم) ایجاد کنید.

یک آزمایش را گسترش دهید

اگر فهمیدید که یک آزمایش به اندازه کافی کاربران را برای A/B Testing برای اعلام یک رهبر وارد نمی کند ، می توانید توزیع آزمایش خود را افزایش دهید تا به درصد بیشتری از پایگاه کاربر برنامه برسید.

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. آزمایش در حال اجرا را که می خواهید ویرایش کنید انتخاب کنید.
  3. در بررسی اجمالی آزمایش ، روی منوی زمینه ( ) کلیک کنید و سپس روی Edit Running Experiment کلیک کنید.
  4. گفتگوی هدفمند گزینه ای را برای افزایش درصد کاربرانی که در آزمایش در حال اجرا هستند ، نشان می دهد. یک عدد بیشتر از درصد فعلی را انتخاب کرده و روی انتشار کلیک کنید. این آزمایش به درصد کاربرانی که شما مشخص کرده اید منتقل می شود.

کپی یا متوقف کردن یک آزمایش

  1. در بخش Engage از منوی ناوبری کنسول Firebase ، روی A/B Testing کلیک کنید.
  2. بر روی تکمیل یا اجرای ، کلیک کنید ، نشانگر را روی آزمایش خود نگه دارید ، بر روی منوی زمینه ( ) کلیک کنید و سپس روی آزمایش کپی یا آزمایش Stop کلیک کنید.

هدف گیری کاربر

شما می توانید کاربران را هدف قرار دهید تا با استفاده از معیارهای هدف گیری کاربر زیر ، آزمایش خود را در آزمایش خود قرار دهند.

معیار هدفمند اپراتور(های) ارزش(های) توجه داشته باشید
نسخه حاوی،
حاوی نیست ،
matches exactly,
contains regex
Enter a value for one or more app versions that you want to include in the experiment.

When using any of the contains , does not contain , or matches exactly operators, you can provide a comma-separated list of values.

When using the contains regex operator, you can create regular expressions in RE2 format. Your regular expression can match all or part of the target version string. You can also use the ^ and $ anchors to match the beginning, end, or entirety of a target string.

User audience(s) includes all of,
includes at least one of,
does not include all of,
does not include at least one of
Select one or more Analytics audiences to target users who might be included in your experiment. Some experiments that target Google Analytics audiences may require a few days to accumulate data because they are subject to Analytics data processing latency . You are most likely to encounter this delay with new users, who are typically enrolled into qualifying audiences 24-48 hours after creation, or for recently-created audiences .

For Remote Config , this means that even if a user technically qualifies for an audience, if Analytics has not yet added the user to the audience when `fetchAndActivate()` is executed, the user will not be included in the experiment.

دارایی کاربر برای متن:
حاوی،
does not contain,
exactly matches,
contains regex

برای اعداد:
<, ≤, =, ≥, >
An Analytics user property is used to select users who might be included in an experiment, with a range of options for selecting user property values.

On the client, you can set only string values for user properties. For conditions that use numeric operators, the Remote Config service converts the value of the corresponding user property into an integer/float.
When using the contains regex operator, you can create regular expressions in RE2 format. Your regular expression can match all or part of the target version string. You can also use the ^ and $ anchors to match the beginning, end, or entirety of a target string.
کشور/منطقه N/A One or more countries or regions used to select users who might be included in the experiment.
زبان ها N/A One or more languages and locales used to select users who might be included in the experiment.
First open قبل از
بعد از

Target users based on the first time they open your app:

  • Select New users to target users who first open your app after a specified future date and time.
  • Select Time range to target users who first open your app within the range before or after the date and time you specify. Combine Before and After conditions to target users within a specific time range.

User targeting by first open is available after you select an Android or iOS app. It is currently supported by the following Remote Config SDK versions: Apple platforms SDK v9.0.0+ and Android SDK v21.1.1+ ( Firebase BoM v30.3.0+).

Analytics must also have been enabled on the client during the first open event.

A/B Testing metrics

When you create your experiment, you choose a primary, or goal metric, that is used to determine the winning variant. You should also track other metrics to help you better understand each experiment variant's performance and track important trends that may differ for each variant, like user retention, app stability and in-app purchase revenue. You can track up to five non-goal metrics in your experiment.

For example, say you're using Remote Config to launch two different game flows in your app and want to optimize for in-app purchases and ad revenue, but you also want to track the stability and user retention of each variant. In this case, you might consider choosing Estimated total revenue as your goal metric because it includes in-app purchase revenue and ad revenue, and then, for Other metrics to track , you might add the following:

  • To track your daily and weekly user retention, add Retention (2-3 days) and Retention (4-7 days) .
  • To compare stability between the two game flows, add Crash-free users .
  • To see more detailed views of each revenue type, add Purchase revenue and Estimated ad revenue .

The following tables provide details on how goal metrics and other metrics are calculated.

Goal metrics

متریک توضیحات
کاربران بدون خرابی The percentage of users who have not encountered errors in your app that were detected by the Firebase Crashlytics SDK during the experiment.
Estimated ad revenue Estimated ad earnings.
کل درآمد تخمینی Combined value for purchase and estimated ad revenues.
درآمد خرید Combined value for all purchase and in_app_purchase events.
Retention (1 day) The number of users who return to your app on a daily basis.
Retention (2-3 days) The number of users who return to your app within 2-3 days.
Retention (4-7 days) The number of users who return to your app within 4-7 days.
Retention (8-14 days) The number of users who return to your app within 8-14 days.
Retention (15+ days) The number of users who return to your app 15 or more days after they last used it.
first_open An Analytics event that triggers when a user first opens an app after installing or reinstalling it. Used as part of a conversion funnel.

سایر معیارها

متریک توضیحات
notification_dismiss An Analytics event that triggers when a notification sent by the Notifications composer is dismissed (Android only).
notification_receive An Analytics event that triggers when a notification sent by the Notifications composer is received while the app is in the background (Android only).
os_update An Analytics event that tracks when the device operating system is updated to a new version.To learn more, see Automatically collected events .
screen_view An Analytics event that tracks screens viewed within your app. To learn more, see Track Screenviews .
جلسه_شروع An Analytics event that counts user sessions in your app. To learn more, see Automatically collected events .

BigQuery data export

In addition to viewing A/B Testing experiment data in the Firebase console, you can inspect and analyze experiment data in BigQuery . While A/B Testing does not have a separate BigQuery table, experiment and variant memberships are stored on every Google Analytics event within the Analytics event tables.

The user properties that contain experiment information are of the form userProperty.key like "firebase_exp_%" or userProperty.key = "firebase_exp_01" where 01 is the experiment ID, and userProperty.value.string_value contains the (zero-based) index of the experiment variant.

You can use these experiment user properties to extract experiment data. This gives you the power to slice your experiment results in many different ways and independently verify the results of A/B Testing .

To get started, complete the following as described in this guide:

  1. Enable BigQuery export for Google Analytics in the Firebase console
  2. Access A/B Testing data using BigQuery
  3. Explore example queries

Enable BigQuery export for Google Analytics in the Firebase console

If you're on the Spark plan, you can use the BigQuery sandbox to access BigQuery at no cost, subject to Sandbox limits . See Pricing and the BigQuery sandbox for more information.

First, make sure that you're exporting your Analytics data to BigQuery :

  1. Open the Integrations tab, which you can access using > Project settings in the Firebase console .
  2. If you're already using BigQuery with other Firebase services, click Manage . Otherwise, click Link .
  3. Review About Linking Firebase to BigQuery , then click Next .
  4. In the Configure integration section, enable the Google Analytics toggle.
  5. Select a region and choose export settings.

  6. Click Link to BigQuery .

Depending on how you chose to export data, it may take up to a day for the tables to become available. For more information about exporting project data to BigQuery , see Export project data to BigQuery .

Access A/B Testing data in BigQuery

Before querying for data for a specific experiment, you'll want to obtain some or all of the following to use in your query:

  • Experiment ID: You can obtain this from the URL of the Experiment overview page. For example, if your URL looks like https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25 , the experiment ID is 25 .
  • Google Analytics property ID : This is your 9-digit Google Analytics property ID. You can find this within Google Analytics ; it also appears in BigQuery when you expand your project name to show the name of your Google Analytics event table ( project_name.analytics_000000000.events ).
  • Experiment date: To compose a faster and more efficient query, it's good practice to limit your queries to the Google Analytics daily event table partitions that contain your experiment data—tables identified with a YYYYMMDD suffix. So, if your experiment ran from February 2, 2024 through May 2, 2024, you'd specify a _TABLE_SUFFIX between '20240202' AND '20240502' . For an example, see Select a specific experiment's values .
  • Event names: Typically, these correspond with your goal metrics that you configured in the experiment. For example, in_app_purchase events, ad_impression , or user_retention events.

After you gather the information you need to generate your query:

  1. Open BigQuery in the Google Cloud console.
  2. Select your project, then select Create SQL query .
  3. درخواست خود را اضافه کنید For example queries to run, see Explore example queries .
  4. روی Run کلیک کنید.

Query experiment data using the Firebase console's auto-generated query

If you're using the Blaze plan, the Experiment overview page provides a sample query that returns the experiment name, variants, event names, and the number of events for the experiment you're viewing.

To obtain and run the auto-generated query:

  1. From the Firebase console, open A/B Testing and select the A/B Testing experiment you want to query to open the Experiment overview .
  2. From the Options menu, beneath BigQuery integration , select Query experiment data . This opens your project in BigQuery within the Google Cloud console console and provides a basic query you can use to query your experiment data.

The following example shows a generated query for an experiment with three variants (including the baseline) named "Winter welcome experiment." It returns the active experiment name, variant name, unique event, and event count for each event. Note that the query builder doesn't specify your project name in the table name, as it opens directly within your project.

  /*
    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

For additional query examples, proceed to Explore example queries .

Explore example queries

The following sections provide examples of queries you can use to extract A/B Testing experiment data from Google Analytics event tables.

Extract purchase and experiment standard deviation values from all experiments

You can use experiment results data to independently verify Firebase A/B Testing results. The following BigQuery SQL statement extracts experiment variants, the number of unique users in each variant, and sums total revenue from in_app_purchase and ecommerce_purchase events, and standard deviations for all experiments within the time range specified as the _TABLE_SUFFIX begin and end dates. You can use the data you obtain from this query with a statistical significance generator for one-tailed t-tests to verify that the results Firebase provides match your own analysis.

For more information about how A/B Testing calculates inference, see Interpret test results .

  /*
    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;

Select a specific experiment's values

The following example query illustrates how to obtain data for a specific experiment in BigQuery . This sample query returns the experiment name, variant names (including Baseline), event names, and event counts.

  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
،

When you use Firebase Remote Config to deploy settings for an application with an active user base, you want to make sure you get it right. You can use A/B Testing experiments to best determine the following:

  • The best way to implement a feature to optimize the user experience. Too often, app developers don't learn that their users dislike a new feature or an updated user experience until their app's rating in the app store declines. A/B testing can help measure whether your users like new variants of features, or whether they prefer the app as it exists. Plus, keeping most of your users in a baseline group ensures that most of your user base can continue to use your app without experiencing any changes to its behavior or appearance until the experiment has concluded.
  • The best way to optimize the user experience for a business goal. Sometimes you're implementing product changes to maximize a metric like revenue or retention. With A/B testing, you set your business objective, and Firebase performs the statistical analysis to determine if a variant is outperforming the baseline for your selected objective.

To A/B test feature variants with a baseline, do the following:

  1. Create your experiment.
  2. Validate your experiment on a test device.
  3. Manage your experiment.

یک آزمایش ایجاد کنید

A Remote Config experiment lets you evaluate multiple variants on one or more Remote Config parameters .

  1. Sign in to the Firebase console and verify that Google Analytics is enabled in your project so that the experiment has access to Analytics data.

    If you did not enable Google Analytics when creating your project, you can enable it on the Integrations tab, which you can access using > Project settings in the Firebase console .

  2. In the Engage section of the Firebase console navigation menu, click A/B Testing .

  3. Click Create experiment , and then select Remote Config when prompted for the service you want to experiment with.

  4. Enter a Name and optional Description for your experiment, and click Next .

  5. Fill out the Targeting fields, first choosing the app that uses your experiment. You can also target a subset of your users to participate in your experiment by clicking and , then choosing options from the following list:

    • Version: One or more versions of your app
    • Build number: The version code of the app
    • Languages: One or more languages and locales used to select users who might be included in the experiment
    • Country/Region: One or more countries or regions for selecting users who should be included in the experiment
    • User audience: Analytics audiences used to target users who might be included in the experiment
    • User property: One or more Analytics user properties for selecting users who might be included in the experiment
    • First open: Target users based on the first time they ever opened your app

      User targeting by first open time is available after you select an Android or iOS app. It is supported by the following Remote Config SDK versions: Apple platforms SDK v9.0.0+ and Android SDK v21.1.1+ ( Firebase BoM v30.3.0+).

      Analytics must also have been enabled on the client during the first open event.

  6. Set the Percentage of target users: Enter the percentage of your app's user base matching the criteria set under Target users that you want to evenly divide between the baseline and one or more variants in your experiment. This can be any percentage between 0.01% and 100%. Users are randomly assigned to each experiment, including duplicated experiments.

  7. Optionally, set an activation event to ensure that only the data from users who have first triggered some Analytics event are counted in your experiment. Note that all users matching your targeting parameters will receive Remote Config experimental values, but only those who trigger an activation event will be included in your experiment results.

    To ensure a valid experiment, make sure that the event you choose occurs after your app activates fetched configuration values. In addition, the following events cannot be used because they always occur before fetched values are activated:

    • app_install
    • app_remove
    • app_update
    • dynamic_link_first_open
  8. For the experiment's Goals , select the primary metric to track, and add any additional metrics you want to track from the list. These include built-in objectives (purchases, revenue, retention, crash-free users, etc.), Analytics conversion events, and other Analytics events. پس از اتمام، روی Next کلیک کنید.

  9. In the Variants section, choose a baseline and at least one variant for the experiment. Use the Choose or create new list to add one or more parameters to experiment with. You can create a parameter that has not previously been used in the Firebase console, but it must exist in your app for it to have any effect. You can repeat this step to add multiple parameters to your experiment.

  10. (optional) To add more than one variant to your experiment, click Add another variant .

  11. Change one or more parameters for specific variants. Any unchanged parameters are the same for users not included in the experiment.

  12. Expand Variant Weights to view or change variant weight for the experiment. By default, each variant is weighted equally. Note that uneven weights may increase data collection time and weights cannot be changed after the experiment begins .

  13. Click Review to save your experiment.

You are allowed up to 300 experiments per project, which could consist of up to 24 running experiments, with the rest as draft or completed.

Validate your experiment on a test device

For each Firebase installation, you can retrieve the installation auth token associated with it. You can use this token to test specific experiment variants on a test device with your app installed. To validate your experiment on a test device, do the following:

  1. Get the installation auth token as follows:
    do {
      let result = try await Installations.installations()
        .authTokenForcingRefresh(true)
      print("Installation auth token: \(result.authToken)")
    } catch {
      print("Error fetching token: \(error)")
    }
    [[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]);
    }];
    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");
            }
        }
    });
    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")
            }
        }
    firebase::InitResult init_result;
    auto* installations_object = firebase::installations::Installations::GetInstance(
        firebase::App::GetInstance(), &init_result);
    installations_object->GetToken().OnCompletion(
        [](const firebase::Future<std::string>& future) {
          if (future.status() == kFutureStatusComplete &&
              future.error() == firebase::installations::kErrorNone) {
            printf("Installations Auth Token %s\n", future.result()->c_str());
          }
        });
    Firebase.Installations.FirebaseInstallations.DefaultInstance.GetTokenAsync(forceRefresh: true).ContinueWith(
      task => {
        if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
          UnityEngine.Debug.Log(System.String.Format("Installations token {0}", task.Result));
        }
      });
  2. On the Firebase console navigation bar, click A/B Testing .
  3. Click Draft (and/or Running for Remote Config experiments), hover over your experiment, click the context menu ( ), and then click Manage test devices .
  4. Enter the installation auth token for a test device and choose the experiment variant to send to that test device.
  5. Run the app and confirm that the selected variant is being received on the test device.

To learn more about Firebase installations, see Manage Firebase installations .

Manage your experiment

Whether you create an experiment with Remote Config , the Notifications composer, or Firebase In-App Messaging , you can then validate and start your experiment, monitor your experiment while it is running, and increase the number of users included in your running experiment.

When your experiment is done, you can take note of the settings used by the winning variant, and then roll out those settings to all users. Or, you can run another experiment.

Start an experiment

  1. In the Engage section of the Firebase console navigation menu, click A/B Testing .
  2. Click Draft , and then click the title of your experiment.
  3. To validate that your app has users who would be included in your experiment, expand the draft details and check for a number greater than 0% in the Targeting and distribution section (for example, 1% of users matching the criteria ).
  4. To change your experiment, click Edit .
  5. To start your experiment, click Start Experiment . You can run up to 24 experiments per project at a time.

Monitor an experiment

Once an experiment has been running for a while, you can check in on its progress and see what your results look like for the users who have participated in your experiment so far.

  1. In the Engage section of the Firebase console navigation menu, click A/B Testing .
  2. Click Running , and then click on, or search for, the title of your experiment. On this page, you can view various observed and modeled statistics about your running experiment, including the following:

    • % difference from baseline : A measure of the improvement of a metric for a given variant as compared to the baseline. Calculated by comparing the value range for the variant to the value range for the baseline.
    • Probability to beat baseline : The estimated probability that a given variant beats the baseline for the selected metric.
    • observed_metric per user : Based on experiment results, this is the predicted range that the metric value will fall into over time.
    • Total observed_metric : The observed cumulative value for the baseline or variant. The value is used to measure how well each experiment variant performs, and is used to calculate Improvement , Value range , Probability to beat baseline , and Probability to be the best variant . Depending on the metric being measured, this column may be labeled "Duration per user," "Revenue per user," "Retention rate," or "Conversion rate."
  3. After your experiment has run for a while (at least 7 days for FCM and In-App Messaging or 14 days for Remote Config ), data on this page indicates which variant, if any, is the "leader." Some measurements are accompanied by a bar chart that presents the data in a visual format.

Roll out an experiment to all users

After an experiment has run long enough that you have a "leader," or winning variant, for your goal metric, you can release the experiment to 100% of users. This lets you select a variant to publish to all users moving forward. Even if your experiment has not created a clear winner, you can still choose to release a variant to all of your users.

  1. In the Engage section of the Firebase console navigation menu, click A/B Testing .
  2. Click Completed or Running , click an experiment that you want to release to all users, click the context menu ( ) Roll out variant .
  3. Roll out your experiment to all users by doing one of the following:

    • For an experiment that uses the Notifications composer , use the Roll out message dialog to send the message to the remaining targeted users who were not part of the experiment.
    • For a Remote Config experiment, select a variant to determine which Remote Config parameter values to update. The targeting criteria defined when creating the experiment is added as a new condition in your template, to ensure the rollout only affects users targeted by the experiment. After clicking Review in Remote Config to review the changes, click Publish changes to complete the rollout.
    • For an In-App Messaging experiment, use the dialog to determine which variant needs to be rolled out as a standalone In-App Messaging campaign. Once selected, you are redirected to the FIAM compose screen to make any changes (if required) before publishing.

Expand an experiment

If you find that an experiment isn't bringing in enough users for A/B Testing to declare a leader, you can increase distribution of your experiment to reach a larger percentage of the app's user base.

  1. In the Engage section of the Firebase console navigation menu, click A/B Testing .
  2. Select the running experiment that you want to edit.
  3. In the Experiment overview , click the context menu ( ), and then click Edit running experiment .
  4. The Targeting dialog displays an option to increase the percentage of users who are in the running experiment. Select a number greater than the current percentage and click Publish . The experiment will be pushed out to the percentage of users you have specified.

Duplicate or stop an experiment

  1. In the Engage section of the Firebase console navigation menu, click A/B Testing .
  2. Click Completed or Running , hold the pointer over your experiment, click the context menu ( ), and then click Duplicate experiment or Stop experiment .

User targeting

You can target the users to include in your experiment using the following user-targeting criteria.

Targeting criterion اپراتور(های) ارزش(های) توجه داشته باشید
نسخه حاوی،
does not contain,
matches exactly,
contains regex
Enter a value for one or more app versions that you want to include in the experiment.

When using any of the contains , does not contain , or matches exactly operators, you can provide a comma-separated list of values.

When using the contains regex operator, you can create regular expressions in RE2 format. Your regular expression can match all or part of the target version string. You can also use the ^ and $ anchors to match the beginning, end, or entirety of a target string.

User audience(s) includes all of,
includes at least one of,
does not include all of,
does not include at least one of
Select one or more Analytics audiences to target users who might be included in your experiment. Some experiments that target Google Analytics audiences may require a few days to accumulate data because they are subject to Analytics data processing latency . You are most likely to encounter this delay with new users, who are typically enrolled into qualifying audiences 24-48 hours after creation, or for recently-created audiences .

For Remote Config , this means that even if a user technically qualifies for an audience, if Analytics has not yet added the user to the audience when `fetchAndActivate()` is executed, the user will not be included in the experiment.

دارایی کاربر برای متن:
حاوی،
does not contain,
exactly matches,
contains regex

برای اعداد:
<, ≤, =, ≥, >
An Analytics user property is used to select users who might be included in an experiment, with a range of options for selecting user property values.

On the client, you can set only string values for user properties. For conditions that use numeric operators, the Remote Config service converts the value of the corresponding user property into an integer/float.
When using the contains regex operator, you can create regular expressions in RE2 format. Your regular expression can match all or part of the target version string. You can also use the ^ and $ anchors to match the beginning, end, or entirety of a target string.
کشور/منطقه N/A One or more countries or regions used to select users who might be included in the experiment.
زبان ها N/A One or more languages and locales used to select users who might be included in the experiment.
First open قبل از
بعد از

Target users based on the first time they open your app:

  • Select New users to target users who first open your app after a specified future date and time.
  • Select Time range to target users who first open your app within the range before or after the date and time you specify. Combine Before and After conditions to target users within a specific time range.

User targeting by first open is available after you select an Android or iOS app. It is currently supported by the following Remote Config SDK versions: Apple platforms SDK v9.0.0+ and Android SDK v21.1.1+ ( Firebase BoM v30.3.0+).

Analytics must also have been enabled on the client during the first open event.

A/B Testing metrics

When you create your experiment, you choose a primary, or goal metric, that is used to determine the winning variant. You should also track other metrics to help you better understand each experiment variant's performance and track important trends that may differ for each variant, like user retention, app stability and in-app purchase revenue. You can track up to five non-goal metrics in your experiment.

For example, say you're using Remote Config to launch two different game flows in your app and want to optimize for in-app purchases and ad revenue, but you also want to track the stability and user retention of each variant. In this case, you might consider choosing Estimated total revenue as your goal metric because it includes in-app purchase revenue and ad revenue, and then, for Other metrics to track , you might add the following:

  • To track your daily and weekly user retention, add Retention (2-3 days) and Retention (4-7 days) .
  • To compare stability between the two game flows, add Crash-free users .
  • To see more detailed views of each revenue type, add Purchase revenue and Estimated ad revenue .

The following tables provide details on how goal metrics and other metrics are calculated.

Goal metrics

متریک توضیحات
کاربران بدون خرابی The percentage of users who have not encountered errors in your app that were detected by the Firebase Crashlytics SDK during the experiment.
Estimated ad revenue Estimated ad earnings.
کل درآمد تخمینی Combined value for purchase and estimated ad revenues.
درآمد خرید Combined value for all purchase and in_app_purchase events.
Retention (1 day) The number of users who return to your app on a daily basis.
Retention (2-3 days) The number of users who return to your app within 2-3 days.
Retention (4-7 days) The number of users who return to your app within 4-7 days.
Retention (8-14 days) The number of users who return to your app within 8-14 days.
Retention (15+ days) The number of users who return to your app 15 or more days after they last used it.
first_open An Analytics event that triggers when a user first opens an app after installing or reinstalling it. Used as part of a conversion funnel.

سایر معیارها

متریک توضیحات
notification_dismiss An Analytics event that triggers when a notification sent by the Notifications composer is dismissed (Android only).
notification_receive An Analytics event that triggers when a notification sent by the Notifications composer is received while the app is in the background (Android only).
os_update An Analytics event that tracks when the device operating system is updated to a new version.To learn more, see Automatically collected events .
screen_view An Analytics event that tracks screens viewed within your app. To learn more, see Track Screenviews .
جلسه_شروع An Analytics event that counts user sessions in your app. To learn more, see Automatically collected events .

BigQuery data export

In addition to viewing A/B Testing experiment data in the Firebase console, you can inspect and analyze experiment data in BigQuery . While A/B Testing does not have a separate BigQuery table, experiment and variant memberships are stored on every Google Analytics event within the Analytics event tables.

The user properties that contain experiment information are of the form userProperty.key like "firebase_exp_%" or userProperty.key = "firebase_exp_01" where 01 is the experiment ID, and userProperty.value.string_value contains the (zero-based) index of the experiment variant.

You can use these experiment user properties to extract experiment data. This gives you the power to slice your experiment results in many different ways and independently verify the results of A/B Testing .

To get started, complete the following as described in this guide:

  1. Enable BigQuery export for Google Analytics in the Firebase console
  2. Access A/B Testing data using BigQuery
  3. Explore example queries

Enable BigQuery export for Google Analytics in the Firebase console

If you're on the Spark plan, you can use the BigQuery sandbox to access BigQuery at no cost, subject to Sandbox limits . See Pricing and the BigQuery sandbox for more information.

First, make sure that you're exporting your Analytics data to BigQuery :

  1. Open the Integrations tab, which you can access using > Project settings in the Firebase console .
  2. If you're already using BigQuery with other Firebase services, click Manage . Otherwise, click Link .
  3. Review About Linking Firebase to BigQuery , then click Next .
  4. In the Configure integration section, enable the Google Analytics toggle.
  5. Select a region and choose export settings.

  6. Click Link to BigQuery .

Depending on how you chose to export data, it may take up to a day for the tables to become available. For more information about exporting project data to BigQuery , see Export project data to BigQuery .

Access A/B Testing data in BigQuery

Before querying for data for a specific experiment, you'll want to obtain some or all of the following to use in your query:

  • Experiment ID: You can obtain this from the URL of the Experiment overview page. For example, if your URL looks like https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25 , the experiment ID is 25 .
  • Google Analytics property ID : This is your 9-digit Google Analytics property ID. You can find this within Google Analytics ; it also appears in BigQuery when you expand your project name to show the name of your Google Analytics event table ( project_name.analytics_000000000.events ).
  • Experiment date: To compose a faster and more efficient query, it's good practice to limit your queries to the Google Analytics daily event table partitions that contain your experiment data—tables identified with a YYYYMMDD suffix. So, if your experiment ran from February 2, 2024 through May 2, 2024, you'd specify a _TABLE_SUFFIX between '20240202' AND '20240502' . For an example, see Select a specific experiment's values .
  • Event names: Typically, these correspond with your goal metrics that you configured in the experiment. For example, in_app_purchase events, ad_impression , or user_retention events.

After you gather the information you need to generate your query:

  1. Open BigQuery in the Google Cloud console.
  2. Select your project, then select Create SQL query .
  3. درخواست خود را اضافه کنید For example queries to run, see Explore example queries .
  4. روی Run کلیک کنید.

Query experiment data using the Firebase console's auto-generated query

If you're using the Blaze plan, the Experiment overview page provides a sample query that returns the experiment name, variants, event names, and the number of events for the experiment you're viewing.

To obtain and run the auto-generated query:

  1. From the Firebase console, open A/B Testing and select the A/B Testing experiment you want to query to open the Experiment overview .
  2. From the Options menu, beneath BigQuery integration , select Query experiment data . This opens your project in BigQuery within the Google Cloud console console and provides a basic query you can use to query your experiment data.

The following example shows a generated query for an experiment with three variants (including the baseline) named "Winter welcome experiment." It returns the active experiment name, variant name, unique event, and event count for each event. Note that the query builder doesn't specify your project name in the table name, as it opens directly within your project.

  /*
    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

For additional query examples, proceed to Explore example queries .

Explore example queries

The following sections provide examples of queries you can use to extract A/B Testing experiment data from Google Analytics event tables.

Extract purchase and experiment standard deviation values from all experiments

You can use experiment results data to independently verify Firebase A/B Testing results. The following BigQuery SQL statement extracts experiment variants, the number of unique users in each variant, and sums total revenue from in_app_purchase and ecommerce_purchase events, and standard deviations for all experiments within the time range specified as the _TABLE_SUFFIX begin and end dates. You can use the data you obtain from this query with a statistical significance generator for one-tailed t-tests to verify that the results Firebase provides match your own analysis.

For more information about how A/B Testing calculates inference, see Interpret test results .

  /*
    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;

Select a specific experiment's values

The following example query illustrates how to obtain data for a specific experiment in BigQuery . This sample query returns the experiment name, variant names (including Baseline), event names, and event counts.

  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