شناسهٔ نصب با نام بازیکن فرق دارد

مسئله‌ای که باید حل می‌کردم

نام بازیکن برای تجربهٔ شخصی هست و شناسهٔ آنالیتیکس برای پیوند رویدادها. من نمی‌خواستم عوض‌کردن نام نمایشی، تاریخچهٔ نصب را به کاربر تازه تبدیل کنه.

پیاده‌سازی در نسخهٔ فعلی

AnalyticsIdentity.GetOrCreateUserId یک GUID محلی می‌سازد و در PlayerPrefs نگه می‌دارد. GetOrIncrementSessionNumber شمارهٔ نشست را بالا می‌برد؛ ShouldSendFirstOpen و MarkFirstOpenSent وضعیت اولین بازشدن را نگه می‌دارند.

تصمیم و هزینهٔ طراحی

این قرارداد از رشتهٔ نام مستقل هست. transport هم می‌تواند شناسهٔ موجود را بگیرد، بنابراین یک نقطهٔ تولید هویت را می‌شود به چند رویداد وصل کرد.

مرزهای فعلی

پاک‌شدن داده یا نصب دوباره می‌تواند شناسهٔ تازه بسازد. این شناسه حساب احراز هویت‌شده، هویت شخص حقیقی یا شناسهٔ مشترک بین دستگاه‌ها نیست.

سناریوهای بررسی و معنای قرارداد

در سمت PHP، کلید نشست از ترکیب player_id و session_id ساخته می‌شود. این انتخاب مانع یکی شدن دو نشست با شناسهٔ نشست مشابه اما بازیکن متفاوت در تجمیع می‌شود. شروع نشست از app_open یا session_start و پایان از session_end به دست می‌آید. وقتی شروع یا پایان معتبر وجود نداره، مدت نشست ناشناخته باقی می‌ماند و نباید اختلاف اولین و آخرین رویداد را به جای مدت کامل جا زد. این دقیقاً همان جایی هست که تعریف شناسه و چرخهٔ عمر به معنای عدد گزارش وصل می‌شود؛ شمار بازیکن در این سامانه شمار شناسه‌های مشاهده‌شده، نه گواهی تعداد انسان‌های یکتا.

تابع retention_cohorts نخستین روز رویداد هر شناسه را مبنای گروه بازگشت می‌گیرد. بازگشت در روزهای یک، هفت و سی، حضور در همان روز دقیق UTC هست و به معنای هر زمان پس از آن روز نیست. روز هدف باید پیش از observedUntil باشد تا پنجرهٔ مشاهده کامل تلقی بشه؛ روز جاری هنوز کامل نیست. اگر آرشیو تاریخچه نخستین رویداد را کنار بگذارد، معنای اولین مشاهده در دادهٔ باقی‌مانده تغییر می‌کنه. نصب مجدد هم می‌تواند شناسهٔ تازه بسازد. بنابراین گزارش حفظ کاربر به تعریف تاریخچهٔ موجود و هویت محلی وابسته هست. این مرزها برای من بخشی از تحلیل صادقانهٔ Bunny Circus Analytics هستند و با حساب احرازشده یا هویت چنددستگاهی یکی نیستند.

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

چیزی که از این مرحله یاد گرفتم

برای من، تفسیر درست داده از تعریف درست شناسه شروع شد. شمارش نشست و اولین بازشدن وقتی قابل فهم هست که بدانم دربارهٔ نصب محلی حرف می‌زنم، نه دربارهٔ تمام زندگی یک بازیکن.

مثال عملی شناسهٔ نصب بازی

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

خطای رایج و علت آن

شناسهٔ نصب الزاماً حساب کاربری یا شخص یکتا نیست و می‌تواند پس از نصب دوباره تغییر کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. بدون دادهٔ حساب، تعداد نصب مشاهده‌شده را تعداد انسان‌های یکتا معرفی نکن. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.

چطور نتیجه را بررسی کنیم؟

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

پرسش‌های کاربردی دربارهٔ شناسهٔ نصب بازی

از کجا شروع کنم؟

از همان موقعیت محدود این مطلب شروع کن: دو اجرای همان نصب را با نصب دوباره و تغییر نام نمایشی بازیکن مقایسه کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.

چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟

زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. ثبات شناسه در اجرای معمول و رفتار آن در پاک شدن داده را توضیح بده. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. بدون دادهٔ حساب، تعداد نصب مشاهده‌شده را تعداد انسان‌های یکتا معرفی نکن.