چرخهٔ عمر صفحه و مرز ارسال رویداد

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

دیدن یک صفحه و کلیک‌کردن در آن دو رفتار متفاوت‌اند. من لازم داشتم ورود، خروج و مدت حضور در صفحه را از رویداد دکمه جدا ثبت کنم.

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

AnalyticsScreenTracker.Enter زمان realtimeSinceStartup را نگه می‌دارد و ورود را می‌فرسته. Exit فقط اگر ورود ثبت شده باشد مدت را حساب می‌کنه و حالت isEntered را خاموش می‌کنه.

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

OnEnable و OnDisable به صورت قابل تنظیم به این دو متد وصل‌اند. screenId هویت صفحه را می‌دهد و نام رویداد از مسیر مرکزی Analytics می‌آید.

مرزهای فعلی

این مدت زمانِ فعال‌بودن component هست، نه الزاماً توجه واقعی بازیکن. Enter دوباره می‌تواند مبدا را عوض کنه و tracker خودش چرخهٔ foreground مسابقه را مدل نمی‌کنه.

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

در مرور سورس یک تفاوت مهم پیدا شد: وجود AnalyticsScreenTracker به معنای ارسال فعلی همهٔ رویدادهای آن نیست. این جزء مدت فعال بودن را محاسبه و مسیر مرکزی را فراخوانی می‌کنه، اما فهرست EssentialEvent در Analytics.cs نام‌های screen_enter و screen_exit را نمی‌پذیرد. بنابراین نسخهٔ فعلی wrapper ترافیک صفحه‌های رابط را فیلتر می‌کنه. من از دیدن callback نتیجه نمی‌گیرم که داده در فایل PHP ذخیره شده. این تفکیک برای هر بررسی آنالیتیکس لازم هست: تولید داده، پذیرش سیاست محلی، صف ارسال و پذیرش سرور مراحل جدا هستند و هر مرحله می‌تواند رویداد را متوقف کنه.

سورس سرور امکان تعریف رویداد و گزارش عمومی را داره، اما تعریف schema خودش رویداد بازی نمی‌سازد. اگر در آینده مشاهدهٔ صفحه لازم باشد، باید هم سیاست کلاینت روشن بشه و هم کد واقعی آن را از SDK مجاز ارسال کنه. تعریف Number برای مدت با ارسال عدد واقعی سازگار هست و میانگین می‌تواند بر اساس صفحه گروه‌بندی بشه. فیلد عددی غایب یا غیرعددی در محاسبه وارد نمی‌شود، پس تغییر نوع داده نتیجه را عوض می‌کنه. همچنین مدت این tracker فعالیت جزء هست و توجه چشم بازیکن نیست. سناریوی باز شدن دوبارهٔ پنل، غیرفعال شدن هنگام خروج و توقف برنامه برای تعیین معنای مدت مهم‌تر از ساخت یک نمودار زیباست.

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

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

برای من، یک عدد مدت بدون تعریف ارزشی نداره. این tracker مشاهدهٔ چرخهٔ صفحه را می‌دهد؛ برای تحلیل باید بدانم صفحه چه وقت فعال می‌شود و خروج آن در UI واقعی چه معنایی داره.

مثال عملی رویداد عمر صفحه

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

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

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

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

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

پرسش‌های کاربردی دربارهٔ رویداد عمر صفحه

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

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

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

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