مسئله‌ای که باید حل می‌کردم
بعد از اقتصاد و ظاهر، می‌خواستم رفتار واقعی بازیکن را ببینم. در Bunny Circus Analytics، ارسال رویداد باید از ادامهٔ بازی جدا باشد و قطع شبکه نباید نتیجهٔ مسابقه را عوض کنه.
پیاده‌سازی در نسخهٔ فعلی
GameAnalytics.TrackEvent رویداد را در outbox پایدار می‌نویسد. فایل موقت پس از نوشتن جابه‌جا می‌شود و SendLoop قدیمی‌ترین فایل را با UnityWebRequest ارسال می‌کنه؛ تأیید success باعث حذف هست.
تصمیم و هزینهٔ طراحی
خطای موقت retry با فاصلهٔ افزایشی داره. خطای مجوز و redirect ارسال را pause می‌کنه و رد دائمی در پوشهٔ rejected نگه داشته می‌شود؛ همهٔ خطاها یک رفتار واحد ندارند.
مرزهای فعلی
سورس PHP اکنون ذخیرهٔ JSON روزانه، قفل فایل، بررسی تکرار و گزارش‌ها را نشان می‌دهد. این شواهد برای توضیح معماری کافی هست؛ وضعیت استقرار و موفقیت ترافیک زنده همچنان به شاهد جدا نیاز داره.
سناریوهای بررسی و معنای قرارداد
با اضافه شدن سورس PHP، می‌شود سمت دیگر قرارداد را نیز دید. API فقط POST با JSON می‌پذیرد، کلید را با بازی مجاز تطبیق می‌دهد و سپس داده را برای ذخیره می‌فرسته. store_event برای فایل روز همان بازی قفل می‌گیرد و بررسی بودجهٔ کلی رویدادها نیز با قفل مشترک انجام می‌شود. نوشتن اتمیک با فایل موقت و rename، جایگزین نوشتن مستقیم روی فایل اصلی هست. رویداد تکراری با شناسه و محتوای یکسان دوباره اضافه نمی‌شود؛ استفادهٔ متعارض از همان شناسه خطا می‌دهد. این بررسی در فایل روز هدف انجام می‌شود و نباید آن را شاخص یکتایی نامحدود در همهٔ روزها معرفی کرد.
سناریوی مهم، قطع پاسخ پس از ذخیرهٔ موفق هست: کلاینت نمی‌داند درخواست رسیده و دوباره همان رویداد را می‌فرسته. ثابت ماندن event_id و payload به سرور امکان تشخیص تکرار در همان روز را می‌دهد. اگر ظرفیت روز یا بودجهٔ کلی پر باشد، پاسخ 503 نشان‌دهندهٔ توقف موقت دریافت هست؛ حذف خودکار تاریخچه راهکار این نسخه نیست. ذخیرهٔ JSON برای هاست کوچک تصمیم ساده‌ای هست اما گزارش تاریخچه آن را در حافظهٔ PHP می‌خواند و با بزرگ شدن داده محدودیت پیدا می‌کنه. من این معماری Bunny Circus Analytics را با قراردادهای قابل بررسی توضیح می‌دهدم، بدون ادعای تعداد کاربران، نرخ تحویل یا آزمون فشار انجام‌شده.
فایل روز از زمان خود رویداد تعیین می‌شود و سرور received_at را جدا اضافه می‌کنه. پس دیر رسیدن داده را نباید با زمان وقوع یکی دانست. این تفاوت در ارسال صف پس از بازگشت شبکه مهم هست. برای فهم تأخیر و انتخاب بازهٔ گزارش، هر دو مفهوم لازم‌اند؛ از صرف حضور یک رکورد در فایل نمی‌توان زمان آنلاین بودن بازیکن را با دقت عملیاتی نتیجه گرفت.
چیزی که از این مرحله یاد گرفتم
برای من، ثبت رویداد باید صادقانه باشد: queued با delivered فرق داره. معماری کلاینت برای دوام تلاش می‌کنه، ولی صحت انتها به انتهای Bunny Circus Analytics به بررسی سمت سرور هم نیاز داره.
سورس و گفتگو دربارهٔ پروژه: GitHub · Telegram
مثال عملی اتصال آنالیتیکس یونیتی
اگر بخواهی اتصال آنالیتیکس یونیتی را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. یک رویداد آزمایشی را از یونیتی بفرست و دریافت آن را در فایل روزانهٔ PHP بررسی کن. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
دیده شدن رویداد در کلاینت به معنی دریافت موفق در سرور نیست. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. هر مرحلهٔ ارسال، پاسخ و نگهداری داده شاهد جداگانه می‌خواهد. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
نام بازی، کلید اتصال و رویداد ذخیره‌شده باید با نمونهٔ ارسال‌شده تطبیق داشته باشند. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | یک رویداد آزمایشی را از یونیتی بفرست و دریافت آن را در فایل روزانهٔ PHP بررسی کن. |
| ریسک اصلی | دیده شدن رویداد در کلاینت به معنی دریافت موفق در سرور نیست. |
| روش بررسی | نام بازی، کلید اتصال و رویداد ذخیره‌شده باید با نمونهٔ ارسال‌شده تطبیق داشته باشند. |
| مرز نتیجه‌گیری | هر مرحلهٔ ارسال، پاسخ و نگهداری داده شاهد جداگانه می‌خواهد. |
پرسش‌های کاربردی دربارهٔ اتصال آنالیتیکس یونیتی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: یک رویداد آزمایشی را از یونیتی بفرست و دریافت آن را در فایل روزانهٔ PHP بررسی کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. نام بازی، کلید اتصال و رویداد ذخیره‌شده باید با نمونهٔ ارسال‌شده تطبیق داشته باشند. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. هر مرحلهٔ ارسال، پاسخ و نگهداری داده شاهد جداگانه می‌خواهد.
برای ادامهٔ همین موضوع، آنالیتیکس چیست؟ از شمارش رویداد تا فهم مسیر بازیکن و Bunny Circus Analytics را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
