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

تاریخ انتشار : سه‌شنبه 18/04/17
دسته بندی: 

چگونه آزمایش A/B  می‌تواند به شما کمک کند تا اپلیکیشن‌تان بیشترین بازدهی را داشته باشد.
آزمایش A/B یک شیوه‌ی آزمایشی کنترل شده است که دو یا چند نسخه از یک اپلیکیشن را با هم مقایسه می‌کند تا یک فرضیه تایید یا رد شود. این آزمایش، متغیرهای خاص را از بقیه سیستم مجزا می‌کند تا نتایج قابل اطمینانی حاصل کند. آزمایشA/B  زمانی بسیار مؤثر است که در یک محیط زنده انجام شود و جمعیت تحت آزمایش در جریان اینکه آزمایش در حال انجام است نباشند. 
با بکارگیری یک نمونه جمعیتی برای هر متغیر، یک پلتفرم آزمایشی A/B به طور تصادفی به هر کاربر متغیر A یا B را نمایش می‌دهد یا آنها را از آزمایش حذف می‎کند. سپس اطمینان حاصل می‌کند که هر کاربر یک تجربه ثابت (همیشه A یا همیشه B) را در طول آن آزمایش می‌بیند  و داده‌های اضافی را در اختیار یک پلتفرم تحلیلی برای تعیین اثر روی معیارها قرار می‌دهد. هنگامی که معیارها تجزیه و تحلیل  شدند و کاراترین نسخه انتخاب شد، شما می‌توانید به تدریج با استفاده از پلتفرم A/B از نسخه‌ی برنده برای همه‌ی کاربران استفاده کنید. 
به عنوان مثال، شما ممکن است فرض کنید که در اپلیکیشن شماbottom navigation  باعث جذب تعامل کاربری بیشتری نسبت به Tabها می‌شود. شما می توانید یک آزمایش A/B طراحی کنید که Tab ها (نسخه A) را با یک bottom navigation  (نسخه B) مقایسه کند. پلتفرم آزمایش A/B شما سپس یک نمونه‌ی کاربر محور ایجاد می‌کند که بطور تصادفی و نمایشی به نسخه A یا نسخهB  اختصاص داده شده است، و هرکاربر در طول آزمایش همان نسخه را می‌بیند. زمانی که آزمایش تمام می‌شود، تعامل کاربری نسخه A، می‌تواند با نسخه B مقایسه شود تا ببینید که آیا پیشرفت آماری قابل‌توجهی برای نسخه B وجود دارد یا خیر. اگر نسخه B بهتر است، حالا شما این اطلاعات را دارید که تصمیم خودتان را مبنی بر استفاده‌ی از bottom navigation  برای همه‌ی کاربران عملی کنید. 
در این مطلب، به پنج مرحله‌ی کلیدی آزمایش A/B درون‌برنامه‌ای می‌پردازیم:
-    فرضیه‌ی خود را بسازید. 
-    یک پلتفرم آزمایش A/B راه‌اندازی کنید. 
-    فرضیه خود را آزمایش کنید.
-    تجزیه و تحلیل و نتیجه‌گیری کنید. 
-    بر اساس نتیجه اقدام کنید. 
و بعد از این‌ها به تکنیک‌های پیشرفته‌ای که می‌توانید بکار ببرید هم اشاره خواهیم کرد. 
گام اول: فرضیه‌ی خود را بسازید. 
فرضیه یک توضیح پیشنهادی برای یک پدیده است و آزمایش A/B روشی برای سنجیدن درست یا نادرست بودن آن. فرضیه ممکن است با بررسی داده‌های موجود بوجود آید، ممکن است براساس حدس و گمان باشد، یا ممکن است فقط چیزی شهودی باشد. (فرضیه‌های شهودی به ویژه برای افزونه‌های جدیدی که معیارهای جدیدی را فعال می‌کنند، بسیار رایج است.) در مثالی که بالا زدیم فرضیه می‌تواند به این شکل مطرح شود: "استفاده از bottom navigation  به جای Tab باعث افزایش تعامل کاربر خواهد شد". شما سپس می‌توانید از این فرضیه استفاده کنید تا تصمیم خود را درباره اینکه چه تغییری (در صورت نیاز) باید در سبک Navigation اپلیکیشن شما انجام شود و این تغییر چه تأثیری بر روی تعامل کاربر خواهد گذاشت بگیرید. نکته‌ی مهمی که باید بخاطر داشته باشیم این است که تنها هدف این آزمایش اثبات این است که bottom navigation  تأثیر مثبت مستقیمی بر روی میانگین درآمد به ازای هرکاربر (ARPU) دارد. 
چه چیزی را آزمایش کنیم؟ (A چیست؟ B چیست؟)
جدول زیر، سناریوهای گسترده‌ای را ارائه می‌دهد که می‌تواند به شما در تعیین چگونگی انتخاب متغیرها کمک کند. از فرضیه‌ی مثالی که در بالا مطرح کردیم به عنوان نمونه استفاده می‌کنیم:​
انتخاب بین سناریوهای 2 و 3 به این بستگی دارد  که فرضیه درصدد اندازه‌گیری چه چیزی است. اگر آن چیز  فقط به ویژگی جدید مربوط است  (به عنوان مثال اگر ویژگی جدید خرید درون برنامه‌ای باشد، پس درآمد خرید درون برنامه‌ای به عنوان یک معیار فقط زمانی مرتبط است که آن ویژگی پیاده‌سازی شده باشد.) سپس سناریو 2 را انتخاب کنید. اگر فرضیه مربوط به چیزی مرتبط (و قابل اندازه‌گیری) قبل از پیاده‌سازی ویژگی جدید باشد (به عنوان مثال، اگر ویژگی جدید یک مکانیزم  "علاقه‌مندی‌ها" است و معیار مشارکت کاربر است)، سناریو 3 را انتخاب کنید.
توجه: در بخش های زیر تا بخش "اقدام"، از سناریو 1 به خاطر مختصر بودن استفاده می‌کنیم. همان روش به همین شکل برای سناریوهای 2 و 3 نیز قابل استفاده است.

آزمایش را بر روی چه کسانی انجام دهیم؟
اگر رفتار مشاهده شده با برخی از عوامل خارج از فرضیه قابل‌تغییر است، برای مثال می‌دانیم که رفتار با توجه به کشور محل اقامت متفاوت خواهد بود وقتی که فرضیه فقط به دنبال تأثیر جهانی بر درآمد است، یک ارزش واحد را برای این عامل هدف قرار دهید (یک کشور واحد) یا از یک جمعیت آماری نمونه از همه‌ی کشورها استفاده کنید. 
اندازه‌ی این جمعیت آماری نمونه کنترل شده، همچنین می‌تواند به عنوان درصد مشخصی از جمعیت تعریف شود. برای مثال، 10% جمعیت در آزمایش درنظر گرفته می‌شوند- 5% متغیر A  را دریافت می‌کنند و 5% متغیر B – و 90% باقیمانده شامل آزمایش نمی‌شوند. این 90% همان پیاده‌سازی موجود را مشاهده می‌کنند و هیچ ویژگی جدیدی را نمی‌بینند، و رفتار آنها از معیارهای آزمایش حذف می‌شود.
آزمایش را برای چه مدتی انجام دهیم؟
حداکثر زمان: رفتار کاربران اغلب با زمان روز، روز هفته، ماه، فصل، و غیره تغییر می‌کند. برای به دست آوردن حدنصابی از این تغییرات، شما باید نیاز به استناد آماری و احتیاجات کسب‌وکار را متعادل ‌سازی کنید. (کسب و کار شما ممکن است نتواند برای کامل شدن آمارها صبر کند). اگر می‌دانید که یک متریک در یک دوره‌ی کوتاه نظیر زمان مشخصی از روز یا روزی از هفته؛ تغییر می‌کند سعی کنید تمام آن دوره را پوشش دهید. برای دوره‌های طولانی‌تر، ممکن است به صرفه‌تر باشد که آزمایش را برای چند هفته اجرا کنید و براساس اطلاعات حاصل از آن، رفتار کاربر را برای هر دوره‌ی زمانی که مدنظر دارید پیش بینی کنید.
حداقل زمان: آزمایش باید به اندازه کافی طول بکشد تا اطلاعات کافی را برای رسیدن به یک نتیجه‌ی آماری قابل استناد داشته باشد. این موضوع معمولا به معنی داشتن یک جامعه آماری با 1000 کاربر (حداقل) است. اما رسیدن به یک نتیجه قابل توجه بستگی به نوع توزیع متریک مشتق شده از فرضیه دارد. شما می توانید این کار را در یک زمان معقول منطقی انجام دهید با برآورد اینکه چه تعداد از کاربران برای آزمایش در این دوره زمانی مورد نظر واجد شرایط هستند، و سپس درصدی از آن جمعیت را برای آزمایش انتخاب کنید، بنابراین آزمایش شما در آن زمان مشخص به استناد آماری موردنظر می‌رسد. برخی از پلتفرم‌های آزمایش A/B این موضوع را به طور خودکار مدیریت می‌کنند و همچنین ممکن است به شما اجازه دهند که سرعت نمونه‌ی آزمایشی را برای سریعتر رسیدن به استناد آماری افزایش دهید.
گام دوم: از یک پلتفرم آزمایش A/B  استفاده کنید. 
پلتفرم‌های متعددی برای آزمایش A/B وجود دارد، یا به عنوان یک سیستم مستقل و یا به عنوان جزئی از یک سیستم تجزیه‌ و تحلیل گسترده‌تر، نظیر Firebase Remote Config در گوگل با کتابخانه‌ای از مشتریان، پلتفرم‌ها مجموعه‌ای از دستورالعمل‌ها و تنظیمات را  به اپلیکیشن ارسال می‌کنند. اپلیکیشن نمی‌داند که چرا یک مقدار پارامتر خاص برگردانده شده است، بنابراین، اطلاعی ندارد که جزئی از چه آزمایشی است و یا اینکه اصلاً جزئی از یک آزمایش است یا نه. مشتری باید فقط تنظیمات خود را با آنچه به او گفته شده تطبیق دهد. از سوی دیگر، پلتفرم به معنای ارزش هر پارامتری که به مشتری برمی‌گرداند اهمیتی نمی‌دهد. به عهده‌ی مشتری است که آن ارزش را تفسیر کند. در ساده‌ترین موارد، پارامتر برگشتی می‌تواند جفت‌های کلید-مقدار (key value pairs) ساده‌ای باشند که کنترل کنند که آیا ویژگی معین شده فعال است، و اگر چنین باشد، کدام مدل باید فعال شود.
در موارد پیشترفته‌تر، که درآنها تنظیمات گسترده‌ی از راه دور اپلیکیشن موردنیاز است، اپلیکیشن ممکن است پارامترها را به پلتفرم آزمایش A/B ارسال کند که می‌توانند برای تصمیم‌گیری درباره‌ی شایستگی آزمایش استفاده شوند. به عنوان مثال، اگر یک فرضیه مربوط به دستگاههایی با تراکم صفحه نمایش xxxhdpi باشد، پس برنامه باید تراکم صفحه نمایش خود را به پلت فرم تست A/ B ارسال کند.
چرخ را دوباره اختراع نکنید!
یکی از پلتفرم‌های موجود را انتخاب کنید که با نیازهای آزمایش A/B شما سازگار باشد. توجه داشته باشید: آزمایشA/B و تصمیم‌گیری مبتنی بر داده‌ای که امکان‌پذیر می‌سازد، اعتیادآور است!
نکته: مدیریت وضعیت ثابت آزمایش و تخصیص منصفانه‌ی شرکت‌کنندگان در آزمایش با تعداد زیادی از کاربران و تعداد زیادی از آزمایش‌ها سخت است. نیازی به نوشتن آن از ابتدا نیست. 
البته، لازم است که برای هر نسخه‌ای که می‌خواهید آزمایش کنید کدنویسی انجام دهید. با این حال، این مسئله نباید به اپلیکیشن یا یک سرویس واگذار شود که تصمیم بگیرد از چه نسخه‌ای در هر زمانی استفاده شود. این مسئله باید همیشه به پلتفرم آزمایش A/B منتهی شود،  بنابراین یک روش استاندارد می‌تواند مورد استفاده قرار بگیرد و چندین آزمایش همزمان بر روی یک جمعیت ثابت  می‌تواند به طور مرکزی مدیریت شود.
نوشتن یک مکانیسم آزمایش A/B  ساده به صورت دستی فقط زمانی معقول است که شما با توجه به دلیلی بدانید که فقط قصد انجام یک آزمایش را دارید. بخاطر هزینه‌های زیاد کدنویسی برای دو آزمایش، شما می‌توانید از پلتفرم‌های آزمایش A/B آماده استفاده کنید. 
یکپارچه‌سازی با تجزیه و تحلیل
شما می‌توانید بصورت خودکار جمعیت تحت آزمایش را به گروه‌های مختلف تقسیم کنید، بنابراین یک پلتفرم تجزیه و تحلیل را انتخاب کنید که بتواند اطلاعات دقیق وضعیت آزمایش را بطور مستقیم به پلتفرم تجزیه و تحلیل موجود شما ارائه دهد. محکم‌ترین مکانیسم یکپارچه‌سازی متکی به تنظیمات مشخص برای هر آزمایش و مدل‌هایی است که بطور مستقیم بین پلتفرم آزمایش A/B و پلتفرم تجزیه و تحلیل منتقل می‌شوند. یک مرجع منحصربفرد جهانی به هر مدل اختصاص داده می‌شود و توسط پلتفرم A/B به مشتری و پلتفرم تجزیه و تحلیل ارائه می‌شود.  این موضوع به مشتری این اجازه را می‌دهد که به جای همه‌ی تنظیمات آن مدل فقط نیاز به ارائه‌ی آن رفرنس به پلتفرم تجزیه و تحلیل داشته باشد. 
تنظیمات از راه‌دور
اپلیکیشن‌هایی که قابلیت تنظیمات از راه دور را دارند معمولاً دارای اغلب کدهایی که برای انجام آزمایش A/B  نیاز است هستند. 
اساساً، آزمایش A/B برخی از قوانین مربوط به سرور را اضافه می‌کند که تعیین می‌کند کدام تنظیمات به اپلیکیشن ارسال شده است. برای اپلیکیشن‌هایی که قابلیت تنظیمات از راه دور را ندارند، یک پلتفرم آزمایش A/B راهی عالی برای معرفی آن است.

گام سوم: فرضیه را امتحان کنید.
زمانی که فرضیه شما مشخص باشد، آزمایش‌تان طراحی شده باشد و پلتفرم آزمایش A/B شما تعیین شده باشد، پیاده‌سازی مدل‌های آزمایش‌تان ساده‌ترین مرحله است. پس از آن، آزمایش خود را شروع کنید. پلتفرم آزمایش A/B مجموعه‌ی از کاربران را به عنوان جامعه‌ی آماری  برای هر کدام از نسخه‌های مورد آزمایش درنظر می‌گیرد. این پلتفرم سپس همچنان به توزیع جمعیت برای دوره‌ی مورد نظر آزمایش ادامه می دهد. در پلتفرم‌های پیشرفته‌تر، پلتفرم آزمایش شما را تا زمانیکه به استناد آماری برسد ادامه می‌دهد. 
بر آزمایش نظارت کنید. 
در طول دروه‌ی آزمایش، پیشنهاد می‌کنیم که بر تاثیر متغیرهای جدید نظارت کنید، از جمله بر معیارهایی که در فرضیه آزمون مطرح نشده است. اگر یک تاثیر مضر را مشاهده می‌کنید، ممکن است ضروری باشد که آزمایش را پیش از موعد مقرر متوقف کنید تا کاربرانتان سریعتر به نسخه‌ی موجود بازگردانده شوند، و شما یک تجربه کاربری ضعیف را به حداقل برسانید. برخی از پلتفرم‌های آزمایش A/B دارای قابلیت نظارت و هشدار خودکار هستند و اگر یک آزمایش تاثیر منفی غیرمنتظره‌ای داشته باشد، اطلاع می‌دهند. در غیر این صورت، هر تاثیری که در سیستم‌های نظارت موجود شما دیده می‌شود نیاز است که به تست‌ها‌ی موجود بطور متقابل ارجاع شود تا بتوان «متغیر بد» را شناسایی کرد. 
نکته: اگر نیازی نیست که آزمایش متوقف شود، داده‌های جمع‌آوری شده شما باید با احتیاط بسیار مورد توجه قرار گیرد زیرا هیچ تضمینی وجود ندارد که نمونه‌ی جمعیتی آزمایش نماینده‌ی مناسبی باشد. 
گام چهارم: تجزیه و تحلیل کنید و نتیجه بگیرید. 
هنگامی که آزمایش به طور کامل به پایان رسید، داده‌های جمع‌آوری شده توسط پلتفرم تجزیه و تحلیل شما می‌تواند برای تعیین نتیجه آزمایش مورد استفاده قرار گیرد. اگر فرضیه توسط متریک‌‌های حاصل شده تأیید شود، می‌توانید نتیجه بگیرید که فرضیه درست بوده است، در غیر اینصورت، فرضیه درست نبوده. تعیین اینکه آیا نتایج مشاهده شده از لحاظ آماری معتبرند یا نه، بستگی به ماهیت و توزیع متریک دارد. 
اگر فرضیه غلط است – چون بدون اثر بوده یا اثرات منفی روی معیارهای مربوطه گذاشته - پس هیچ دلیلی برای حفظ نسخه جدید وجود ندارد. با این وجود،  این حالت هم امکانپذیر است که نسخه‌ی جدید تأثیر مثبتی بر یک متریک مرتبط، اما غیرقابل انتظار داشته باشد. این می‌تواند دلیل معتبری برای انتخاب مدل جدید باشد، اگر چه اغلب بهتر است که آزمایش دیگری را راه‌اندازی کنید که به طور اختصاصی متریک ثانویه را هدف قرار دهد تا تأثیر آن را تأیید کند. در واقع، نتیجه یک آزمایش اغلب سوالات و فرضیه‌های دیگری را مطرح می‌کند.
گام پنجم: اقدام کنید. 
اگر فرضیه درست باشد و نسخه‌ی جدید به نسخه‌ی قدیمی‌ ترجیح داده شود، پارامترهای تنظیمات پیش‌فرض که به اپلیکیشن منتقل می‌شوند می‌توانند به‌روزرسانی شوند و آن را برای استفاده از نسخه‌ی جدید تنظیم کنند. هنگامی که مدل جدید در مدت زمانی کافی تبدیل به پیش‌فرض شد، کد و منابع مدل قدیمی می‌توانند در نسخه‌های بعدی اپلیکیشن حذف شوند. 

گسترش افزایشی
یکی از موارد استفاده‌ی معمول در پلتفرم‌های آزمایش A/B، تغییر هدف آنها به عنوان یک مکانیزم گسترش افزایشی است که در آن نسخه‌ی برنده‌ی آزمایش A/B به تدریج برای همه‌ی کاربران جایگزین نسخه‌ی قدیمی می‌شود. این موضوع را می‌توان به عنوان یک آزمایش طراحی A/B دید، در حالی‌که گسترش افزایشی یک آزمایش Vcurr/Vnext است برای تأیید اینکه مدل انتخابی هیچ تأثیر مضری بر روی بخش بزرگتری از کاربران پایه‌ی شما نمی‌گذارد. گسترش افزایشی می‌تواند با افزایش درصد کاربرانی انجام شود ( برای مثال 0.01٪، 0.1٪، 1٪، 3٪، 7.5٪، 25٪، 50٪، 100٪ ) که مدل جدید را دریافت می‌کنند و با چک کردن اینکه هیچ نتیجه‌ی منفی قبل از رفتن به مرحله بعد مشاهده نشده است. دیگر بخش‌ها نیز می‌توانند مورد استفاده قرار‌گیرند، از جمله کشور، نوع دستگاه، بخش کاربر و غیره. شما همچنین می‌توانید انتخاب کنید که مدل جدید را برای گروه‌های خاصی از کاربران (مثلا کاربران داخلی) گسترش دهید. 
آزمایش پیشرفته
شما می‌توانید یک آزمایش A/B ساده مثلاً برای پشتیبانی از درک عمیق‌تری از طیف رفتاری کاربران بسازید. همچنین می‌توانید با اجرای آزمایش‌های چندگانه‌ی موازی و با مقایسه مدل‌های مختلف در یک آزمایش، کارایی بیشتری کسب کنید.
تقسیم‌بندی عمیق و هدفگیری
نتایج آزمایش A/B را می‌توان برای تغییرات در بخش‌های مختلف مورد بررسی قرارداد و همینطور برای روش‌شناسی هدفگیری آنها را تحلیل کرد. در هر دو مورد، ممکن است ضروری باشد که میزان نمونه یا مدت زمان آزمایش را افزایش دهید تا برای هر بخش به استناد آماری دست پیدا کنید. برای نمونه، نتایج آزمایش فرضیه‌یbottom navigation  در مقابل Tabها ممکن است نشان‌دهنده‌ی تأثیرات مختلفی در کشورهای گوناگون باشد، در موارد دیگر، برخی کشورها ممکن است افزایش مشارکت کاربر را نشان دهند، برخی از آنها هیچ تغییری را نشان ندهند، و برخی از آنها کاهش اندکی را نشان دهند. در این سناریو، پلتفرم آزمایش A/B می‌تواند یک گزینه‌ی «پیش فرض» در هر کشور  در نظر بگیرد تا تعامل کاربری را به حداکثر برساند. 
اطلاعات تقسیم‌بندی مشابه ممکن است برای هدفگیری یک آزمایش فقط در یک بخش خاص بکار روند. به عنوان مثال، شما می‌توانید بر روی کاربرانی که در ایالات متحده زندگی می‌کنند آزمایش کنید و برای کسانی که قبلاً از یک ویژگی خاص در اپلیکیشن استفاده کرده‌اند. 
آزمایش A/n
آزمایش A/n آزمایشی برای بیش از دو متغیر است. حالا ممکن است چندین متغیر جدید به جای متغیر فعلی باشد یا چندین مدل از یک ویژگی جدید، و عدم حضور هر متغیر جدیدی. در هنگام ترکیب شدن با تقسیم‌بندی جدید، ممکن است پی ببرید که مدل‌های مختلف با  کدام بخش‌ها بهترین عملکرد را دارند.
آزمایشی با چند متغیر
یک آزمایش چند متغیری یک آزمایش واحد است که در آن چندین جنبه از یک اپلیکیشن همزمان تغییر می‌کند. این آزمایش سپس با هر یک از مجموعه مقادیر منحصربفرد، به عنوان یک متغیر جداگانه رفتار می‌کند. مثلا: 
آزمایش‌های چندمتغیره زمانی مناسب هستند که وقتی چندین جنبه‌ی مرتبط وجود دارند که می‌توانند عملکرد کلی یک متریک را تحت تأثیر قرار دارند، اما تأثیر جنبه‌های خاص قابل تشخیص نیست. 
آزمایش در مقیاس
آزمایش‌های چندگانه‌ی موازی بر روی یک جمعیت یکسان باید توسط یک پلتفرم مدیریت شوند. بعضی از پلتفرم‌ها قادر به اندازه‌گیری هزاران آزمایش در حال اجرا به صورت موازی هستند، برخی فقط بر یک آزمایش تمرکز دارند (بنابراین کاربر تنها در حال انجام یک آزمایش در یک زمان واحد است)، و برخی در یک جمعیت مشترک (به طوری که کاربر در چند آزمایش به طور همزمان است). مدیریت مورد اول آسان‌تر است، اما به سرعت جمعیت تحت آزمایش را خسته می‌کند و منجر به حد بالا بر روی آزمایش‌های موازی با استناد آماری می‌شود. مدیریت مورد دوم برای پلتفرم آزمایش A/B سخت‌تر است، اما محدودیت بالای تعداد تست‌های موازی را حذف می‌کند. پلتفرم این کار را با بکارگیری بنیادی هر آزمایش  به صورت تقسیم‌بندی اضافی در خارج از هر آزمایش دیگر انجام می دهد.
ورود انتخابی
ورود انتخابی به کاربر این اجازه را می‌دهد تا به طور آگاهانه در معرض یک متغیر خاص از یک آزمایش خاص قرار گیرد. کاربر می‌تواند این متغیر را انتخاب کند یا آن توسط پلتفرم آزمایش A/B به او اختصاص داده شود. در هر صورت، این کاربران  باید از تجزیه و تحلیل معیارها کنار گذاشته شوند چرا که آنها شرکت‌کننده کور در آزمایش نیستند - آنها می دانند که این یک آزمایش است، به طوری که ممکن است پاسخ غلط بدهند. 
نتیجه‌گیری
آزمایش A/B درون‌برنامه‌ای یک ابزار بسیار انعطاف‌پذیر برای تصمیم‌گیری‌های مبتنی بر داده است، و همینطور که در این مقاله تشریح کردیم، می‌تواند به شما در تصمیم‌گیری آگاهانه برای ویژگی‌های جدید اپلیکیشن‌تان کمک کند. آزمایش A/B به شما اجازه می‌دهد تا متغیرهای مختلفی را برای هر جنبه‌ی اپلیکیشن‌تان با کاربران واقعی و در دنیای واقعی آزمایش کنید. برای ساده‌سازی طراحی آزمایش A/B درون‌برنامه‌ای، ادغام، اجرا و پیاده‌سازی گوگل مجموعه‌ای از ابزارها را ارائه می‌دهد. از جمله:
Firebase Remote Config (FRC):
این ابزار کتابخانه‌ای از مشتریان ارائه ‌می‌دهد که به اپلیکیشن‌ها این امکان را می‌دهد که درخواست و دریافت تنظیمات از Firebase داشته باشند، به علاوه‌ی یک مکانیسم قاعده محور برای تعریف تنظیمات کاربر. این ابزار می‌تواند به شما در بروزرسانی و ارتقاء اپلیکیشن‌تان بدون نیاز به انتشار نسخه‌ی جدید کمک کند.  
Firebase Remote Config with Analytics
این ابزار استفاده‌ی رسمی از روش‌های آزمایش A/B را برای تصمیم‌گیری و پیگیری متغیرها امکانپذیر می‌سازد. 
Firebase Analytics
به شما گزارش معیارهای هر متغیر را ارائه می‌دهد و بطور مستقیم به FCR متصل می‌شود.
 

افزودن دیدگاه جدید

مطالب مرتبط

بررسی 4 اشتباه رایج در استراتژی‌ تبلیغات موبایلی

در این مقاله به بررسی چهار اشتباه رایج در تبلیغات موبایلی می‌پردازیم که برای استفاده‌ی بهتر از این رسانه‌ی تبلیغاتی با
شنبه 1 سپتامبر 2018

چگونه یک صفحه فرود (Landing Page) مؤثر طراحی کنیم؟

7 نکته‌ی کلیدی که به شما برای ساختن صفحه‌های فرود با نرخ تبدیل بالا کمک می‌کند را مرور می‌کنیم.
یک‌شنبه 12 اوت 2018
چگونه یک کمپین آگاهی از برند (Brand Awareness) موفق طراحی کنیم؟

چگونه یک کمپین آگاهی از برند (Brand Awareness) موفق طراحی کنیم؟

میزان آگاهی از برند، تأثیر مستقیمی بر موفقیت یک کسب و کار دارد.
یک‌شنبه 29 ژوئیه 2018

آشنایی با بهترین اندازه‌ها برای تبلیغات بنری موبایلی

در این مطلب نگاهی به بهترین اندازه‌ها‌ی تبلیغات بنری برای ناشران در سال 2018 می‌اندازیم و توصیه‌هایی برای استفاده‌ی بهین
شنبه 7 ژوئیه 2018