এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

A/B পরীক্ষার সাথে ফায়ারবেস রিমোট কনফিগার পরীক্ষা তৈরি করুন

যখন আপনি সক্রিয় ব্যবহারকারী আছে এমন কোনো অ্যাপ্লিকেশনের জন্য সেটিংস ডেপ্লয় করতে Firebase Remote Config ব্যবহার করেন, তখন আপনাকে নিশ্চিত করতে হবে যে কাজটি সঠিকভাবে হচ্ছে। নিম্নলিখিত বিষয়গুলো সবচেয়ে ভালোভাবে নির্ধারণ করার জন্য আপনি A/B Testing এক্সপেরিমেন্ট ব্যবহার করতে পারেন:

ব্যবহারকারীর অভিজ্ঞতা উন্নত করার জন্য কোনো ফিচার প্রয়োগ করার সেরা উপায় হলো A/B Testing পরিমাপ করতে সাহায্য করে যে আপনার ব্যবহারকারীরা ফিচারের নতুন সংস্করণগুলো পছন্দ করছেন, নাকি তারা অ্যাপটির বর্তমান রূপটিই বেশি পছন্দ করেন। এছাড়াও, আপনার বেশিরভাগ ব্যবহারকারীকে একটি বেসলাইন গ্রুপে রাখলে এটি নিশ্চিত হয় যে, পরীক্ষাটি শেষ না হওয়া পর্যন্ত আপনার ব্যবহারকারীদের একটি বড় অংশ অ্যাপটির আচরণ বা চেহারায় কোনো পরিবর্তন ছাড়াই এটি ব্যবহার করা চালিয়ে যেতে পারবেন।
একটি ব্যবসায়িক লক্ষ্যের জন্য ব্যবহারকারীর অভিজ্ঞতাকে অপ্টিমাইজ করার সেরা উপায় হলো এ/বি টেস্টিং। কখনও কখনও আপনি রাজস্ব বা রিটেনশনের মতো কোনো মেট্রিককে সর্বোচ্চ করার জন্য পণ্যে পরিবর্তন আনেন। A/B Testing মাধ্যমে, আপনি আপনার ব্যবসায়িক উদ্দেশ্য নির্ধারণ করেন এবং ফায়ারবেস পরিসংখ্যানগত বিশ্লেষণ করে নির্ধারণ করে যে, কোনো ভ্যারিয়েন্ট আপনার নির্বাচিত উদ্দেশ্যের জন্য বেসলাইনের চেয়ে ভালো পারফর্ম করছে কি না।

একটি বেসলাইনের সাথে ফিচার ভ্যারিয়েন্টগুলোর A/B টেস্ট করতে, নিম্নলিখিত পদক্ষেপগুলো অনুসরণ করুন:

আপনার পরীক্ষাটি তৈরি করুন।
আপনার পরীক্ষাটি পরিচালনা করুন।

একটি পরীক্ষা তৈরি করুন

একটি Remote Config এক্সপেরিমেন্ট আপনাকে এক বা একাধিক Remote Config প্যারামিটারের একাধিক ভ্যারিয়েন্ট মূল্যায়ন করার সুযোগ দেয়।

আপনার প্রোজেক্টে Google Analytics সক্রিয় করা আছে কিনা তা যাচাই করুন, যাতে এক্সপেরিমেন্টটি Analytics ডেটা অ্যাক্সেস করতে পারে।
প্রজেক্ট তৈরি করার সময় যদি আপনি Google Analytics চালু না করে থাকেন, তাহলে আপনি এটি চালু করতে পারেন। Firebase কনসোলের > ইন্টিগ্রেশন ট্যাব ।
Firebase কনসোলে, DevOps & Engagement > A/B Testing এ যান।
Create experiment-এ ক্লিক করুন, এবং তারপরে আপনি যে পরিষেবাটি নিয়ে পরীক্ষা করতে চান তার জন্য অনুরোধ করা হলে Remote Config নির্বাচন করুন।
ভ্যারিয়েন্টস সেকশনে, পরীক্ষাটির জন্য একটি বেসলাইন এবং অন্তত একটি ভ্যারিয়েন্ট বেছে নিন। পরীক্ষা চালানোর জন্য আপনি এক বা একাধিক প্যারামিটার যোগ করতে পারেন। আপনার পরীক্ষায় একাধিক প্যারামিটার যোগ করতে আপনি এই ধাপটি পুনরাবৃত্তি করতে পারেন।
(ঐচ্ছিক) আপনার পরীক্ষায় একাধিক ভ্যারিয়েন্ট যোগ করতে, ‘Add another variant’- এ ক্লিক করুন।
নির্দিষ্ট ভ্যারিয়েন্টগুলোর জন্য এক বা একাধিক প্যারামিটার পরিবর্তন করুন। পরীক্ষায় অন্তর্ভুক্ত নন এমন ব্যবহারকারীদের জন্য অপরিবর্তিত প্যারামিটারগুলো একই থাকবে।
পরীক্ষার জন্য ভ্যারিয়েন্টের ওয়েট দেখতে বা পরিবর্তন করতে ‘Variant Weights’ অংশটি প্রসারিত করুন। ডিফল্টরূপে, প্রতিটি ভ্যারিয়েন্টকে সমান ওয়েট দেওয়া হয়। মনে রাখবেন যে, অসম ওয়েটের কারণে ডেটা সংগ্রহের সময় বেড়ে যেতে পারে এবং পরীক্ষা শুরু হয়ে গেলে ওয়েট পরিবর্তন করা যায় না ।
Remote Config শর্তাবলী ব্যবহার করে আপনার এক্সপেরিমেন্টের জন্য টার্গেটিং ক্রাইটেরিয়া নির্ধারণ করুন:
- বিদ্যমান শর্ত পুনরায় ব্যবহার করুন: যদি আপনার Remote Config টেমপ্লেটে থাকা কোনো বিদ্যমান শর্ত আপনার টার্গেট অডিয়েন্সের সাথে আগে থেকেই মিলে যায়, তাহলে তালিকা থেকে সেটি নির্বাচন করুন।
  গুরুত্বপূর্ণ: যদি আপনি কোনো পরীক্ষার জন্য বিদ্যমান কোনো শর্ত পুনরায় ব্যবহার করেন, তাহলে পরীক্ষাটি সম্পূর্ণ বা বন্ধ না হওয়া পর্যন্ত আপনি সেই শর্তটি সম্পাদনা করতে পারবেন না । পরীক্ষা চলাকালীন কোনো শেয়ার করা শর্ত পরিবর্তন করলে তা ভ্যারিয়েন্ট অ্যাসাইনমেন্ট পরিবর্তন করতে পারে এবং পরীক্ষার পরিমাপকে অবৈধ করে দিতে পারে।
- শর্ত মূল্যায়নের ক্রম যাচাই করুন: নিশ্চিত করুন যে 'শর্তাবলী' পৃষ্ঠায় আপনার শর্তগুলো সঠিক অগ্রাধিকার ক্রমে সাজানো আছে। যেহেতু Remote Config শর্তগুলোকে উপর থেকে নিচে ক্রমানুসারে মূল্যায়ন করে, তাই অন্যান্য উচ্চ-অগ্রাধিকারের শর্তগুলো আপনার এক্সপেরিমেন্টের সাথে যুক্ত শর্তটিতে পর্যাপ্ত সংখ্যক ব্যবহারকারীকে পৌঁছাতে বাধা দিতে পারে।
- একটি নতুন শর্ত তৈরি করুন: যদি কোনো বিদ্যমান শর্ত আপনার টার্গেটিং প্রয়োজনীয়তা পূরণ না করে, অথবা যদি আপনি একটি বিদ্যমান শর্ত নকল করতে চান (উদাহরণস্বরূপ, অন্যান্য প্যারামিটারের সাথে ব্যবহৃত একটি শর্ত লক করা এড়াতে), তাহলে প্রথমে আপনার এক্সপেরিমেন্ট ব্যবহারকারী অ্যাপটি বেছে নিয়ে একটি নতুন শর্ত তৈরি করুন। আপনি যে প্যারামিটারটি পরীক্ষা করছেন সেটি যদি বিদ্যমান (বা অন্য কোনো ওভারল্যাপিং) শর্তও ব্যবহার করে, তাহলে নিশ্চিত করুন যে নতুন এক্সপেরিমেন্টের শর্তটি 'Conditions' ট্যাবে বিদ্যমান শর্তের উপরে রাখা হয়েছে (এটিকে উচ্চতর মূল্যায়ন অগ্রাধিকার দিয়ে); অন্যথায়, ব্যবহারকারীরা প্রথমে বিদ্যমান শর্তের সাথে মিলে যাবে এবং এক্সপেরিমেন্টে প্রবেশ করতে পারবে না।
  এরপর আপনি ক্লিক করে এবং নিচের তালিকা থেকে এক বা একাধিক বিকল্প নির্বাচন করে ব্যবহারকারীদের একটি নির্দিষ্ট উপগোষ্ঠীকে লক্ষ্য করতে পারেন:
  - সংস্করণ: আপনার অ্যাপের এক বা একাধিক সংস্করণ
  - বিল্ড নম্বর: আপনার অ্যাপের বিল্ড নম্বর (অ্যাপল) বা ভার্সন কোড (অ্যান্ড্রয়েড)।
  - প্ল্যাটফর্ম: এক বা একাধিক প্ল্যাটফর্ম (iOS, Android, বা Web) লক্ষ্য করা হবে
  - অপারেটিং সিস্টেম: তাদের অপারেটিং সিস্টেম এবং ভার্সনের উপর ভিত্তি করে ওয়েব অ্যাপ ব্যবহারকারীদের লক্ষ্য করুন।
  - ব্রাউজার: ওয়েব ব্রাউজার এবং ব্রাউজার সংস্করণের উপর ভিত্তি করে ওয়েব অ্যাপ ব্যবহারকারীদের লক্ষ্য করুন।
  - ডিভাইসের বিভাগ: ব্যবহারকারীদের ডিভাইস মোবাইল নাকি নন-মোবাইল, তার উপর ভিত্তি করে ওয়েব অ্যাপ ব্যবহারকারীদের লক্ষ্য করুন।
  - ভাষা: পরীক্ষায় অন্তর্ভুক্ত হতে পারে এমন ব্যবহারকারীদের নির্বাচন করার জন্য ব্যবহৃত এক বা একাধিক ভাষা এবং লোকেল।
  - দেশ/অঞ্চল: পরীক্ষায় অন্তর্ভুক্ত করার জন্য ব্যবহারকারী নির্বাচনের উদ্দেশ্যে এক বা একাধিক দেশ বা অঞ্চল।
  - ব্যবহারকারী অডিয়েন্স: Analytics অডিয়েন্স, যা এমন ব্যবহারকারীদের টার্গেট করতে ব্যবহৃত হয় যারা এই পরীক্ষায় অন্তর্ভুক্ত হতে পারেন।
  - ব্যবহারকারীর বৈশিষ্ট্য: পরীক্ষায় অন্তর্ভুক্ত হতে পারে এমন ব্যবহারকারীদের নির্বাচন করার জন্য এক বা একাধিক Analytics ব্যবহারকারীর বৈশিষ্ট্য।
  - এলোমেলো শতাংশে ব্যবহারকারী: একটি সংজ্ঞায়িত শতাংশ পরিসরের মধ্যে থেকে এলোমেলোভাবে নির্বাচিত ব্যবহারকারীদের একটি নির্দিষ্ট শতাংশকে লক্ষ্য করুন।
  - ইমপোর্টেড সেগমেন্ট: আপনার প্রজেক্টে আপলোড করা কাস্টম ইমপোর্টেড সেগমেন্টের অন্তর্ভুক্ত ব্যবহারকারীদের টার্গেট করুন।
  - তারিখ/সময়: একটি নির্দিষ্ট তারিখ এবং সময়ের মধ্যে ব্যবহারকারীদের লক্ষ্য করা।
  - প্রথমবার খোলা: ব্যবহারকারীরা প্রথমবারের মতো আপনার অ্যাপটি খোলার উপর ভিত্তি করে তাদের লক্ষ্য করুন।
  - ইনস্টলেশন আইডি: তাদের ফায়ারবেস ইনস্টলেশন আইডি (FID) ব্যবহার করে নির্দিষ্ট টেস্ট ডিভাইস বা ক্লায়েন্ট ইনস্ট্যান্সকে টার্গেট করুন।
  - ব্যবহারকারী বিদ্যমান: প্রজেক্টের সমস্ত অ্যাপের সকল ব্যবহারকারীকে টার্গেট করুন।
  - কাস্টম সিগন্যাল: রানটাইমে প্রেরিত কাস্টম ক্লায়েন্ট-সাইড কী-ভ্যালু সিগন্যালের উপর ভিত্তি করে ব্যবহারকারীদের টার্গেট করা।
দ্রষ্টব্য: Google Analytics ডেটা প্রক্রিয়াকরণের বিলম্বের কারণে, Analytics ব্যবহারকারী গোষ্ঠীকে লক্ষ্য করে করা পরীক্ষাগুলোর ডেটা সংগ্রহ করতে বেশি সময় লাগতে পারে। এই বিষয়ে এবং অন্যান্য টার্গেটিং বিকল্পগুলো সম্পর্কে আরও জানতে, ব্যবহারকারী টার্গেটিং (User targeting) দেখুন।
এক্সপোজার নির্ধারণ করুন: আপনার এক্সপেরিমেন্টে বেসলাইন এবং এক বা একাধিক ভ্যারিয়েন্টের মধ্যে সমানভাবে ভাগ করার জন্য, 'টার্গেট ইউজার্স' -এর অধীনে নির্ধারিত শর্তের সাথে মেলে এমন আপনার অ্যাপের ব্যবহারকারীর শতাংশ লিখুন। এই শতাংশ ০% থেকে ১০০%-এর মধ্যে যেকোনো হতে পারে। ডুপ্লিকেট এক্সপেরিমেন্ট সহ প্রতিটি এক্সপেরিমেন্টে ব্যবহারকারীদের এলোমেলোভাবে বরাদ্দ করা হয়।
ঐচ্ছিকভাবে, একটি অ্যাক্টিভেশন ইভেন্ট সেট করুন যাতে আপনার এক্সপেরিমেন্টে শুধুমাত্র সেইসব ব্যবহারকারীর ডেটা গণনা করা হয়, যারা প্রথম কোনো Analytics ইভেন্ট ট্রিগার করেছেন। মনে রাখবেন যে, আপনার টার্গেটিং প্যারামিটারের সাথে মিলে যাওয়া সমস্ত ব্যবহারকারী Remote Config এক্সপেরিমেন্টাল ভ্যালু পাবেন, কিন্তু শুধুমাত্র তারাই আপনার এক্সপেরিমেন্টের ফলাফলে অন্তর্ভুক্ত হবেন, যারা একটি অ্যাক্টিভেশন ইভেন্ট ট্রিগার করবেন।
দ্রষ্টব্য: A/B Testing ওয়েব বাস্তবায়নের জন্য অ্যাক্টিভেশন ইভেন্ট সমর্থিত নয়।
একটি বৈধ এক্সপেরিমেন্ট নিশ্চিত করতে, খেয়াল রাখবেন যেন আপনার নির্বাচিত ইভেন্টটি আপনার অ্যাপ দ্বারা ফেচ করা কনফিগারেশন ভ্যালুগুলো অ্যাক্টিভেট করার পরে ঘটে। এছাড়াও, নিম্নলিখিত ইভেন্টগুলো ব্যবহার করা যাবে না, কারণ এগুলো সবসময় ফেচ করা ভ্যালুগুলো অ্যাক্টিভেট হওয়ার আগে ঘটে:
- app_install
- app_remove
- app_update
Analytics ইভেন্ট হিসেবে আপনি যে অ্যানালিটিক্স ইভেন্টটি নির্বাচন করবেন, সেটি একই এক্সপেরিমেন্টে প্রাইমারি মেট্রিক (বা অতিরিক্ত মেট্রিক) হিসেবে ব্যবহার করা যাবে না। এমনটা করলে ফায়ারবেস কনসোলে একটি ভ্যালিডেশন এরর দেখা দেবে এবং আপনার এক্সপেরিমেন্টটি চালু হতে পারবে না।
এক্সপেরিমেন্টের ' Goals'- এর জন্য, ট্র্যাক করার প্রধান মেট্রিকটি নির্বাচন করুন এবং তালিকা থেকে আপনি ট্র্যাক করতে চান এমন যেকোনো অতিরিক্ত মেট্রিক যোগ করুন। এগুলোর মধ্যে রয়েছে বিল্ট-ইন উদ্দেশ্যসমূহ (যেমন: ক্রয়, রাজস্ব, রিটেনশন, ক্র্যাশ-মুক্ত ব্যবহারকারী ইত্যাদি), Analytics কনভার্সন ইভেন্ট এবং অন্যান্য Analytics ইভেন্ট। কাজ শেষ হলে, 'Next'-এ ক্লিক করুন।
আপনার এক্সপেরিমেন্টটি সংরক্ষণ করতে সেভ-এ ক্লিক করুন। এক্সপেরিমেন্টটি চালানো শুরু করতে আপনাকে অবশ্যই টেমপ্লেটটি পাবলিশ করতে হবে।

প্রতিটি প্রকল্পে আপনাকে সর্বোচ্চ ৩০০টি এক্সপেরিমেন্ট (রোলআউট সহ) করার অনুমতি দেওয়া হয়েছে, যার মধ্যে সর্বোচ্চ ২৪টি চলমান এক্সপেরিমেন্ট ও রোলআউট এবং বাকিগুলো সম্পন্ন এক্সপেরিমেন্ট হিসেবে থাকবে।

আপনার পরীক্ষাটি পরিচালনা করুন

যখন আপনি Remote Config ব্যবহার করে একটি এক্সপেরিমেন্ট তৈরি করেন, তখন আপনি আপনার এক্সপেরিমেন্টটি শুরু করতে, এটি চলার সময় পর্যবেক্ষণ করতে এবং আপনার চলমান এক্সপেরিমেন্টে অন্তর্ভুক্ত ব্যবহারকারীর সংখ্যা বাড়াতে পারেন।

আপনার পরীক্ষাটি সম্পন্ন হলে, আপনি বিজয়ী ভ্যারিয়েন্টটির ব্যবহৃত সেটিংসগুলো নোট করে নিতে পারেন এবং তারপর সেই সেটিংসগুলো সকল ব্যবহারকারীর জন্য চালু করে দিতে পারেন। অথবা, আপনি আরেকটি পরীক্ষা চালাতে পারেন।

একটি পরীক্ষা সম্পাদনা করুন

Firebase কনসোল নেভিগেশন মেনুর DevOps & Engagement বিভাগে, Remote Config ক্লিক করুন।
A/B টেস্ট ট্যাবে ক্লিক করুন।
Running-এ ক্লিক করুন, এরপর যে এক্সপেরিমেন্টটি সম্পাদনা করতে চান সেটিতে ক্লিক করুন।
কন্টেক্সট মেনু ( ) ক্লিক করুন এবং চলমান এক্সপেরিমেন্ট সম্পাদনা করুন- এ ক্লিক করুন।
আপনার অ্যাপে এমন ব্যবহারকারী আছেন কিনা যারা আপনার এক্সপেরিমেন্টে অন্তর্ভুক্ত হবেন, তা যাচাই করতে, ডিটেইলসগুলো এক্সপ্যান্ড করুন এবং টার্গেটিং অ্যান্ড ডিস্ট্রিবিউশন সেকশনে 0%-এর চেয়ে বড় কোনো সংখ্যা আছে কিনা তা দেখুন (উদাহরণস্বরূপ, ক্রাইটেরিয়ার সাথে মিলে যাওয়া ব্যবহারকারীদের 1% )।

একটি পরীক্ষা পর্যবেক্ষণ করুন

একটি পরীক্ষা কিছুক্ষণ চলার পর, আপনি এর অগ্রগতি যাচাই করতে পারেন এবং এখন পর্যন্ত আপনার পরীক্ষায় অংশগ্রহণকারী ব্যবহারকারীদের জন্য ফলাফল কেমন দেখাচ্ছে তা দেখতে পারেন।

Firebase কনসোল নেভিগেশন মেনুর DevOps & Engagement বিভাগে, Remote Config ক্লিক করুন।
A/B টেস্ট ট্যাবে ক্লিক করুন।
'Running'-এ ক্লিক করুন, এবং তারপর আপনার এক্সপেরিমেন্টের শিরোনামে ক্লিক করুন বা অনুসন্ধান করুন। এই পৃষ্ঠায়, আপনি আপনার চলমান এক্সপেরিমেন্ট সম্পর্কিত বিভিন্ন পর্যবেক্ষণকৃত এবং মডেলকৃত পরিসংখ্যান দেখতে পারবেন, যার মধ্যে নিম্নলিখিতগুলো অন্তর্ভুক্ত:
- বেসলাইন থেকে শতাংশ পার্থক্য : বেসলাইনের তুলনায় কোনো প্রদত্ত ভ্যারিয়েন্টের জন্য একটি মেট্রিকের উন্নতির পরিমাপ। ভ্যারিয়েন্টটির মান পরিসরকে বেসলাইনের মান পরিসরের সাথে তুলনা করে এটি গণনা করা হয়।
- বেসলাইনকে ছাড়িয়ে যাওয়ার সম্ভাবনা : নির্বাচিত মেট্রিকের ক্ষেত্রে কোনো প্রদত্ত ভ্যারিয়েন্টের বেসলাইনকে ছাড়িয়ে যাওয়ার আনুমানিক সম্ভাবনা।
- প্রতি ব্যবহারকারীর observed_metric : পরীক্ষার ফলাফলের উপর ভিত্তি করে, এটি হলো সেই পূর্বাভাসিত পরিসর যার মধ্যে সময়ের সাথে সাথে মেট্রিকের মানটি থাকবে।
- মোট observed_metric : বেসলাইন বা ভ্যারিয়েন্টের জন্য পর্যবেক্ষণকৃত ক্রমবর্ধমান মান। প্রতিটি এক্সপেরিমেন্ট ভ্যারিয়েন্ট কতটা ভালো পারফর্ম করে তা পরিমাপ করতে এবং উন্নতি , মানের পরিসর , বেসলাইনকে হারানোর সম্ভাবনা , ও সেরা ভ্যারিয়েন্ট হওয়ার সম্ভাবনা গণনা করতে এই মানটি ব্যবহৃত হয়। পরিমাপ করা মেট্রিকের উপর নির্ভর করে, এই কলামটির লেবেল "ব্যবহারকারী প্রতি সময়কাল," "ব্যবহারকারী প্রতি আয়," "রিটেনশন রেট," বা "কনভার্সন রেট" হতে পারে।
আপনার পরীক্ষাটি কিছু সময় চলার পর ( Remote Config জন্য ১৪ দিন), এই পৃষ্ঠার ডেটা থেকে জানা যায় কোন ভ্যারিয়েন্টটি (যদি থাকে) "লিডার"। কিছু পরিমাপের সাথে একটি বার চার্ট থাকে যা ডেটাগুলোকে একটি ভিজ্যুয়াল ফরম্যাটে উপস্থাপন করে।

সকল ব্যবহারকারীর জন্য একটি পরীক্ষা চালু করুন

একটি পরীক্ষা যথেষ্ট সময় ধরে চলার পর যখন আপনার কাঙ্ক্ষিত মেট্রিকের জন্য একটি 'লিডার' বা বিজয়ী ভ্যারিয়েন্ট পাওয়া যায়, তখন আপনি পরীক্ষাটি ১০০% ব্যবহারকারীর জন্য প্রকাশ করতে পারেন। এর মাধ্যমে আপনি ভবিষ্যতে সকল ব্যবহারকারীর জন্য প্রকাশ করার মতো একটি ভ্যারিয়েন্ট বেছে নিতে পারেন। এমনকি যদি আপনার পরীক্ষাটি কোনো সুস্পষ্ট বিজয়ী তৈরি না করে, তবুও আপনি আপনার সকল ব্যবহারকারীর জন্য একটি ভ্যারিয়েন্ট প্রকাশ করার সিদ্ধান্ত নিতে পারেন।

Firebase কনসোল নেভিগেশন মেনুর DevOps & Engagement বিভাগে, Remote Config ক্লিক করুন।
A/B টেস্ট ট্যাবে ক্লিক করুন।
Completed বা Running-এ ক্লিক করুন, যে এক্সপেরিমেন্টটি আপনি সকল ব্যবহারকারীর জন্য রিলিজ করতে চান সেটিতে ক্লিক করুন, এরপর কনটেক্সট মেনু ( ) থেকে Roll out variant-এ ক্লিক করুন।
নিম্নলিখিত কাজগুলো করে আপনার পরীক্ষাটি সকল ব্যবহারকারীর কাছে চালু করুন:
- একটি Remote Config এক্সপেরিমেন্টের জন্য, কোন Remote Config প্যারামিটার ভ্যালুগুলো আপডেট করতে হবে তা নির্ধারণ করতে একটি ভ্যারিয়েন্ট নির্বাচন করুন। এক্সপেরিমেন্টটি তৈরি করার সময় সংজ্ঞায়িত টার্গেটিং ক্রাইটেরিয়া আপনার টেমপ্লেটে একটি নতুন শর্ত হিসাবে যুক্ত করা হয়, যাতে রোলআউটটি শুধুমাত্র এক্সপেরিমেন্ট দ্বারা টার্গেট করা ব্যবহারকারীদের প্রভাবিত করে। পরিবর্তনগুলো পর্যালোচনা করতে 'রিমোট কনফিগ-এ রিভিউ' ক্লিক করার পর, রোলআউটটি সম্পূর্ণ করতে 'পাবলিশ চেঞ্জেস'-এ ক্লিক করুন।

একটি পরীক্ষা প্রসারিত করুন

যদি আপনি দেখেন যে কোনো একটি পরীক্ষা থেকে সেরাটিকে ঘোষণা করার জন্য A/B Testing উদ্দেশ্যে যথেষ্ট ব্যবহারকারী আসছে না, তাহলে আপনি অ্যাপটির ব্যবহারকারী গোষ্ঠীর একটি বৃহত্তর অংশের কাছে পৌঁছানোর জন্য আপনার পরীক্ষাটির পরিধি বাড়াতে পারেন।

Firebase কনসোল নেভিগেশন মেনুর DevOps & Engagement বিভাগে, Remote Config ক্লিক করুন।
A/B টেস্ট ট্যাবে ক্লিক করুন।
যে চলমান পরীক্ষাটি আপনি সম্পাদনা করতে চান, সেটি নির্বাচন করুন।
এক্সপেরিমেন্ট ওভারভিউ- তে, কনটেক্সট মেনুতে ( ) ক্লিক করুন এবং তারপরে 'Edit running experiment'-এ ক্লিক করুন।
টার্গেটিং ডায়ালগটি চলমান এক্সপেরিমেন্টে থাকা ব্যবহারকারীদের শতাংশ বাড়ানোর একটি অপশন দেখায়। বর্তমান শতাংশের চেয়ে বেশি একটি সংখ্যা নির্বাচন করুন এবং পাবলিশ-এ ক্লিক করুন। আপনার নির্দিষ্ট করা ব্যবহারকারীদের শতাংশের কাছে এক্সপেরিমেন্টটি পৌঁছে দেওয়া হবে।

একটি পরীক্ষা নকল করুন

Firebase কনসোল নেভিগেশন মেনুর DevOps & Engagement বিভাগে, Remote Config ক্লিক করুন।
A/B টেস্ট ট্যাবে ক্লিক করুন।
যে চলমান বা সমাপ্ত পরীক্ষাটি আপনি বন্ধ করতে চান, সেটি নির্বাচন করুন।
Completed বা Running-এ ক্লিক করুন, আপনার এক্সপেরিমেন্টের উপর পয়েন্টারটি ধরে রাখুন, কনটেক্সট মেনুতে ( ) ক্লিক করুন, এবং তারপরে Duplicate experiment বা Stop experiment-এ ক্লিক করুন।

একটি পরীক্ষা বন্ধ করুন

Firebase কনসোল নেভিগেশন মেনুর DevOps & Engagement বিভাগে, Remote Config ক্লিক করুন।
A/B টেস্ট ট্যাবে ক্লিক করুন।
যে চলমান বা সমাপ্ত পরীক্ষাটি আপনি বন্ধ করতে চান, সেটি নির্বাচন করুন।
Completed বা Running-এ ক্লিক করুন, আপনার এক্সপেরিমেন্টের উপর পয়েন্টারটি ধরে রাখুন, কনটেক্সট মেনুতে ( ) ক্লিক করুন এবং তারপরে Stop experiment-এ ক্লিক করুন।

ওয়েব ক্লায়েন্ট শনাক্তকরণ এবং পরীক্ষার স্থায়িত্ব

যখন কোনো ব্যবহারকারী প্রথমবারের মতো ব্রাউজারে Firebase A/B Testing ব্যবহার করে একটি ওয়েব অ্যাপ্লিকেশন চালু করেন, তখন একটি অনন্য Firebase ইনস্টলেশন আইডি (FID) তৈরি হয়। সেশন জুড়ে অ্যাপ ইনস্ট্যান্সটিকে শনাক্ত করার জন্য এই FID-টি ব্রাউজারের IndexedDB-তে স্থায়ীভাবে সংরক্ষণ করা হয়।

Firebase A/B Testing ব্যবহারকারীদের এক্সপেরিমেন্ট ভ্যারিয়েন্টে অন্তর্ভুক্ত করতে এফআইডি (FID) ব্যবহার করে, এবং Google Analytics প্রতিটি ভ্যারিয়েন্টের মধ্যে ব্যবহারকারীর আচরণ পরিমাপ ও বিশ্লেষণ করার জন্য ইভেন্ট অ্যাগ্রিগেশনে এটি ব্যবহার করে।

যেহেতু FID ইনডেক্সডডিবি-তে সংরক্ষিত থাকে, তাই Firebase A/B Testing একজন ব্যবহারকারীকে নতুন ব্যবহারকারী হিসেবে গণ্য করে, যদি তিনি ভিন্ন কোনো ব্রাউজার থেকে বা ইনকগনিটো উইন্ডোতে আপনার অ্যাপ অ্যাক্সেস করেন, অথবা যদি তিনি তার ব্রাউজারের ইনডেক্সডডিবি মুছে ফেলেন। এর মানে হলো, ভিন্ন ভিন্ন ব্রাউজার বা ব্রাউজিং সেশন ব্যবহার করার সময় একজন ব্যবহারকারী ভিন্ন ভিন্ন এক্সপেরিমেন্ট ভ্যারিয়েন্টে অন্তর্ভুক্ত হতে পারেন।

ব্যবহারকারী টার্গেটিং

নিম্নলিখিত ব্যবহারকারী-লক্ষ্য নির্ধারণের মানদণ্ড ব্যবহার করে আপনি আপনার পরীক্ষায় অন্তর্ভুক্ত করার জন্য ব্যবহারকারীদের লক্ষ্য করতে পারেন।

Firebase কনসোলে নিম্নলিখিত নিয়মের প্রকারগুলি সমর্থিত। Remote Config REST API-তে সমতুল্য বৈশিষ্ট্যগুলি উপলব্ধ, যেমনটি কন্ডিশনাল এক্সপ্রেশন রেফারেন্সে বিস্তারিতভাবে বর্ণনা করা হয়েছে।

নিয়মের ধরণ	অপারেটর(গণ)	মান(গুলি)	দ্রষ্টব্য
অ্যাপ	==	আপনার ফায়ারবেস প্রজেক্টের সাথে যুক্ত অ্যাপগুলোর অ্যাপ আইডি-র তালিকা থেকে নির্বাচন করুন।	যখন আপনি Firebase-এ কোনো অ্যাপ যোগ করেন, তখন আপনাকে একটি বান্ডেল আইডি বা অ্যান্ড্রয়েড প্যাকেজ নেম লিখতে হয়, যা এমন একটি অ্যাট্রিবিউটকে সংজ্ঞায়িত করে, যা Remote Config রুলসে অ্যাপ আইডি হিসেবে প্রকাশিত হয়। এই অ্যাট্রিবিউটটি নিম্নরূপে ব্যবহার করুন: অ্যাপল প্ল্যাটফর্মের জন্য: অ্যাপটির CFBundleIdentifier ব্যবহার করুন। আপনি Xcode-এ আপনার অ্যাপের প্রাথমিক টার্গেটের General ট্যাবে Bundle Identifier-টি খুঁজে পাবেন। অ্যান্ড্রয়েডের জন্য: অ্যাপটির applicationId ব্যবহার করুন। আপনি আপনার অ্যাপ-লেভেলের `build.gradle(.kts)` ফাইলে `applicationId` খুঁজে পাবেন।
অ্যাপ সংস্করণ	স্ট্রিং মানের জন্য: হুবহু মিলে যায়, ধারণ করে, ধারণ করে না, রেগুলার এক্সপ্রেশন ধারণ করে সংখ্যাসূচক মানের জন্য: <, <=, =, !=, >, >=	আপনার অ্যাপের যে সংস্করণ(গুলি)কে লক্ষ্য করতে চান, তা নির্দিষ্ট করুন। এই নিয়মটি ব্যবহার করার আগে, আপনাকে অবশ্যই একটি অ্যাপ আইডি নিয়ম ব্যবহার করে আপনার ফায়ারবেস প্রজেক্টের সাথে যুক্ত একটি অ্যান্ড্রয়েড/অ্যাপল অ্যাপ নির্বাচন করতে হবে।	অ্যাপল প্ল্যাটফর্মের জন্য: অ্যাপটির CFBundleShortVersionString ব্যবহার করুন। দ্রষ্টব্য: নিশ্চিত করুন যে আপনার Apple অ্যাপটি Firebase Apple প্ল্যাটফর্ম SDK সংস্করণ 6.24.0 বা তার উচ্চতর সংস্করণ ব্যবহার করছে, কারণ পূর্ববর্তী সংস্করণগুলিতে CFBundleShortVersionString পাঠানো হয় না ( রিলিজ নোট দেখুন)। অ্যান্ড্রয়েডের জন্য: অ্যাপটির versionName ব্যবহার করুন। দ্রষ্টব্য: সংখ্যাসূচক তুলনা অপারেটর ( `<` , `<=` , `=` , `!=` , `>` , `>=` ) শুধুমাত্র সংখ্যাসূচক অর্থগত সংস্করণ (যেমন `1.2.3` ) সমর্থন করে। এগুলি প্রি-রিলিজ সাফিক্স বা হাইফেন (যেমন `-beta` বা `-rc` ) সমর্থন করে না। অ-সংখ্যাসূচক সাফিক্স বা হাইফেনযুক্ত সংস্করণ স্ট্রিংগুলির জন্য (যেমন `1.5-beta` ), পরিবর্তে স্ট্রিং অপারেটর ব্যবহার করুন (যেমন contains regular expression , contains , বা exactly matches )। এই নিয়মের ক্ষেত্রে স্ট্রিং তুলনা কেস-সেনসিটিভ। 'exactly matches' , ' contains ', 'does not contain' , বা 'contains' রেগুলার এক্সপ্রেশন অপারেটর ব্যবহার করার সময়, আপনি একাধিক মান নির্বাচন করতে পারেন। `contains` রেগুলার এক্সপ্রেশন অপারেটর ব্যবহার করে, আপনি RE2 ফরম্যাটে রেগুলার এক্সপ্রেশন তৈরি করতে পারেন। আপনার রেগুলার এক্সপ্রেশনটি টার্গেট ভার্সন স্ট্রিং-এর সম্পূর্ণ বা আংশিক অংশের সাথে মিলতে পারে। এছাড়াও, আপনি টার্গেট স্ট্রিং-এর শুরু, শেষ বা সম্পূর্ণ অংশের সাথে মেলানোর জন্য ` ^` এবং `$` অ্যাঙ্কর ব্যবহার করতে পারেন।
বিল্ড নম্বর	স্ট্রিং মানের জন্য: হুবহু মিলে যায়, ধারণ করে, ধারণ করে না, নিয়মিত অভিব্যক্তি সংখ্যাসূচক মানের জন্য: =, ≠, >, ≥, <, ≤	আপনার অ্যাপের যে বিল্ড(গুলি)কে টার্গেট করতে চান, তা নির্দিষ্ট করুন। এই নিয়মটি ব্যবহার করার আগে, আপনাকে অবশ্যই একটি অ্যাপ আইডি নিয়ম ব্যবহার করে আপনার ফায়ারবেস প্রজেক্টের সাথে যুক্ত একটি অ্যাপল বা অ্যান্ড্রয়েড অ্যাপ নির্বাচন করতে হবে।	এই অপারেটরটি শুধুমাত্র অ্যাপল এবং অ্যান্ড্রয়েড অ্যাপের জন্য উপলব্ধ। এটি অ্যাপলের ক্ষেত্রে অ্যাপের CFBundleVersion এবং অ্যান্ড্রয়েডের ক্ষেত্রে versionCode-এর সাথে সঙ্গতিপূর্ণ। এই নিয়মের জন্য স্ট্রিং তুলনা কেস-সেনসিটিভ। 'exactly matches ', ' contains ', 'does not contain ', বা 'contains' রেগুলার এক্সপ্রেশন অপারেটর ব্যবহার করার সময়, আপনি একাধিক মান নির্বাচন করতে পারেন। `contains` রেগুলার এক্সপ্রেশন অপারেটর ব্যবহার করে, আপনি RE2 ফরম্যাটে রেগুলার এক্সপ্রেশন তৈরি করতে পারেন। আপনার রেগুলার এক্সপ্রেশনটি টার্গেট ভার্সন স্ট্রিং-এর সম্পূর্ণ বা আংশিক অংশের সাথে মিলতে পারে। এছাড়াও, আপনি টার্গেট স্ট্রিং-এর শুরু, শেষ বা সম্পূর্ণ অংশের সাথে মেলানোর জন্য ` ^` এবং `$` অ্যাঙ্কর ব্যবহার করতে পারেন।
প্ল্যাটফর্ম	==	আইওএস অ্যান্ড্রয়েড ওয়েব
অপারেটিং সিস্টেম	==	লক্ষ্য করার জন্য অপারেটিং সিস্টেম(গুলি) নির্দিষ্ট করুন। এই নিয়মটি ব্যবহার করার আগে, আপনাকে অবশ্যই একটি অ্যাপ আইডি নিয়ম ব্যবহার করে আপনার ফায়ারবেস প্রজেক্টের সাথে যুক্ত একটি ওয়েব অ্যাপ নির্বাচন করতে হবে।	এই নিয়মটি কোনো নির্দিষ্ট ওয়েব অ্যাপ ইনস্ট্যান্সের জন্য `true` বলে বিবেচিত হবে, যদি অপারেটিং সিস্টেম এবং এর সংস্করণ নির্দিষ্ট তালিকার কোনো লক্ষ্য মানের সাথে মিলে যায়।
ব্রাউজার	==	যে ব্রাউজার(গুলি)কে লক্ষ্য করতে চান তা নির্দিষ্ট করুন। এই নিয়মটি ব্যবহার করার আগে, আপনাকে অবশ্যই একটি অ্যাপ আইডি নিয়ম ব্যবহার করে আপনার ফায়ারবেস প্রজেক্টের সাথে যুক্ত একটি ওয়েব অ্যাপ নির্বাচন করতে হবে।	কোনো নির্দিষ্ট ওয়েব অ্যাপ ইনস্ট্যান্সের ক্ষেত্রে এই নিয়মটি `true` বলে গণ্য হবে, যদি ব্রাউজার এবং তার সংস্করণ নির্দিষ্ট তালিকার কোনো লক্ষ্য মানের সাথে মিলে যায়।
ডিভাইসের বিভাগ	আছে, নেই	মোবাইল	এই নিয়মটি মূল্যায়ন করে যে আপনার ওয়েব অ্যাপ অ্যাক্সেসকারী ডিভাইসটি মোবাইল নাকি নন-মোবাইল (ডেস্কটপ বা কনসোল)। এই ধরনের নিয়ম শুধুমাত্র ওয়েব অ্যাপের জন্য উপলব্ধ।
ভাষা	ভিতরে আছে	এক বা একাধিক ভাষা নির্বাচন করুন।	এই নিয়মটি কোনো নির্দিষ্ট অ্যাপ ইনস্ট্যান্সের জন্য `true` বলে বিবেচিত হবে, যদি সেই অ্যাপ ইনস্ট্যান্সটি তালিকাভুক্ত ভাষাগুলোর মধ্যে কোনো একটি ব্যবহারকারী ডিভাইসে ইনস্টল করা থাকে।
দেশ/অঞ্চল	ভিতরে আছে	এক বা একাধিক অঞ্চল বা দেশ নির্বাচন করুন।	এই নিয়মটি একটি নির্দিষ্ট অ্যাপ ইনস্ট্যান্সের জন্য `true` বলে বিবেচিত হবে, যদি ইনস্ট্যান্সটি তালিকাভুক্ত কোনো অঞ্চল বা দেশে থাকে। ডিভাইসের কান্ট্রি কোডটি অনুরোধে থাকা ডিভাইসের আইপি অ্যাড্রেস ব্যবহার করে অথবা ফায়ারবেস অ্যানালিটিক্স দ্বারা নির্ধারিত কান্ট্রি কোড ব্যবহার করে নির্ণয় করা হয় (যদি অ্যানালিটিক্স ডেটা ফায়ারবেসের সাথে শেয়ার করা হয়)।
ব্যবহারকারী দর্শক(গণ)	অন্তত একটি অন্তর্ভুক্ত	আপনার প্রোজেক্টের জন্য সেট আপ করা Google Analytics অডিয়েন্সের তালিকা থেকে এক বা একাধিক নির্বাচন করুন।	এই নিয়মটি আপনার Firebase প্রজেক্টের সাথে যুক্ত একটি অ্যাপ নির্বাচন করার জন্য একটি অ্যাপ আইডি নিয়মের প্রয়োজন। দ্রষ্টব্য: যেহেতু অনেক Analytics অডিয়েন্স ইভেন্ট বা ব্যবহারকারীর বৈশিষ্ট্যের উপর ভিত্তি করে সংজ্ঞায়িত করা হয়, যা অ্যাপ ব্যবহারকারীদের কার্যকলাপের উপর নির্ভর করতে পারে, তাই একটি নির্দিষ্ট অ্যাপ ইনস্ট্যান্সের জন্য 'ইউজার ইন অডিয়েন্স' নিয়মটি কার্যকর হতে কিছুটা সময় লাগতে পারে। এর মানে হলো, কোনো ব্যবহারকারী প্রযুক্তিগতভাবে একটি অডিয়েন্সের জন্য যোগ্য হলেও, যদি `fetchAndActivate()` কার্যকর হওয়ার সময় Analytics সেই ব্যবহারকারীকে অডিয়েন্সে যুক্ত না করে থাকে, তবে ব্যবহারকারীটি শর্তটির সাথে মিলবে না।
ব্যবহারকারীর সম্পত্তি	স্ট্রিং মানের জন্য: ধারণ করে, ধারণ করে না, হুবহু মিলে যায়, রেগুলার এক্সপ্রেশন ধারণ করে সংখ্যাসূচক মানের জন্য: =, ≠, >, ≥, <, ≤ দ্রষ্টব্য: ক্লায়েন্টে, আপনি ইউজার প্রপার্টির জন্য শুধুমাত্র স্ট্রিং ভ্যালু সেট করতে পারবেন। যেসব কন্ডিশনে নিউমেরিক অপারেটর ব্যবহৃত হয়, Remote Config সংশ্লিষ্ট ইউজার প্রপার্টির ভ্যালুকে একটি ইন্টিজার/ফ্লোটে রূপান্তর করে।	উপলব্ধ Google Analytics ব্যবহারকারী বৈশিষ্ট্যগুলির তালিকা থেকে নির্বাচন করুন।	আপনার ব্যবহারকারী গোষ্ঠীর খুব নির্দিষ্ট অংশের জন্য কীভাবে ইউজার প্রোপার্টি ব্যবহার করে আপনার অ্যাপকে কাস্টমাইজ করতে পারেন, তা জানতে Remote Config এবং ইউজার প্রোপার্টি দেখুন। ব্যবহারকারীর বৈশিষ্ট্য সম্পর্কে আরও জানতে, নিম্নলিখিত নির্দেশিকাগুলি দেখুন: অ্যাপলে ব্যবহারকারীর বৈশিষ্ট্য সেট করুন অ্যান্ড্রয়েডে ব্যবহারকারীর বৈশিষ্ট্য সেট করুন 'exactly matches ', ' contains ', ' does not contain ' বা 'contains' রেগুলার এক্সপ্রেশন অপারেটর ব্যবহার করার সময়, আপনি একাধিক মান নির্বাচন করতে পারেন। `contains` রেগুলার এক্সপ্রেশন অপারেটর ব্যবহার করে, আপনি RE2 ফরম্যাটে রেগুলার এক্সপ্রেশন তৈরি করতে পারেন। আপনার রেগুলার এক্সপ্রেশনটি টার্গেট ভার্সন স্ট্রিং-এর সম্পূর্ণ বা আংশিক অংশের সাথে মিলতে পারে। এছাড়াও, আপনি টার্গেট স্ট্রিং-এর শুরু, শেষ বা সম্পূর্ণ অংশের সাথে মেলানোর জন্য ` ^` এবং `$` অ্যাঙ্কর ব্যবহার করতে পারেন। দ্রষ্টব্য: Remote Config শর্ত তৈরি করার সময় স্বয়ংক্রিয়ভাবে সংগৃহীত ব্যবহারকারী বৈশিষ্ট্যগুলি উপলব্ধ থাকে না।
ব্যবহারকারী এলোমেলো শতাংশে	স্লাইডার (ফায়ারবেস কনসোলে। REST API-তে `<=` , `>` , এবং `between` অপারেটরগুলো ব্যবহৃত হয়)।	০-১০০	এই ফিল্ডটি ব্যবহার করে অ্যাপ ইনস্ট্যান্সের একটি র‍্যান্ডম স্যাম্পলে (স্যাম্পলের আকার .০০০১% এর মতো ছোট হলেও) কোনো পরিবর্তন প্রয়োগ করুন এবং স্লাইডার উইজেট ব্যবহার করে এলোমেলোভাবে সাজানো ব্যবহারকারীদের (অ্যাপ ইনস্ট্যান্স) বিভিন্ন গ্রুপে বিভক্ত করুন। প্রতিটি অ্যাপ ইনস্ট্যান্সকে সেই প্রজেক্টে সংজ্ঞায়িত একটি সিড অনুসারে একটি র‍্যান্ডম পূর্ণ বা ভগ্নাংশ সংখ্যার সাথে স্থায়ীভাবে ম্যাপ করা হয়। সিড ভ্যালুতে এক থেকে ৩২টি অক্ষর থাকতে পারে, যেগুলোতে অ্যালফানিউমেরিক মান, ডট, হাইফেন এবং/অথবা আন্ডারস্কোর অন্তর্ভুক্ত থাকবে। আপনি সিড ভ্যালুটি পরিবর্তন না করলে, একটি রুল ডিফল্ট কী ব্যবহার করবে (যা Firebase কনসোলে ' এডিট সিড ' হিসেবে দেখানো হয়)। 'সিড' ফিল্ডটি খালি করে আপনি রুলটিকে আবার ডিফল্ট কী ব্যবহারে ফিরিয়ে আনতে পারেন। প্রদত্ত শতাংশ পরিসরের মধ্যে ধারাবাহিকভাবে একই অ্যাপ ইনস্ট্যান্সগুলিকে সম্বোধন করতে, সমস্ত শর্ত জুড়ে একই সীড মান ব্যবহার করুন। অথবা, একটি নতুন সীড নির্দিষ্ট করে একটি প্রদত্ত শতাংশ পরিসরের জন্য অ্যাপ ইনস্ট্যান্সগুলির একটি নতুন এলোমেলোভাবে নির্ধারিত গোষ্ঠী নির্বাচন করুন। উদাহরণস্বরূপ, দুটি সম্পর্কিত শর্ত তৈরি করতে, যেগুলোর প্রতিটি একটি অ্যাপের ব্যবহারকারীদের এমন ৫% অংশের উপর প্রযোজ্য হবে যারা একে অপরের সাথে ওভারল্যাপ করবে না, আপনি একটি শর্তকে ০% থেকে ৫% এর মধ্যে একটি শতাংশের সাথে মেলানোর জন্য এবং অন্য শর্তটিকে ৫% থেকে ১০% এর মধ্যে একটি পরিসরের সাথে মেলানোর জন্য কনফিগার করতে পারেন। কিছু ব্যবহারকারীকে এলোমেলোভাবে উভয় গ্রুপে অন্তর্ভুক্ত করার সুযোগ দিতে, প্রতিটি শর্তের ভেতরের নিয়মগুলোর জন্য ভিন্ন ভিন্ন সিড ভ্যালু ব্যবহার করুন।
আমদানিকৃত অংশ	ভিতরে আছে	এক বা একাধিক আমদানিকৃত সেগমেন্ট নির্বাচন করুন।	এই নিয়মটির জন্য কাস্টম ইম্পোর্টেড সেগমেন্ট সেট আপ করা প্রয়োজন।
তারিখ/সময়	আগে, পরে	একটি নির্দিষ্ট তারিখ ও সময়, যা ডিভাইসের টাইমজোনে অথবা কোনো নির্দিষ্ট টাইমজোনে হতে পারে, যেমন "(GMT+11) সিডনি টাইম"।	বর্তমান সময়ের সাথে ডিভাইস থেকে ডেটা আনার সময়ের তুলনা করা হয়।
প্রথম খোলা	আগে, পরে	ব্যবহারকারীরা প্রথমবার আপনার অ্যাপ খোলার উপর ভিত্তি করে তাদের টার্গেট করুন: ভবিষ্যতের একটি নির্দিষ্ট তারিখ ও সময়ের পরে যারা প্রথমবার আপনার অ্যাপটি খুলবে, সেইসব ব্যবহারকারীদের টার্গেট করতে 'নতুন ব্যবহারকারী' নির্বাচন করুন। আপনার নির্দিষ্ট করা তারিখ ও সময়ের আগে বা পরে, যেসব ব্যবহারকারী প্রথমবার আপনার অ্যাপটি খোলেন, তাদের টার্গেট করতে সময়সীমা নির্বাচন করুন। একটি নির্দিষ্ট সময়সীমার মধ্যে ব্যবহারকারীদের টার্গেট করতে ' আগে ' এবং ' পরে' শর্তগুলো একত্রিত করুন।	একটি অ্যান্ড্রয়েড, আইওএস বা ওয়েব অ্যাপ নির্বাচন করার পর, প্রথমবার খোলার ভিত্তিতে ব্যবহারকারীকে লক্ষ্য করার সুবিধাটি উপলব্ধ হয়। নিম্নলিখিত SDK-গুলো প্রয়োজন: Google Analytics জন্য ফায়ারবেস এসডিকে অ্যাপল প্ল্যাটফর্ম এসডিকে ভি৯.০.০+ অথবা অ্যান্ড্রয়েড এসডিকে ভি২১.১.১+ ( Firebase BoM ৩০.৩.০+), এবং জাভাস্ক্রিপ্ট এসডিকে ভি১২.৮.০+। প্রথম ওপেন ইভেন্টের সময় ক্লায়েন্টে Analytics সক্রিয় করা থাকতে হবে।
ইনস্টলেশন আইডি	ভিতরে আছে	লক্ষ্য করার জন্য এক বা একাধিক (সর্বোচ্চ ৫০টি) ইনস্টলেশন আইডি নির্দিষ্ট করুন।	এই নিয়মটি কোনো নির্দিষ্ট ইনস্টলেশনের জন্য `true` বলে বিবেচিত হবে, যদি সেই ইনস্টলেশনের আইডিটি কমা দ্বারা পৃথক করা মানগুলির তালিকায় থাকে। কীভাবে ইনস্টলেশন আইডি পেতে পারেন তা জানতে, ‘ক্লায়েন্ট শনাক্তকারী পুনরুদ্ধার করুন’ দেখুন।
ব্যবহারকারী বিদ্যমান	(কোন অপারেটর নেই)	বর্তমান প্রকল্পের অন্তর্গত সমস্ত অ্যাপের সকল ব্যবহারকারীকে লক্ষ্য করে।	অ্যাপ বা প্ল্যাটফর্ম নির্বিশেষে, প্রোজেক্টের অন্তর্গত সকল ব্যবহারকারীকে মেলানোর জন্য এই শর্ত নিয়মটি ব্যবহার করুন। Remote Config পার্সোনালাইজেশন ব্যবহার করার সময়, প্রোজেক্টের অন্তর্ভুক্ত সকল ব্যবহারকারী যেন পার্সোনালাইজড ভ্যালু পায়, তা নিশ্চিত করতে আপনি এই অপারেটরটি ব্যবহার করতে পারেন।
কাস্টম সংকেত	স্ট্রিং মানের জন্য: ধারণ করে, ধারণ করে না, হুবহু মিলে যায়, রেগুলার এক্সপ্রেশন ধারণ করে সংখ্যাসূচক মানের জন্য: =, ≠, >, ≥, <, ≤ সংস্করণ মানগুলির জন্য: =, ≠, >, ≥, <, ≤	এই নিয়মের জন্য স্ট্রিং তুলনা কেস-সেনসিটিভ। এক্স্যাক্টলি ম্যাচ, কন্টেইন, ডাজ নট কন্টেইন, বা কন্টেইন রেগুলার এক্সপ্রেশন অপারেটর ব্যবহার করার সময়, আপনি একাধিক মান নির্বাচন করতে পারেন। কন্টেইন রেগুলার এক্সপ্রেশন অপারেটর ব্যবহার করার সময়, আপনি RE2 ফরম্যাটে রেগুলার এক্সপ্রেশন তৈরি করতে পারেন। আপনার রেগুলার এক্সপ্রেশন টার্গেট ভার্সন স্ট্রিং-এর সম্পূর্ণ বা আংশিক অংশের সাথে মিলতে পারে। এছাড়াও আপনি একটি টার্গেট স্ট্রিং-এর শুরু, শেষ বা সম্পূর্ণ অংশের সাথে মিলানোর জন্য ^ এবং $ অ্যাঙ্কর ব্যবহার করতে পারেন। ক্লায়েন্ট পরিবেশের জন্য নিম্নলিখিত ডেটা টাইপগুলি সমর্থিত: iOS: int, double অ্যান্ড্রয়েড: int, long, double ওয়েব: সংখ্যা যে সংখ্যাটি মেলাতে হবে এমন সংস্করণ নম্বর(গুলি) নির্দেশ করে (উদাহরণস্বরূপ, ২.১.০)।	কাস্টম সিগন্যাল কন্ডিশন এবং ব্যবহারযোগ্য কন্ডিশনাল এক্সপ্রেশন সম্পর্কে আরও তথ্যের জন্য, কাস্টম সিগন্যাল কন্ডিশন এবং কন্ডিশন তৈরিতে ব্যবহৃত উপাদানসমূহ দেখুন।

দ্রষ্টব্য: Analytics ব্যবহারকারী অডিয়েন্সকে লক্ষ্য করে পরিচালিত এক্সপেরিমেন্টগুলো Analytics ডেটা প্রসেসিং ল্যাটেন্সির অধীন। কোনো ব্যবহারকারী প্রযুক্তিগতভাবে কোনো অডিয়েন্সের জন্য যোগ্য হলেও, যদি fetchAndActivate() এক্সিকিউট হওয়ার সময় Analytics সেই ব্যবহারকারীকে অডিয়েন্সে যুক্ত না করে থাকে, তবে তাকে এক্সপেরিমেন্টে অন্তর্ভুক্ত করা হবে না।

A/B Testing মেট্রিক্স

যখন আপনি আপনার এক্সপেরিমেন্ট তৈরি করেন, তখন আপনি একটি প্রাথমিক বা লক্ষ্য মেট্রিক বেছে নেন, যা বিজয়ী ভ্যারিয়েন্ট নির্ধারণ করতে ব্যবহৃত হয়। প্রতিটি এক্সপেরিমেন্ট ভ্যারিয়েন্টের পারফরম্যান্স আরও ভালোভাবে বুঝতে এবং প্রতিটি ভ্যারিয়েন্টের জন্য ভিন্ন হতে পারে এমন গুরুত্বপূর্ণ ট্রেন্ডগুলো ট্র্যাক করতে আপনার অন্যান্য মেট্রিকগুলোও ট্র্যাক করা উচিত, যেমন ব্যবহারকারী ধরে রাখা, অ্যাপের স্থিতিশীলতা এবং ইন-অ্যাপ পারচেজ থেকে আয়। আপনি আপনার এক্সপেরিমেন্টে সর্বোচ্চ পাঁচটি অ-লক্ষ্য মেট্রিক ট্র্যাক করতে পারেন।

উদাহরণস্বরূপ, ধরুন আপনি আপনার অ্যাপে দুটি ভিন্ন গেম ফ্লো চালু করতে Remote Config ব্যবহার করছেন এবং ইন-অ্যাপ পারচেজ ও বিজ্ঞাপন থেকে আয়ের জন্য অপটিমাইজ করতে চান, কিন্তু একই সাথে প্রতিটি ভ্যারিয়েন্টের স্থিতিশীলতা এবং ইউজার রিটেনশনও ট্র্যাক করতে চান। এই ক্ষেত্রে, আপনি আপনার গোল মেট্রিক হিসেবে ‘Estimated total revenue’ বেছে নেওয়ার কথা ভাবতে পারেন, কারণ এতে ইন-অ্যাপ পারচেজ থেকে আয় এবং বিজ্ঞাপন থেকে আয় অন্তর্ভুক্ত থাকে। এরপর, ‘Other metrics to track’-এর জন্য আপনি নিম্নলিখিত বিষয়গুলো যোগ করতে পারেন:

আপনার দৈনিক এবং সাপ্তাহিক ব্যবহারকারী ধরে রাখার হার ট্র্যাক করতে, রিটেনশন (২-৩ দিন) এবং রিটেনশন (৪-৭ দিন) যোগ করুন।
দুটি গেম ফ্লো-এর মধ্যে স্থিতিশীলতা তুলনা করতে, ক্র্যাশ-মুক্ত ব্যবহারকারীদের যুক্ত করুন।
প্রতিটি রাজস্বের ধরণ সম্পর্কে আরও বিস্তারিত তথ্য দেখতে, 'ক্রয় রাজস্ব' এবং 'আনুমানিক বিজ্ঞাপন রাজস্ব' যোগ করুন।

নিম্নলিখিত সারণিগুলোতে লক্ষ্যমাত্রা মেট্রিক এবং অন্যান্য মেট্রিকগুলো কীভাবে গণনা করা হয়, সে সম্পর্কে বিস্তারিত তথ্য দেওয়া হয়েছে।

লক্ষ্য মেট্রিক্স

মেট্রিক	বর্ণনা
ক্র্যাশ-মুক্ত ব্যবহারকারীরা	পরীক্ষার সময় Firebase Crashlytics SDK দ্বারা শনাক্ত হওয়া ত্রুটিগুলো আপনার অ্যাপে পাননি এমন ব্যবহারকারীর শতকরা হার। দ্রষ্টব্য: ওয়েব অ্যাপ্লিকেশনের জন্য Firebase Crashlytics সমর্থিত নয়।
আনুমানিক বিজ্ঞাপন আয়	আনুমানিক বিজ্ঞাপন আয়।
আনুমানিক মোট রাজস্ব	ক্রয়মূল্য এবং আনুমানিক বিজ্ঞাপন রাজস্বের সম্মিলিত মান।
ক্রয় রাজস্ব	সমস্ত `purchase` এবং `in_app_purchase` ইভেন্টের সম্মিলিত মান।
ধরে রাখা (১ দিন)	যেসব ব্যবহারকারী প্রতিদিন আপনার অ্যাপে ফিরে আসেন, তাদের সংখ্যা।
ধরে রাখার হার (২-৩ দিন)	যেসব ব্যবহারকারী ২-৩ দিনের মধ্যে আপনার অ্যাপে ফিরে আসেন, তাদের সংখ্যা।
ধরে রাখার হার (৪-৭ দিন)	যেসব ব্যবহারকারী ৪-৭ দিনের মধ্যে আপনার অ্যাপে ফিরে আসেন, তাদের সংখ্যা।
ধরে রাখার হার (৮-১৪ দিন)	যেসব ব্যবহারকারী ৮-১৪ দিনের মধ্যে আপনার অ্যাপে ফিরে আসেন, তাদের সংখ্যা।
ধরে রাখা (১৫+ দিন)	যেসব ব্যবহারকারী শেষবার অ্যাপটি ব্যবহার করার ১৫ বা তার বেশি দিন পর আবার ফিরে আসেন, তাদের সংখ্যা।
প্রথম_খোলা	একটি Analytics ইভেন্ট যা কোনো ব্যবহারকারী অ্যাপটি ইনস্টল বা রিইনস্টল করার পর প্রথমবার খুললে ট্রিগার হয়। এটি কনভার্সন ফানেলের অংশ হিসেবে ব্যবহৃত হয়।

অন্যান্য মেট্রিক

মেট্রিক	বর্ণনা
বিজ্ঞপ্তি_বাতিল করুন	একটি Analytics ইভেন্ট যা নোটিফিকেশন কম্পোজার দ্বারা প্রেরিত কোনো নোটিফিকেশন খারিজ করা হলে ট্রিগার হয় (শুধুমাত্র অ্যান্ড্রয়েডের জন্য)।
বিজ্ঞপ্তি_গ্রহণ	একটি Analytics ইভেন্ট যা তখন ট্রিগার হয় যখন অ্যাপটি ব্যাকগ্রাউন্ডে থাকা অবস্থায় নোটিফিকেশন কম্পোজার দ্বারা পাঠানো কোনো নোটিফিকেশন পাওয়া যায় (শুধুমাত্র অ্যান্ড্রয়েডের জন্য)।
ওএস_আপডেট	একটি Analytics ইভেন্ট যা ট্র্যাক করে কখন ডিভাইসের অপারেটিং সিস্টেম একটি নতুন সংস্করণে আপডেট করা হয়। আরও জানতে, স্বয়ংক্রিয়ভাবে সংগৃহীত ইভেন্টসমূহ দেখুন। এই মেট্রিকটি ওয়েব অ্যাপ্লিকেশনের জন্য সমর্থিত নয়।
স্ক্রিন_ভিউ	একটি Analytics ইভেন্ট যা আপনার অ্যাপের মধ্যে দেখা স্ক্রিনগুলো ট্র্যাক করে। আরও জানতে, ‘স্ক্রিনভিউ ট্র্যাক করুন’ দেখুন।
সেশন_শুরু	একটি Analytics ইভেন্ট যা আপনার অ্যাপে ব্যবহারকারীর সেশন গণনা করে। আরও জানতে, স্বয়ংক্রিয়ভাবে সংগৃহীত ইভেন্টসমূহ দেখুন।

BigQuery ডেটা রপ্তানি

Firebase কনসোলে A/B Testing এক্সপেরিমেন্টের ডেটা দেখার পাশাপাশি, আপনি 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 এর ফলাফল স্বাধীনভাবে যাচাই করার ক্ষমতা দেয়।

শুরু করার জন্য, এই নির্দেশিকায় বর্ণিত অনুযায়ী নিম্নলিখিতগুলি সম্পূর্ণ করুন:

Firebase কনসোলে Google Analytics জন্য BigQuery এক্সপোর্ট সক্রিয় করুন।
BigQuery ব্যবহার করে A/B Testing ডেটা অ্যাক্সেস করুন
উদাহরণ কোয়েরিগুলি অন্বেষণ করুন

Firebase কনসোলে Google Analytics জন্য BigQuery এক্সপোর্ট সক্রিয় করুন।

আপনি যদি Spark প্ল্যানে থাকেন, তাহলে Sandbox-এর সীমাবদ্ধতা সাপেক্ষে কোনো খরচ ছাড়াই BigQuery অ্যাক্সেস করতে BigQuery স্যান্ডবক্স ব্যবহার করতে পারবেন। আরও তথ্যের জন্য মূল্য নির্ধারণ এবং BigQuery স্যান্ডবক্স দেখুন।

প্রথমে, নিশ্চিত করুন যে আপনি আপনার Analytics ডেটা BigQuery তে এক্সপোর্ট করছেন।

Firebase কনসোলে, এখানে যান > ইন্টিগ্রেশন ট্যাব ।
BigQuery কার্ডে, Manage-এ ক্লিক করুন এবং যাচাই করুন যে আপনার প্রজেক্টটি BigQuery তে Analytics ডেটা এক্সপোর্ট করছে।
যদি কার্ডটিতে ‘লিঙ্ক’ লেখা থাকে, তাহলে আপনাকে এক্সপোর্ট সেট আপ করতে হবে (পরবর্তী ধাপে যান)।
যদি আপনার রপ্তানি সেট আপ করার প্রয়োজন হয়:
1. Firebase-কে BigQuery এর সাথে লিঙ্ক করার বিষয়ে পর্যালোচনা করুন, তারপর Next-এ ক্লিক করুন।
2. ইন্টিগ্রেশন কনফিগার করুন বিভাগে Google Analytics সক্রিয় করুন।
3. একটি অঞ্চল নির্বাচন করুন এবং রপ্তানি সেটিংস বেছে নিন।
  দ্রষ্টব্য: Google Analytics for Firebase সেটিংস সম্পর্কে আরও তথ্যের জন্য, ডেটা সংগ্রহ দেখুন।
4. BigQuery তে যেতে লিঙ্কে ক্লিক করুন।

আপনি কীভাবে ডেটা এক্সপোর্ট করেছেন তার উপর নির্ভর করে, টেবিলগুলো উপলব্ধ হতে একদিন পর্যন্ত সময় লাগতে পারে। BigQuery তে প্রোজেক্ট ডেটা এক্সপোর্ট করার বিষয়ে আরও তথ্যের জন্য, BigQuery তে প্রোজেক্ট ডেটা এক্সপোর্ট করুন" দেখুন।

BigQuery তে A/B Testing ডেটা অ্যাক্সেস করুন

কোনো নির্দিষ্ট পরীক্ষার ডেটার জন্য কোয়েরি করার আগে, আপনার কোয়েরিতে ব্যবহারের জন্য নিম্নলিখিতগুলির কয়েকটি বা সবগুলি সংগ্রহ করতে হবে:

এক্সপেরিমেন্ট আইডি: আপনি এক্সপেরিমেন্ট ওভারভিউ পেজের URL থেকে এটি পেতে পারেন। উদাহরণস্বরূপ, যদি আপনার URL দেখতে https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25 এর মতো হয়, তাহলে এক্সপেরিমেন্ট আইডি হবে 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:

In the Google Cloud console, go to BigQuery .
Select your project, then select Create SQL query .
Add your query. For example queries to run, see Explore example queries .
Click 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:

In the Firebase console, go to DevOps & Engagement > A/B Testing .
Select the A/B Testing experiment you want to query to open the Experiment overview .
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:

Create your experiment.
Manage your experiment.

Create an experiment

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

Verify that Google Analytics is enabled in your project so that the experiment has access to Analytics data.
If you didn't enable Google Analytics when creating your project, you can enable it in the Settings > Integrations tab of the Firebase console.
In the Firebase console, go to DevOps & Engagement > A/B Testing
Click Create experiment , and then select Remote Config when prompted for the service you want to experiment with.
In the Variants section, choose a baseline and at least one variant for the experiment. You can add one or more parameters to experiment with. You can repeat this step to add multiple parameters to your experiment.
(optional) To add more than one variant to your experiment, click Add another variant .
Change one or more parameters for specific variants. Any unchanged parameters are the same for users not included in the experiment.
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 .
Define the Targeting criteria for your experiment using Remote Config conditions:
- Reuse an existing condition: If an existing condition in your Remote Config template already matches your target audience, select it from the list.
  Important: If you reuse an existing condition for an experiment, you cannot edit that condition until the experiment has completed or stopped . Modifying a shared condition while an experiment is actively running can alter variant assignment and invalidate experiment measurements.
- Verify condition evaluation order: Make sure your conditions on the Conditions page are organized in the correct priority order. Because Remote Config evaluates conditions sequentially from top to bottom, other higher-priority condition(s) can prevent sufficient users from reaching the condition associated with your experiment.
- Create a new condition: If no existing condition satisfies your targeting requirements, or if you prefer to duplicate an existing condition (for example, to avoid locking a condition that is shared by other parameters), create a new condition by first choosing the app that uses your experiment. If the parameter you are testing also uses the existing (or another overlapping) condition, make sure the new experiment condition is placed above the existing condition on the Conditions tab (giving it higher evaluation priority); otherwise, users will match the existing condition first and won't flow into the experiment.
  You can then target a specific subset of users by clicking and and selecting one or more options from the following list:
  - Version: One or more versions of your app
  - Build number: The build number (Apple) or version code (Android) of your app
  - Platform: One or more platforms (iOS, Android, or Web) to target
  - Operating system: Target web app users based on their operating system and version
  - Browser: Target web app users based on their web browser and browser version
  - Device category: Target web app users based on whether their device is mobile or non-mobile
  - 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
  - User in random percentage: Target a randomly selected percentage of users within a defined percentile range
  - Imported segment: Target users who belong to custom imported segments uploaded to your project
  - Date/Time: Target users based on a specified date and time window
  - First open: Target users based on the first time they ever opened your app
  - Installation ID: Target specific test devices or client instances using their Firebase Installation IDs (FIDs)
  - User exists: Target all users across all apps in the project
  - Custom signal: Target users based on custom client-side key-value signals passed at runtime
Note: Due to Google Analytics data processing latency , experiments that target Analytics user audiences may require more time to accumulate data. To learn more about this and other targeting options, see User targeting .
Set the Exposure: 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% and 100%. Users are randomly assigned to each experiment, including duplicated experiments.
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.
Note: Activation events are not supported for A/B Testing web implementations.
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
The Analytics event you select as the activation event must not also be used as the primary metric (or as an additional metric) in the same experiment. Doing so will trigger a validation error in the Firebase console and prevent your experiment from launching.
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. When finished, click Next .
Click Save to save your experiment. You must publish the template to start running your experiment.

You are allowed up to 300 experiments per project (including rollouts), which could consist of up to 24 running experiments and rollouts, with the rest as completed experiments.

Manage your experiment

When you create an experiment with Remote Config , you can 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.

Edit an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Click Running , click an experiment that you want to edit.
Click the context menu ( ) and click Edit running experiment .
To validate that your app has users who would be included in your experiment, expand the details and check for a number greater than 0% in the Targeting and distribution section (for example, 1% of users matching the criteria ).

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.

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Click Running , and then click, 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."
After your experiment has run for a while (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.

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Click Completed or Running , click an experiment that you want to release to all users, click the context menu ( ) Roll out variant .
Roll out your experiment to all users by doing the following:
- 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.

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.

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Select the running experiment that you want to edit.
In the Experiment overview , click the context menu ( ), and then click Edit running experiment .
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 an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Select the running or completed experiment that you want to stop.
Click Completed or Running , hold the pointer over your experiment, click the context menu ( ), and then click Duplicate experiment or Stop experiment .

Stop an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Select the running or completed experiment that you want to stop.
Click Completed or Running , hold the pointer over your experiment, click the context menu ( ), and then click Stop experiment .

Web client identification and experiment persistence

When a user launches a web application using Firebase A/B Testing in a browser for the first time, a unique Firebase installation ID ( FID) is generated. This FID is persistently stored in the browser's IndexedDB to identify the app instance across sessions.

Firebase A/B Testing uses the FID to assign users to experiment variants, and Google Analytics uses it for event aggregation to measure and analyze user behavior within each variant.

Because the FID is stored in IndexedDB, Firebase A/B Testing treats a user as a new user if they access your app from a different browser or in an incognito window, or if they clear their browser's IndexedDB. This means that a user might be included in different experiment variants when using different browsers or browsing sessions.

User targeting

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

The following rule types are supported in the Firebase console. Equivalent features are available in the Remote Config REST API, as detailed in the conditional expression reference .

Rule type	অপারেটর(গণ)	Value(s)	দ্রষ্টব্য
App	==	Select from a list of App IDs for apps associated with your Firebase project.	When you add an app to Firebase, you enter a bundle ID or Android package name that defines an attribute that's exposed as App ID in Remote Config rules. Use this attribute as follows: For Apple platforms: Use the app's CFBundleIdentifier . You can find the Bundle Identifier in the General tab for your app's primary target in Xcode. For Android: Use the app's applicationId . You can find the `applicationId` in your app-level `build.gradle(.kts)` file.
App version	For string values: exactly matches, contains, does not contain, contains regular expression For numeric values: <, <=, =, !=, >, >=	Specify the version(s) of your app to target. Before using this rule, you must use an App ID rule to select an Android/Apple app associated with your Firebase project.	For Apple platforms: Use the app's CFBundleShortVersionString . Note: Make sure your Apple app is using Firebase Apple platforms SDK version 6.24.0 or higher, as CFBundleShortVersionString is not being sent in earlier versions (see release notes ). For Android: Use the app's versionName . Note: Numeric comparison operators ( `<` , `<=` , `=` , `!=` , `>` , `>=` ) support only numeric semantic versions (such as `1.2.3` ). They do not support pre-release suffixes or hyphens (such as `-beta` or `-rc` ). For version strings with non-numeric suffixes or hyphens (such as `1.5-beta` ), use string operators instead (such as contains regular expression , contains , or exactly matches ). String comparisons for this rule are case-sensitive. When using the exactly matches , contains , does not contain , or contains regular expression operator, you can select multiple values. When using the contains regular expression 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.
Build number	For string values: exactly matches, contains, does not contain, regular expression For numeric values: =, ≠, >, ≥, <, ≤	Specify the build(s) of your app to target. Before using this rule, you must use an App ID rule to select an Apple or Android app associated with your Firebase project.	This operator is available for Apple and Android apps only. It corresponds to the app's CFBundleVersion for Apple and versionCode for Android. String comparisons for this rule are case-sensitive. When using the exactly matches , contains , does not contain , or contains regular expression operator, you can select multiple values. When using the contains regular expression 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.
প্ল্যাটফর্ম	==	আইওএস অ্যান্ড্রয়েড ওয়েব
অপারেটিং সিস্টেম	==	Specify the operating system(s) to target. Before using this rule, you must use an App ID rule to select a Web app associated with your Firebase project.	This rule evaluates to `true` for a given Web app instance if the operating system and its version matches a target value in the specified list.
ব্রাউজার	==	Specify the browser(s) to target. Before using this rule, you must use an App ID rule to select a Web app associated with your Firebase project.	This rule evaluates to `true` for a given Web app instance if the browser and its version matches a target value in the specified list.
Device category	is, is not	মোবাইল	This rule evaluates whether the device accessing your web app is mobile or non-mobile (desktop or console). This rule type is only available for web apps.
ভাষা	ভিতরে আছে	Select one or more languages.	This rule evaluates to `true` for a given app instance if that app instance is installed on a device that uses one of the languages listed.
Country/Region	ভিতরে আছে	Select one or more regions or countries.	This rule evaluates to `true` for a given app instance if the instance is in any of the regions or countries listed. The device country code is determined using the device's IP address in the request or the country code determined by Firebase Analytics (if Analytics data is shared with Firebase).
User audience(s)	Includes at least one	Select one or more from a list of Google Analytics audiences that you have set up for your project.	This rule requires an App ID rule to select an app associated with your Firebase project. Note: Because many Analytics audiences are defined by events or user properties, which can be based on the actions of app users, it may take some time for a User in audience rule to take effect for a given app instance. 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 won't match the condition.
User property	For string values: contains, does not contain, exactly matches, contains regular expression For numeric values: =, ≠, >, ≥, <, ≤ Note: On the client, you can set only string values for user properties. For conditions that use numeric operators, Remote Config converts the value of the corresponding user property into an integer/float.	Select from a list of available Google Analytics user properties.	To learn how you can use user properties to customize your app for very specific segments of your user base, see Remote Config and user properties . To learn more about user properties, see the following guides: Set user properties on Apple Set user properties on Android When using the exactly matches , contains , does not contain or contains regular expression operator, you can select multiple values. When using the contains regular expression 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. Note: Automatically collected user properties are not available when creating Remote Config conditions.
User in random percentage	Slider (in the Firebase console. The REST API uses the `<=` , `>` , and `between` operators).	0-100	Use this field to apply a change to a random sample of app instances (with sample sizes as small as .0001%), using the slider widget to segment randomly-shuffled users (app instances) into groups. Each app instance is persistently mapped to a random whole or fractional number, according to a seed defined in that project. Seed values can contain between one and 32 characters containing alphanumeric values, dots, hyphens, and/or underscores. A rule will use the default key (shown as Edit seed in the Firebase console) unless you modify the seed value. You can return a rule to using the default key by clearing the Seed field. To consistently address the same app instances within given percentage ranges, use the same seed value across conditions. Or, select a new randomly-assigned group of app instances for a given percentage range by specifying a new seed. For example, to create two related conditions that each apply to a non-overlapping 5% of an app's users, you could configure one condition to match a percentage between 0% and 5% and configure another condition to match a range between 5% and 10%. To allow some users to randomly appear in both groups, use different seed values for the rules within each condition.
Imported segment	ভিতরে আছে	Select one or more imported segment.	This rule requires setting up custom imported segments .
তারিখ/সময়	Before, After	A specified date and time, either in the device timezone or a specified timezone such as "(GMT+11) Sydney time."	Compares the current time to the device fetch time.
First open	Before, After	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, iOS, or Web app. Requires the following SDKs: Firebase SDK for Google Analytics Apple platforms SDK v9.0.0+ or Android SDK v21.1.1+ ( Firebase BoM v30.3.0+), and JavaScript SDK v12.8.0+. Analytics must also have been enabled on the client during the first open event.
Installation ID	ভিতরে আছে	Specify one or more Installation IDs (up to 50) to target.	This rule evaluates to `true` for a given installation if that installation's ID is in the comma-separated list of values. To learn how you can get installation IDs, see Retrieve client identifiers .
User exists	(no operator)	Targets all users of all apps within the current project.	Use this condition rule to match all users within the project, regardless of app or platform. When using Remote Config personalization , you can use this operator to ensure that all users within the project receive personalized values.
Custom signal	For string values: contains, does not contain, exactly matches, contains regular expression For numeric values: =, ≠, >, ≥, <, ≤ For version values: =, ≠, >, ≥, <, ≤	String comparisons for this rule are case-sensitive. When using the exactly matches, contains, does not contain, or contains regular expression operator, you can select multiple values. When using the contains regular expression 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. The following data types are supported for client environments: iOS: int, double Android: int, long, double Web: number Numeral that represents the version number(s) to match (for example, 2.1.0).	For more information on custom signal conditions and conditional expressions to use, see Custom signal conditions and Elements used to create conditions .

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

মেট্রিক	বর্ণনা
Crash-free users	The percentage of users who have not encountered errors in your app that were detected by the Firebase Crashlytics SDK during the experiment. Note: Firebase Crashlytics is not supported for web applications.
Estimated ad revenue	Estimated ad earnings.
Estimated total revenue	Combined value for purchase and estimated ad revenues.
Purchase revenue	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.

Other metrics

মেট্রিক	বর্ণনা
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 . This metric is not supported for web applications.
screen_view	An Analytics event that tracks screens viewed within your app. To learn more, see Track Screenviews .
session_start	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:

Enable BigQuery export for Google Analytics in the Firebase console
Access A/B Testing data using BigQuery
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 :

In the Firebase console, go to the Settings > Integrations tab .
In the BigQuery card, click Manage and verify that your project is exporting Analytics data to BigQuery .
If the card says Link , then you need to set up the export (continue to the next step).
If you need to set up export:
1. Review About Linking Firebase to BigQuery , then click Next .
2. In the Configure integration section, enable Google Analytics .
3. Select a region and choose export settings.
  Note: For more information about Google Analytics for Firebase settings, see Data collection .
4. 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:

In the Google Cloud console, go to BigQuery .
Select your project, then select Create SQL query .
Add your query. For example queries to run, see Explore example queries .
Click Run .

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

To obtain and run the auto-generated query:

In the Firebase console, go to DevOps & Engagement > A/B Testing .
Select the A/B Testing experiment you want to query to open the Experiment overview .
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.

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

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

  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

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:

Create your experiment.
Manage your experiment.

Create an experiment

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

Verify that Google Analytics is enabled in your project so that the experiment has access to Analytics data.
If you didn't enable Google Analytics when creating your project, you can enable it in the Settings > Integrations tab of the Firebase console.
In the Firebase console, go to DevOps & Engagement > A/B Testing
Click Create experiment , and then select Remote Config when prompted for the service you want to experiment with.
In the Variants section, choose a baseline and at least one variant for the experiment. You can add one or more parameters to experiment with. You can repeat this step to add multiple parameters to your experiment.
(optional) To add more than one variant to your experiment, click Add another variant .
Change one or more parameters for specific variants. Any unchanged parameters are the same for users not included in the experiment.
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 .
Define the Targeting criteria for your experiment using Remote Config conditions:
- Reuse an existing condition: If an existing condition in your Remote Config template already matches your target audience, select it from the list.
  Important: If you reuse an existing condition for an experiment, you cannot edit that condition until the experiment has completed or stopped . Modifying a shared condition while an experiment is actively running can alter variant assignment and invalidate experiment measurements.
- Verify condition evaluation order: Make sure your conditions on the Conditions page are organized in the correct priority order. Because Remote Config evaluates conditions sequentially from top to bottom, other higher-priority condition(s) can prevent sufficient users from reaching the condition associated with your experiment.
- Create a new condition: If no existing condition satisfies your targeting requirements, or if you prefer to duplicate an existing condition (for example, to avoid locking a condition that is shared by other parameters), create a new condition by first choosing the app that uses your experiment. If the parameter you are testing also uses the existing (or another overlapping) condition, make sure the new experiment condition is placed above the existing condition on the Conditions tab (giving it higher evaluation priority); otherwise, users will match the existing condition first and won't flow into the experiment.
  You can then target a specific subset of users by clicking and and selecting one or more options from the following list:
  - Version: One or more versions of your app
  - Build number: The build number (Apple) or version code (Android) of your app
  - Platform: One or more platforms (iOS, Android, or Web) to target
  - Operating system: Target web app users based on their operating system and version
  - Browser: Target web app users based on their web browser and browser version
  - Device category: Target web app users based on whether their device is mobile or non-mobile
  - 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
  - User in random percentage: Target a randomly selected percentage of users within a defined percentile range
  - Imported segment: Target users who belong to custom imported segments uploaded to your project
  - Date/Time: Target users based on a specified date and time window
  - First open: Target users based on the first time they ever opened your app
  - Installation ID: Target specific test devices or client instances using their Firebase Installation IDs (FIDs)
  - User exists: Target all users across all apps in the project
  - Custom signal: Target users based on custom client-side key-value signals passed at runtime
Note: Due to Google Analytics data processing latency , experiments that target Analytics user audiences may require more time to accumulate data. To learn more about this and other targeting options, see User targeting .
Set the Exposure: 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% and 100%. Users are randomly assigned to each experiment, including duplicated experiments.
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.
Note: Activation events are not supported for A/B Testing web implementations.
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
The Analytics event you select as the activation event must not also be used as the primary metric (or as an additional metric) in the same experiment. Doing so will trigger a validation error in the Firebase console and prevent your experiment from launching.
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. When finished, click Next .
Click Save to save your experiment. You must publish the template to start running your experiment.

You are allowed up to 300 experiments per project (including rollouts), which could consist of up to 24 running experiments and rollouts, with the rest as completed experiments.

Manage your experiment

When you create an experiment with Remote Config , you can 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.

Edit an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Click Running , click an experiment that you want to edit.
Click the context menu ( ) and click Edit running experiment .
To validate that your app has users who would be included in your experiment, expand the details and check for a number greater than 0% in the Targeting and distribution section (for example, 1% of users matching the criteria ).

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.

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Click Running , and then click, 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."
After your experiment has run for a while (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

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Click Completed or Running , click an experiment that you want to release to all users, click the context menu ( ) Roll out variant .
Roll out your experiment to all users by doing the following:
- 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.

Expand an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Select the running experiment that you want to edit.
In the Experiment overview , click the context menu ( ), and then click Edit running experiment .
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 an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Select the running or completed experiment that you want to stop.
Click Completed or Running , hold the pointer over your experiment, click the context menu ( ), and then click Duplicate experiment or Stop experiment .

Stop an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Select the running or completed experiment that you want to stop.
Click Completed or Running , hold the pointer over your experiment, click the context menu ( ), and then click Stop experiment .

Web client identification and experiment persistence

Firebase A/B Testing uses the FID to assign users to experiment variants, and Google Analytics uses it for event aggregation to measure and analyze user behavior within each variant.

User targeting

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

The following rule types are supported in the Firebase console. Equivalent features are available in the Remote Config REST API, as detailed in the conditional expression reference .

Rule type	অপারেটর(গণ)	Value(s)	দ্রষ্টব্য
App	==	Select from a list of App IDs for apps associated with your Firebase project.	When you add an app to Firebase, you enter a bundle ID or Android package name that defines an attribute that's exposed as App ID in Remote Config rules. Use this attribute as follows: For Apple platforms: Use the app's CFBundleIdentifier . You can find the Bundle Identifier in the General tab for your app's primary target in Xcode. For Android: Use the app's applicationId . You can find the `applicationId` in your app-level `build.gradle(.kts)` file.
App version	For string values: exactly matches, contains, does not contain, contains regular expression For numeric values: <, <=, =, !=, >, >=	Specify the version(s) of your app to target. Before using this rule, you must use an App ID rule to select an Android/Apple app associated with your Firebase project.	For Apple platforms: Use the app's CFBundleShortVersionString . Note: Make sure your Apple app is using Firebase Apple platforms SDK version 6.24.0 or higher, as CFBundleShortVersionString is not being sent in earlier versions (see release notes ). For Android: Use the app's versionName . Note: Numeric comparison operators ( `<` , `<=` , `=` , `!=` , `>` , `>=` ) support only numeric semantic versions (such as `1.2.3` ). They do not support pre-release suffixes or hyphens (such as `-beta` or `-rc` ). For version strings with non-numeric suffixes or hyphens (such as `1.5-beta` ), use string operators instead (such as contains regular expression , contains , or exactly matches ). String comparisons for this rule are case-sensitive. When using the exactly matches , contains , does not contain , or contains regular expression operator, you can select multiple values. When using the contains regular expression 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.
Build number	For string values: exactly matches, contains, does not contain, regular expression For numeric values: =, ≠, >, ≥, <, ≤	Specify the build(s) of your app to target. Before using this rule, you must use an App ID rule to select an Apple or Android app associated with your Firebase project.	This operator is available for Apple and Android apps only. It corresponds to the app's CFBundleVersion for Apple and versionCode for Android. String comparisons for this rule are case-sensitive. When using the exactly matches , contains , does not contain , or contains regular expression operator, you can select multiple values. When using the contains regular expression 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.
প্ল্যাটফর্ম	==	আইওএস অ্যান্ড্রয়েড ওয়েব
অপারেটিং সিস্টেম	==	Specify the operating system(s) to target. Before using this rule, you must use an App ID rule to select a Web app associated with your Firebase project.	This rule evaluates to `true` for a given Web app instance if the operating system and its version matches a target value in the specified list.
ব্রাউজার	==	Specify the browser(s) to target. Before using this rule, you must use an App ID rule to select a Web app associated with your Firebase project.	This rule evaluates to `true` for a given Web app instance if the browser and its version matches a target value in the specified list.
Device category	is, is not	মোবাইল	This rule evaluates whether the device accessing your web app is mobile or non-mobile (desktop or console). This rule type is only available for web apps.
ভাষা	ভিতরে আছে	Select one or more languages.	This rule evaluates to `true` for a given app instance if that app instance is installed on a device that uses one of the languages listed.
Country/Region	ভিতরে আছে	Select one or more regions or countries.	This rule evaluates to `true` for a given app instance if the instance is in any of the regions or countries listed. The device country code is determined using the device's IP address in the request or the country code determined by Firebase Analytics (if Analytics data is shared with Firebase).
User audience(s)	Includes at least one	Select one or more from a list of Google Analytics audiences that you have set up for your project.	This rule requires an App ID rule to select an app associated with your Firebase project. Note: Because many Analytics audiences are defined by events or user properties, which can be based on the actions of app users, it may take some time for a User in audience rule to take effect for a given app instance. 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 won't match the condition.
User property	For string values: contains, does not contain, exactly matches, contains regular expression For numeric values: =, ≠, >, ≥, <, ≤ Note: On the client, you can set only string values for user properties. For conditions that use numeric operators, Remote Config converts the value of the corresponding user property into an integer/float.	Select from a list of available Google Analytics user properties.	To learn how you can use user properties to customize your app for very specific segments of your user base, see Remote Config and user properties . To learn more about user properties, see the following guides: Set user properties on Apple Set user properties on Android When using the exactly matches , contains , does not contain or contains regular expression operator, you can select multiple values. When using the contains regular expression 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. Note: Automatically collected user properties are not available when creating Remote Config conditions.
User in random percentage	Slider (in the Firebase console. The REST API uses the `<=` , `>` , and `between` operators).	0-100	Use this field to apply a change to a random sample of app instances (with sample sizes as small as .0001%), using the slider widget to segment randomly-shuffled users (app instances) into groups. Each app instance is persistently mapped to a random whole or fractional number, according to a seed defined in that project. Seed values can contain between one and 32 characters containing alphanumeric values, dots, hyphens, and/or underscores. A rule will use the default key (shown as Edit seed in the Firebase console) unless you modify the seed value. You can return a rule to using the default key by clearing the Seed field. To consistently address the same app instances within given percentage ranges, use the same seed value across conditions. Or, select a new randomly-assigned group of app instances for a given percentage range by specifying a new seed. For example, to create two related conditions that each apply to a non-overlapping 5% of an app's users, you could configure one condition to match a percentage between 0% and 5% and configure another condition to match a range between 5% and 10%. To allow some users to randomly appear in both groups, use different seed values for the rules within each condition.
Imported segment	ভিতরে আছে	Select one or more imported segment.	This rule requires setting up custom imported segments .
তারিখ/সময়	Before, After	A specified date and time, either in the device timezone or a specified timezone such as "(GMT+11) Sydney time."	Compares the current time to the device fetch time.
First open	Before, After	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, iOS, or Web app. Requires the following SDKs: Firebase SDK for Google Analytics Apple platforms SDK v9.0.0+ or Android SDK v21.1.1+ ( Firebase BoM v30.3.0+), and JavaScript SDK v12.8.0+. Analytics must also have been enabled on the client during the first open event.
Installation ID	ভিতরে আছে	Specify one or more Installation IDs (up to 50) to target.	This rule evaluates to `true` for a given installation if that installation's ID is in the comma-separated list of values. To learn how you can get installation IDs, see Retrieve client identifiers .
User exists	(no operator)	Targets all users of all apps within the current project.	Use this condition rule to match all users within the project, regardless of app or platform. When using Remote Config personalization , you can use this operator to ensure that all users within the project receive personalized values.
Custom signal	For string values: contains, does not contain, exactly matches, contains regular expression For numeric values: =, ≠, >, ≥, <, ≤ For version values: =, ≠, >, ≥, <, ≤	String comparisons for this rule are case-sensitive. When using the exactly matches, contains, does not contain, or contains regular expression operator, you can select multiple values. When using the contains regular expression 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. The following data types are supported for client environments: iOS: int, double Android: int, long, double Web: number Numeral that represents the version number(s) to match (for example, 2.1.0).	For more information on custom signal conditions and conditional expressions to use, see Custom signal conditions and Elements used to create conditions .

A/B Testing metrics

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

মেট্রিক	বর্ণনা
Crash-free users	The percentage of users who have not encountered errors in your app that were detected by the Firebase Crashlytics SDK during the experiment. Note: Firebase Crashlytics is not supported for web applications.
Estimated ad revenue	Estimated ad earnings.
Estimated total revenue	Combined value for purchase and estimated ad revenues.
Purchase revenue	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.

Other metrics

মেট্রিক	বর্ণনা
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 . This metric is not supported for web applications.
screen_view	An Analytics event that tracks screens viewed within your app. To learn more, see Track Screenviews .
session_start	An Analytics event that counts user sessions in your app. To learn more, see Automatically collected events .

BigQuery data export

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

Enable BigQuery export for Google Analytics in the Firebase console
Access A/B Testing data using BigQuery
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 :

In the Firebase console, go to the Settings > Integrations tab .
In the BigQuery card, click Manage and verify that your project is exporting Analytics data to BigQuery .
If the card says Link , then you need to set up the export (continue to the next step).
If you need to set up export:
1. Review About Linking Firebase to BigQuery , then click Next .
2. In the Configure integration section, enable Google Analytics .
3. Select a region and choose export settings.
  Note: For more information about Google Analytics for Firebase settings, see Data collection .
4. Click Link 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:

In the Google Cloud console, go to BigQuery .
Select your project, then select Create SQL query .
Add your query. For example queries to run, see Explore example queries .
Click Run .

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

To obtain and run the auto-generated query:

In the Firebase console, go to DevOps & Engagement > A/B Testing .
Select the A/B Testing experiment you want to query to open the Experiment overview .
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.

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

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

  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

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:

Create your experiment.
Manage your experiment.

Create an experiment

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

Verify that Google Analytics is enabled in your project so that the experiment has access to Analytics data.
If you didn't enable Google Analytics when creating your project, you can enable it in the Settings > Integrations tab of the Firebase console.
In the Firebase console, go to DevOps & Engagement > A/B Testing
Click Create experiment , and then select Remote Config when prompted for the service you want to experiment with.
In the Variants section, choose a baseline and at least one variant for the experiment. You can add one or more parameters to experiment with. You can repeat this step to add multiple parameters to your experiment.
(optional) To add more than one variant to your experiment, click Add another variant .
Change one or more parameters for specific variants. Any unchanged parameters are the same for users not included in the experiment.
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 .
Define the Targeting criteria for your experiment using Remote Config conditions:
- Reuse an existing condition: If an existing condition in your Remote Config template already matches your target audience, select it from the list.
  Important: If you reuse an existing condition for an experiment, you cannot edit that condition until the experiment has completed or stopped . Modifying a shared condition while an experiment is actively running can alter variant assignment and invalidate experiment measurements.
- Verify condition evaluation order: Make sure your conditions on the Conditions page are organized in the correct priority order. Because Remote Config evaluates conditions sequentially from top to bottom, other higher-priority condition(s) can prevent sufficient users from reaching the condition associated with your experiment.
- Create a new condition: If no existing condition satisfies your targeting requirements, or if you prefer to duplicate an existing condition (for example, to avoid locking a condition that is shared by other parameters), create a new condition by first choosing the app that uses your experiment. If the parameter you are testing also uses the existing (or another overlapping) condition, make sure the new experiment condition is placed above the existing condition on the Conditions tab (giving it higher evaluation priority); otherwise, users will match the existing condition first and won't flow into the experiment.
  You can then target a specific subset of users by clicking and and selecting one or more options from the following list:
  - Version: One or more versions of your app
  - Build number: The build number (Apple) or version code (Android) of your app
  - Platform: One or more platforms (iOS, Android, or Web) to target
  - Operating system: Target web app users based on their operating system and version
  - Browser: Target web app users based on their web browser and browser version
  - Device category: Target web app users based on whether their device is mobile or non-mobile
  - 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
  - User in random percentage: Target a randomly selected percentage of users within a defined percentile range
  - Imported segment: Target users who belong to custom imported segments uploaded to your project
  - Date/Time: Target users based on a specified date and time window
  - First open: Target users based on the first time they ever opened your app
  - Installation ID: Target specific test devices or client instances using their Firebase Installation IDs (FIDs)
  - User exists: Target all users across all apps in the project
  - Custom signal: Target users based on custom client-side key-value signals passed at runtime
Note: Due to Google Analytics data processing latency , experiments that target Analytics user audiences may require more time to accumulate data. To learn more about this and other targeting options, see User targeting .
Set the Exposure: 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% and 100%. Users are randomly assigned to each experiment, including duplicated experiments.
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.
Note: Activation events are not supported for A/B Testing web implementations.
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
The Analytics event you select as the activation event must not also be used as the primary metric (or as an additional metric) in the same experiment. Doing so will trigger a validation error in the Firebase console and prevent your experiment from launching.
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. When finished, click Next .
Click Save to save your experiment. You must publish the template to start running your experiment.

You are allowed up to 300 experiments per project (including rollouts), which could consist of up to 24 running experiments and rollouts, with the rest as completed experiments.

Manage your experiment

When you create an experiment with Remote Config , you can 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.

Edit an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Click Running , click an experiment that you want to edit.
Click the context menu ( ) and click Edit running experiment .
To validate that your app has users who would be included in your experiment, expand the details and check for a number greater than 0% in the Targeting and distribution section (for example, 1% of users matching the criteria ).

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.

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Click Running , and then click, 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."
After your experiment has run for a while (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

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Click Completed or Running , click an experiment that you want to release to all users, click the context menu ( ) Roll out variant .
Roll out your experiment to all users by doing the following:
- 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.

Expand an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Select the running experiment that you want to edit.
In the Experiment overview , click the context menu ( ), and then click Edit running experiment .
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 an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Select the running or completed experiment that you want to stop.
Click Completed or Running , hold the pointer over your experiment, click the context menu ( ), and then click Duplicate experiment or Stop experiment .

Stop an experiment

In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
Click the A/B Tests tab.
Select the running or completed experiment that you want to stop.
Click Completed or Running , hold the pointer over your experiment, click the context menu ( ), and then click Stop experiment .

Web client identification and experiment persistence

Firebase A/B Testing uses the FID to assign users to experiment variants, and Google Analytics uses it for event aggregation to measure and analyze user behavior within each variant.

User targeting

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

The following rule types are supported in the Firebase console. Equivalent features are available in the Remote Config REST API, as detailed in the conditional expression reference .

Rule type	অপারেটর(গণ)	Value(s)	দ্রষ্টব্য
App	==	Select from a list of App IDs for apps associated with your Firebase project.	When you add an app to Firebase, you enter a bundle ID or Android package name that defines an attribute that's exposed as App ID in Remote Config rules. Use this attribute as follows: For Apple platforms: Use the app's CFBundleIdentifier . You can find the Bundle Identifier in the General tab for your app's primary target in Xcode. For Android: Use the app's applicationId . You can find the `applicationId` in your app-level `build.gradle(.kts)` file.
App version	For string values: exactly matches, contains, does not contain, contains regular expression For numeric values: <, <=, =, !=, >, >=	Specify the version(s) of your app to target. Before using this rule, you must use an App ID rule to select an Android/Apple app associated with your Firebase project.	For Apple platforms: Use the app's CFBundleShortVersionString . Note: Make sure your Apple app is using Firebase Apple platforms SDK version 6.24.0 or higher, as CFBundleShortVersionString is not being sent in earlier versions (see release notes ). For Android: Use the app's versionName . Note: Numeric comparison operators ( `<` , `<=` , `=` , `!=` , `>` , `>=` ) support only numeric semantic versions (such as `1.2.3` ). They do not support pre-release suffixes or hyphens (such as `-beta` or `-rc` ). For version strings with non-numeric suffixes or hyphens (such as `1.5-beta` ), use string operators instead (such as contains regular expression , contains , or exactly matches ). String comparisons for this rule are case-sensitive. When using the exactly matches , contains , does not contain , or contains regular expression operator, you can select multiple values. When using the contains regular expression 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.
Build number	For string values: exactly matches, contains, does not contain, regular expression For numeric values: =, ≠, >, ≥, <, ≤	Specify the build(s) of your app to target. Before using this rule, you must use an App ID rule to select an Apple or Android app associated with your Firebase project.	This operator is available for Apple and Android apps only. It corresponds to the app's CFBundleVersion for Apple and versionCode for Android. String comparisons for this rule are case-sensitive. When using the exactly matches , contains , does not contain , or contains regular expression operator, you can select multiple values. When using the contains regular expression 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.
প্ল্যাটফর্ম	==	আইওএস অ্যান্ড্রয়েড ওয়েব
অপারেটিং সিস্টেম	==	Specify the operating system(s) to target. Before using this rule, you must use an App ID rule to select a Web app associated with your Firebase project.	This rule evaluates to `true` for a given Web app instance if the operating system and its version matches a target value in the specified list.
ব্রাউজার	==	Specify the browser(s) to target. Before using this rule, you must use an App ID rule to select a Web app associated with your Firebase project.	This rule evaluates to `true` for a given Web app instance if the browser and its version matches a target value in the specified list.
Device category	is, is not	মোবাইল	This rule evaluates whether the device accessing your web app is mobile or non-mobile (desktop or console). This rule type is only available for web apps.
ভাষা	ভিতরে আছে	Select one or more languages.	This rule evaluates to `true` for a given app instance if that app instance is installed on a device that uses one of the languages listed.
Country/Region	ভিতরে আছে	Select one or more regions or countries.	This rule evaluates to `true` for a given app instance if the instance is in any of the regions or countries listed. The device country code is determined using the device's IP address in the request or the country code determined by Firebase Analytics (if Analytics data is shared with Firebase).
User audience(s)	Includes at least one	Select one or more from a list of Google Analytics audiences that you have set up for your project.	This rule requires an App ID rule to select an app associated with your Firebase project. Note: Because many Analytics audiences are defined by events or user properties, which can be based on the actions of app users, it may take some time for a User in audience rule to take effect for a given app instance. 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 won't match the condition.
User property	For string values: contains, does not contain, exactly matches, contains regular expression For numeric values: =, ≠, >, ≥, <, ≤ Note: On the client, you can set only string values for user properties. For conditions that use numeric operators, Remote Config converts the value of the corresponding user property into an integer/float.	Select from a list of available Google Analytics user properties.	To learn how you can use user properties to customize your app for very specific segments of your user base, see Remote Config and user properties . To learn more about user properties, see the following guides: Set user properties on Apple Set user properties on Android When using the exactly matches , contains , does not contain or contains regular expression operator, you can select multiple values. When using the contains regular expression 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. Note: Automatically collected user properties are not available when creating Remote Config conditions.
User in random percentage	Slider (in the Firebase console. The REST API uses the `<=` , `>` , and `between` operators).	0-100	Use this field to apply a change to a random sample of app instances (with sample sizes as small as .0001%), using the slider widget to segment randomly-shuffled users (app instances) into groups. Each app instance is persistently mapped to a random whole or fractional number, according to a seed defined in that project. Seed values can contain between one and 32 characters containing alphanumeric values, dots, hyphens, and/or underscores. A rule will use the default key (shown as Edit seed in the Firebase console) unless you modify the seed value. You can return a rule to using the default key by clearing the Seed field. To consistently address the same app instances within given percentage ranges, use the same seed value across conditions. Or, select a new randomly-assigned group of app instances for a given percentage range by specifying a new seed. For example, to create two related conditions that each apply to a non-overlapping 5% of an app's users, you could configure one condition to match a percentage between 0% and 5% and configure another condition to match a range between 5% and 10%. To allow some users to randomly appear in both groups, use different seed values for the rules within each condition.
Imported segment	ভিতরে আছে	Select one or more imported segment.	This rule requires setting up custom imported segments .
তারিখ/সময়	Before, After	A specified date and time, either in the device timezone or a specified timezone such as "(GMT+11) Sydney time."	Compares the current time to the device fetch time.
First open	Before, After	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, iOS, or Web app. Requires the following SDKs: Firebase SDK for Google Analytics Apple platforms SDK v9.0.0+ or Android SDK v21.1.1+ ( Firebase BoM v30.3.0+), and JavaScript SDK v12.8.0+. Analytics must also have been enabled on the client during the first open event.
Installation ID	ভিতরে আছে	Specify one or more Installation IDs (up to 50) to target.	This rule evaluates to `true` for a given installation if that installation's ID is in the comma-separated list of values. To learn how you can get installation IDs, see Retrieve client identifiers .
User exists	(no operator)	Targets all users of all apps within the current project.	Use this condition rule to match all users within the project, regardless of app or platform. When using Remote Config personalization , you can use this operator to ensure that all users within the project receive personalized values.
Custom signal	For string values: contains, does not contain, exactly matches, contains regular expression For numeric values: =, ≠, >, ≥, <, ≤ For version values: =, ≠, >, ≥, <, ≤	String comparisons for this rule are case-sensitive. When using the exactly matches, contains, does not contain, or contains regular expression operator, you can select multiple values. When using the contains regular expression 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. The following data types are supported for client environments: iOS: int, double Android: int, long, double Web: number Numeral that represents the version number(s) to match (for example, 2.1.0).	For more information on custom signal conditions and conditional expressions to use, see Custom signal conditions and Elements used to create conditions .

A/B Testing metrics

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

মেট্রিক	বর্ণনা
Crash-free users	The percentage of users who have not encountered errors in your app that were detected by the Firebase Crashlytics SDK during the experiment. Note: Firebase Crashlytics is not supported for web applications.
Estimated ad revenue	Estimated ad earnings.
Estimated total revenue	Combined value for purchase and estimated ad revenues.
Purchase revenue	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.

Other metrics

মেট্রিক	বর্ণনা
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 . This metric is not supported for web applications.
screen_view	An Analytics event that tracks screens viewed within your app. To learn more, see Track Screenviews .
session_start	An Analytics event that counts user sessions in your app. To learn more, see Automatically collected events .

BigQuery data export

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

Enable BigQuery export for Google Analytics in the Firebase console
Access A/B Testing data using BigQuery
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 :

In the Firebase console, go to the Settings > Integrations tab .
In the BigQuery card, click Manage and verify that your project is exporting Analytics data to BigQuery .
If the card says Link , then you need to set up the export (continue to the next step).
If you need to set up export:
1. Review About Linking Firebase to BigQuery , then click Next .
2. In the Configure integration section, enable Google Analytics .
3. Select a region and choose export settings.
  Note: For more information about Google Analytics for Firebase settings, see Data collection .
4. Click Link 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:

In the Google Cloud console, go to BigQuery .
Select your project, then select Create SQL query .
Add your query. For example queries to run, see Explore example queries .
Click Run .

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

To obtain and run the auto-generated query:

In the Firebase console, go to DevOps & Engagement > A/B Testing .
Select the A/B Testing experiment you want to query to open the Experiment overview .
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.

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

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

  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