اقتصاد بازی و تحلیل محصول · · ۷ دقیقه
چطور برای افزایش ماندگاری بازیکنان آزمایش طراحی کنیم؟
برای بازگشت بیشتر بازیکنان، به‌جای افزودن پاداش‌های بیشتر، علت ریزش را پیدا کنید و یک تغییر محدود را بسنجید. این راهنما روش طراحی و ارزیابی چنین آزمایشی را توضیح می‌دهد.
پاسخ کوتاه: یک نقطه ریزش و یک رفتار ارزش‌ساز را انتخاب کنید
اگر برنامه بهبود نگهداشت با این جمله شروع شود که «بازیکن‌ها را بیشتر نگه داریم»، احتمالاً به فهرستی بلند از قابلیت‌ها، پاداش‌ها و پیام‌ها می‌رسد که هیچ‌کدام قابل‌ارزیابی نیستند. نقطه شروع درست، یک cohort و یک نقطه مشخص در مسیر بازیکن است: مثلاً بازیکنانی که آموزش را تمام کرده‌اند اما تا روز سوم به نخستین حلقه بازی برنگشته‌اند، یا کسانی که سطح دهم را می‌رسند اما پیش از باز شدن محتوای بعدی خارج می‌شوند. سپس یک رفتار ارزش‌ساز تعریف کنید؛ مانند تکمیل یک مسابقه، پیوستن به گروه، ارتقای معنادار یا بازگشت در یک روز دیگر. هدف آزمایش افزایش کورکورانه زمان بازی نیست؛ هدف این است که بازیکن با کمترین اصطکاک به ارزشی برسد که دلیل بازگشت اوست. هر آزمایش باید بتواند در یک جمله پاسخ دهد: برای کدام گروه، کدام مانع را با چه تغییری کم می‌کنیم و انتظار داریم کدام رفتار تغییر کند؟
پیش از طراحی راه‌حل، cohort و تعریف نگهداشت را قابل‌اعتماد کنید
عدد retention بدون تعریف مشترک می‌تواند تیم را به تصمیم اشتباه ببرد. روشن کنید روز صفر چیست: نصب، ساخت حساب، پایان آموزش یا نخستین بازی واقعی؟ بازگشت را هم بر اساس رویدادی معنادار تعریف کنید، نه صرف باز شدن برنامه در پس‌زمینه. سپس cohortها را با تاریخ ورود و در صورت نیاز نسخه بازی، کانال جذب، منطقه یا نوع دستگاه جدا کنید. برای نمونه، افت D3 فقط در cohortی که پس از یک کمپین وارد شده ممکن است از وعده تبلیغ یا کیفیت ورودی باشد، نه از مرحله سوم بازی. پیش از آزمایش، چند هفته پایه جمع کنید و پوشش رویدادها را بررسی کنید: آیا شروع و پایان آموزش، شکست مرحله، مصرف منابع، ورود به فروشگاه و بازگشت روزانه با شناسه پایدار ثبت می‌شوند؟ لازم نیست از روز اول مدل پیچیده بسازید؛ اما اگر ثبت رویداد ناقص باشد، هیچ پاداش یا تغییر طراحی نمی‌تواند به‌درستی ارزیابی شود. گزارش پایه باید اندازه cohort، نرخ بازگشت، مسیرهای پرتکرار و نقطه‌های خروج را نشان دهد.
علت احتمالی را از نشانه جدا کنید
افت نگهداشت یک نشانه است، نه علت. دیدن خروج بازیکنان بعد از یک مرحله سخت به‌تنهایی ثابت نمی‌کند که آن مرحله باید آسان‌تر شود؛ شاید بازیکن هدف بعدی را نمی‌فهمد، منابع لازم را نمی‌شناسد، زمان انتظار زیاد است یا با رقیب نامتناسب روبه‌رو می‌شود. برای ساخت فرضیه، یک مسیر نمونه از داده و تجربه واقعی انتخاب کنید. مسیر بازیکن را از ورود تا خروج ببینید، چند جلسه بازی را مشاهده کنید و بازخورد پشتیبانی یا نظرسنجی را کنار داده بگذارید. سپس فرضیه را دقیق بنویسید: «اگر پیش از مرحله هفتم، راهنمای ارتقای آیتم را در لحظه نیاز نشان دهیم، سهم بازیکنانی که این مرحله را تکمیل می‌کنند و در روز سوم برمی‌گردند بالا می‌رود.» این جمله بهتر از «راهنما را بهتر کنیم» است، چون گروه، مداخله و پیامد را روشن می‌کند. چند فرضیه هم‌زمان نسازید؛ ابتدا آن فرضیه‌ای را انتخاب کنید که اثر بالقوه، هزینه اجرا و قابلیت برگشت مناسبی دارد.
تغییر کوچک و قابل‌برگشت بسازید، نه یک بازطراحی بزرگ
برای آزمایش نخست، مداخله را تا حد ممکن محدود نگه دارید. نمونه‌های مناسب می‌تواند یک راهنمای زمینه‌ای، تغییر ترتیب یک مأموریت، دادن انتخاب بین دو مسیر، کوتاه‌کردن یک انتظار، یا پیشنهاد اجتماعی مرتبط باشد. تغییر بزرگ در اقتصاد، نرخ پاداش و دشواری چند مرحله به‌صورت هم‌زمان شاید هیجان‌انگیز باشد، اما بعداً نمی‌فهمید چه چیزی نتیجه را ساخته و چه آسیبی پنهان کرده است. در بازی F2P، افزایش منابع رایگان ممکن است بازگشت کوتاه‌مدت را بهتر کند اما ارزش پیشرفت، توازن منابع و انگیزه خرید سالم را خراب کند. بنابراین برای هر تغییر، مسیر توقف و بازگشت بنویسید: چه کسی آن را فعال می‌کند، برای چه درصدی از کاربران، تا چه تاریخی و با چه شرطی غیرفعال می‌شود؟ طراحی کم‌ریسک به معنی کم‌اثر نیست؛ یعنی تیم بتواند سریع یاد بگیرد، بدون آنکه اقتصاد یا تجربه همه بازیکنان را در معرض یک فرض تأییدنشده قرار دهد.
گروه مقایسه و معیارهای نگهبان را از ابتدا تعیین کنید
برای اینکه تفاوت رفتار را به تغییر خود نسبت دهید، گروه آزمایش و گروه مقایسه‌ای تا حد ممکن مشابه لازم است. بازیکنان واجد شرایط را تصادفی تقسیم کنید و مطمئن شوید یک بازیکن در هر دو تجربه قرار نمی‌گیرد. اگر اندازه cohort کم است یا تقسیم تصادفی ممکن نیست، حداقل یک بازه پایه مشابه و محدودیت نتیجه‌گیری ثبت کنید. معیار اصلی می‌تواند نرخ تکمیل مرحله و D3 یا D7 همان cohort باشد، اما به آن بسنده نکنید. معیارهای نگهبان مانند نرخ خطا و خروج، زمان انتظار، مصرف و تولید منابع، بازپرداخت، شکایت، نرخ پرداخت سالم یا تعادل برد و باخت را کنار آن ببینید. مثال: اگر راهنمای جدید نرخ تکمیل را بالا ببرد ولی بازیکنان منابع حیاتی را خیلی سریع بسوزانند، شاید فقط مسئله را به مرحله بعد منتقل کرده‌اید. پیش از شروع آستانه تصمیم بنویسید: چه مقدار بهبود برای ادامه‌دادن کافی است و کدام افت نگهبان آزمایش را متوقف می‌کند. این کار جلوی تفسیر سلیقه‌ای یک نمودار را می‌گیرد.
نتیجه را بر اساس کیفیت یادگیری بخوانید، نه فقط برد یا باخت
در پایان آزمایش، ابتدا بررسی کنید اجرا همان چیزی بوده که طراحی کرده‌اید: آیا بازیکنان هدف واقعاً تغییر را دیده‌اند؟ آیا رویدادها درست ثبت شده‌اند؟ آیا هم‌زمان رویداد فصلی، کمپین یا نسخه جدیدی منتشر شده است؟ بعد نتیجه را در سطح cohort ببینید، نه فقط میانگین کل کاربران. ممکن است اثر برای بازیکنان تازه مثبت و برای بازیکنان بازگشتی خنثی باشد؛ این یافته می‌تواند به‌مراتب مفیدتر از یک عدد میانگین کوچک باشد. اگر معیار اصلی بهتر شد و نگهبان‌ها سالم ماندند، تغییر را مرحله‌ای گسترش دهید و اثر D7 یا D14 را نیز دنبال کنید. اگر نتیجه خنثی یا ضعیف بود، آن را شکست پنهان نکنید. بنویسید کدام فرض رد شد، چه مشاهده‌ای باقی ماند و آیا مسئله به مسیر، دشواری، اقتصاد یا کیفیت ورودی مربوط است. آزمایش خوب حتی وقتی اثر مثبت ندارد، یک تصمیم بد را زودتر و با هزینه کمتر حذف می‌کند.
برنامه آزمایش را به ریتم محصول و اقتصاد بازی وصل کنید
نگهداشت با یک آزمایش تمام نمی‌شود، چون محتوای بازی، جامعه بازیکنان، اقتصاد و کانال‌های جذب دائماً تغییر می‌کنند. یک backlog کوچک و اولویت‌بندی‌شده بسازید که برای هر مورد مسئله، cohort، فرضیه، مالک، هزینه، معیار اصلی و نگهبان را ثبت کند. در مرور هفتگی محصول، طراحی، داده و اقتصاد بازی، فقط سه سؤال بپرسید: بزرگ‌ترین نقطه اصطکاک کجاست، کدام آزمایش اکنون ارزش اجرا دارد و چه چیزی از آزمایش قبلی آموختیم؟ تغییرات مهم منابع و مصارف یا فروشگاه را جداگانه علامت بزنید تا اثرشان با تغییرات retention اشتباه گرفته نشود. جمع‌بندی: نگهداشت را به یک رفتار ارزش‌ساز و cohort مشخص وصل کنید، تعریف و داده را قابل‌اعتماد کنید، یک مانع را با مداخله کوچک آزمایش کنید و نتیجه را همراه با نگهبان‌های اقتصاد و تجربه بخوانید. اگر تیم شما می‌داند بازیکنان کجا خارج می‌شوند اما درباره علت و آزمایش بعدی توافق ندارد، یک جلسه مشاوره متمرکز می‌تواند نقشه cohort، معیارها و نخستین آزمایش کم‌ریسک را روشن کند.