الترويج / ROBLOX
مسار متجر Roblox: فصل الزيارات المتكررة عن نتائج الشراء
خطط لتحليل متجر يفتحه اللاعب عدة مرات في جلسة واحدة. ميّز المحاولات باستخدام funnelSessionId وحدد خطوات قابلة للملاحظة، دون تحويل مشاهدة منتج إلى شراء غير مؤكد.
اختر سؤالاً لمسار متكرر #
تخيل متجر عناصر تدريبية يفتح اللاعب نافذته ويشاهد بطاقة ثم يغلق ويعود لاحقاً. سجل واحد يقول إنه زار المتجر لا يشرح المحاولتين. قد تنتهي الأولى بالمشاهدة وتصل الثانية إلى طلب شراء. ابدأ بسؤال يحتاج فصل الزيارات: عند أي خطوة تتوقف المحاولات الفردية؟
نستخدم مسار PracticeShop افتراضياً لتخطيط قياس لعبة مستقبلية، وليس تقرير أداء ألعابنا. لم نرسل أحداث AnalyticsService ولم ننفذ مشتريات أو نغير كود الألعاب. لا توجد أرقام تحويل مقاسة. اتفق أولاً على معنى المحاولة وكل خطوة، ثم نفّذ ملاحظتها.
عرّف بداية محاولة واحدة ونهايتها #
اكتب أي فتح مؤكد للمتجر يبدأ محاولة جديدة. ثم حدد معنى الإغلاق والتنقل بين الأقسام والعودة. يمكن أن يبقى تغيير بطاقات المنتجات داخل الزيارة نفسها؛ هذا قرار المشروع. لا تنشئ محاولة لكل إطار من الواجهة أو تغير في الاختيار.
في مثالنا ينهي الإغلاق المحاولة A وتبدأ إعادة الفتح المحاولة B. تسمح هذه الحدود بفحص التصميم بأفعال عادية. سجلها مع نسخة المسار. إذا تغيرت لاحقاً، تحتاج الأحداث القديمة والجديدة إلى تفسير، بدلاً من أن تبدو وصفاً لمسار واحد لم يتغير.
افتح الصورة بالحجم الكامل ↗افصل هوية اللاعب عن هوية المحاولة #
يربط funnelSessionId خطوات المحاولة الواحدة في المسار المتكرر ويميزها عن محاولة أخرى للاعب نفسه. قد تضم جلسة اللعب زيارات متعددة للمتجر. لذلك اللاعب نفسه والمحاولة نفسها علاقتان مختلفتان يجب أن يحفظهما السجل.
الحرفان A وB في المخطط تسميتان تدريبيتان وليسا معرفين حقيقيين. يحتاج السيناريو الجديد إلى معرف جديد، وتستخدم خطواته التالية المعرف نفسه. هناك خطآن متعاكسان: معرف ثابت يخلط الزيارات، ومعرف جديد لكل خطوة يفصل التسلسل. افحصهما قبل الاعتماد على الرسم البياني.
افتح الصورة بالحجم الكامل ↗أنشئ قاموس خطوات قابلة للملاحظة #
حدد لكل خطوة رقماً واسماً قصيراً وشرط اكتمال دقيقاً. مثلاً يعني ShopOpened الفتح المتفق عليه، وItemViewed عرض البطاقة المختارة، وCheckoutRequested بدء عملية الشراء المقصودة. هذه أسماء توضيحية. يجب أن يفهم مطوران اللحظة نفسها التي يجوز عندها تسجيل الحدث.
تعني خطوة GrantConfirmed الأخيرة منحاً مؤكداً فقط عند وجود نظام شراء ومنح مفحوص بشكل مستقل. الضغط على زر أو ظهور نافذة الدفع أو إغلاقها لا يكمل الخطوة. إذا لم يكن المنح جاهزاً، اجعل المسار التدريبي ينتهي بالمشاهدة. قياس محدود وصادق أنفع من مسار يبدو كاملاً بنهاية مختلقة.
| خطوة توضيحية | ما تؤكده |
|---|---|
| ShopOpened | الفتح المتفق عليه |
| ItemViewed | عرض البطاقة المختارة |
| CheckoutRequested | بدء عملية الشراء |
| GrantConfirmed | المنح المؤكد فقط |
حدّد مصدر الحدث على الخادم #
يسمح التوثيق بهذه الأحداث من الخادم في الألعاب المنشورة، وليس من Studio أو العميل. افصل ملاحظة الواجهة عن قرار الخادم بصحة الخطوة. يجب مثلاً أن يرتبط تقرير مشاهدة منتج بمحاولة موجودة وخطوة مسموحة، لا برقم عشوائي يرسله العميل.
جهّز خريطة تضم الشرط ومنطق الخادم الذي يؤكده ورقم الخطوة والمعرف. لا يحتوي المقال متجراً جاهزاً أو أداة تحقق عامة. توضح الخريطة العمل المطلوب. كذلك تختلف عملية اللعبة عن ملاحظتها التحليلية؛ تسجيل خطوة لا ينبغي أن يمنح عنصراً أو ينشئ حق الحصول عليه.
افحص تكرار الخطوة نفسها #
قد تُعرض بطاقة مرة أخرى داخل المحاولة نفسها. يوضح التوثيق أن المسار يعتبر أول ظهور للخطوة المتكررة، بينما تستمر الإرسالات الإضافية في استهلاك حد التكرار. غياب الأعداد المضاعفة عن الرسم لا يثبت أن المعالج نُفذ مرة واحدة أو تجنب العمل غير الضروري.
خطط لحالات منفصلة: مشاهدة البطاقة نفسها ثانية، واختيار أخرى، وإعادة فتح المتجر. هذه أفعال مختلفة. سجل المعرف والرقم المستخدمين لكل منها وقارنهما بحدود السيناريو. لا تضف إرسالاً متكرراً بلا معنى كي يبدو التقرير نشطاً؛ تحتاج كل ملاحظة إلى سبب واضح.
احفظ معنى الخطوات المتجاوزة #
يمكن لخطوة متأخرة أن تكمل السابقة تلقائياً في تقرير المسار. لا يثبت هذا أن معالجاتك لاحظت كل الأفعال المبكرة. إذا ظهر المنح وكانت تسجيلات الفتح قليلة، فافحص ترتيب الإرسال وشروطه قبل تفسير النتيجة باعتبارها سلوك اللاعبين.
ضمّن حالة مقترحة تغيب فيها خطوة مبكرة، وافصل سلوك التقرير المتوقع عن سجل الاستدعاءات الفعلية. هذا ليس سبباً لإرسال إنجازات وهمية. الهدف اكتشاف طريق معطوب أو ملاحظة ناقصة. ميّز أفعال اللعبة المعروفة عما تستنتجه أداة التحليل من حدث متأخر.
تتبع زيارتين في السجل #
يفتح اللاعب في السيناريو الأول المتجر ويشاهد عنصراً ويغلق دون شراء. وفي الثاني يعيد الفتح ويبدأ عملية الشراء المقصودة. يجب أن يميز السجل A وB وترتيب الخطوات داخل كل محاولة. طلب الشراء في الزيارة الثانية لا يزال مختلفاً عن الدفع والمنح.
احتفظ بالتسمية التدريبية والبداية والأرقام المستخدمة وسبب النهاية. سجّل المنح فقط بعد تأكيد نظامك. يعرض الجدول خطة وتوقعات وليس نتائج لعب منفذ. يفحص المطور الإرسال في بيئة منشورة مناسبة؛ لم نرسل أحداثاً حقيقية لهذا الدليل.
اقرأ التقرير بحسب النسخة والفترة #
قارن التقرير بقاموس الخطوات ونسخة السيناريو. بعد تغيير تعريف الفتح أو اسم خطوة، اختر فترة النسخة المناسبة وعلّم حد التحديث. قد تخفي فترة مختلطة تغير المعنى حتى إذا بقيت الأرقام نفسها.
يحدد التوثيق التتبع بآخر عشرة قيم فريدة من funnelSessionId لكل لاعب ومسار. لا تستخدم الآلية كأرشيف غير محدود للمحاولات، ولا تعاود استخدام معرف قديم لاستكمال زيارة أغلقت منذ زمن. يحتاج الاستنتاج إلى بيانات فعلية وعينة واضحة. لا نقدم أياً منهما هنا، ولذلك لا ندعي زيادة المشتريات.
سلّم المطور وصفاً واضحاً #
شارك السؤال وحدود المحاولة والقاموس وخريطة شروط الخادم وقواعد المعرفات وسجلي الزيارتين المقترحتين. أضف الفحوص التي لم تُنفذ. يمكن لدردشة أخرى متابعة القياس دون تخمين معنى الشراء أو خلط جلسة اللعب بزيارة المتجر.
تصميم القياس لا يضمن تحسن المبيعات ولا يستبدل معالجة المنح. أهداف الموقع تراقب أفعالاً مختلفة ولا تؤكد مشتريات داخل اللعبة. يقدم هذا المقال مخططات أصلية وفحوصاً مقترحة دون دفع أو تحويلات حقيقية أو تعديل ألعابنا. تحقق من التنفيذ قبل تفسير ملاحظاته.
| الوصف | ما يُسجل |
|---|---|
| الحدود | بداية المحاولة ونهايتها |
| القاموس | الرقم والاسم والشرط |
| المصدر | منطق الخادم المؤكد |
| النسخة | التاريخ وتغير المعنى |
المصادر الأصلية
Roblox Creator Hub — Funnel eventsRoblox Creator Hub — AnalyticsService API
