Discussions

أعمل بصورة مستقلة على موقع ألعاب عربية موجه أساسًا إلى مستخدمي الهاتف. يضم المشروع ألعابًا خفيفة مثل التلبيس، الطبخ، المكياج، تزيين الغرف والعناية بالحيوانات، ويمكن تشغيلها من المتصفح من دون الحاجة إلى تنزيل تطبيق لكل لعبة.

الموقع موجود حاليًا كتجربة ويب، لكنني أدرس تحسينه كتجربة PWA أو إنشاء تطبيق مرافق في مرحلة لاحقة. قبل اتخاذ هذه الخطوة، أحاول تصميم نموذج واضح لتتبع السلوك، وتقسيم المستخدمين، وتجربة البدء الأولى، والإشعارات التي قد تعيد المستخدم فقط عندما توجد فائدة حقيقية.

المشروع الذي أختبر عليه هذه الأفكار هو مجموعة العاب بنات، لذلك فإن السلوك الأساسي مختلف قليلًا عن تطبيق تجارة إلكترونية أو شبكة اجتماعية.

المستخدم لا يأتي غالبًا لإكمال مهمة طويلة. قد يدخل لأنه يريد لعبة طبخ لمدة عشر دقائق، يجرب لعبتين، ثم يغادر. وقد يعود بعد أسبوع بحثًا عن لعبة تلبيس أو مكياج. عدم العودة في اليوم التالي لا يعني بالضرورة أن التجربة فشلت.

لهذا لا أريد الاعتماد على معدل فتح التطبيق وحده، ولا أريد إرسال إشعارات يومية عامة من نوع: “عدي واكتشفي ألعابًا جديدة”.

أحاول بناء دورة تفاعل تعتمد على ما فعله المستخدم فعليًا.

رحلة المستخدم التي أفكر فيها

المسار الأساسي قد يكون كالتالي:

1. يفتح المستخدم الموقع أو التطبيق للمرة الأولى.
2. يرى عددًا محدودًا من التصنيفات الواضحة.
3. يفتح تصنيفًا مثل ألعاب الطبخ أو التلبيس.
4. يشاهد عدة بطاقات ألعاب.
5. يفتح صفحة لعبة.
6. يضغط على زر بدء اللعب.
7. قد يكمل الجلسة أو يخرج سريعًا.
8. قد يفتح لعبة أخرى من التصنيف نفسه.
9. قد يحفظ لعبة للمرة القادمة إذا وفرت هذه الميزة.
10. يعود لاحقًا إلى التصنيف نفسه أو يبحث عن نوع مختلف.

السؤال الأول لدي هو: ما الحدث الذي يجب اعتباره لحظة التفعيل الحقيقية؟

فتح الصفحة الرئيسية لا يكفي. حتى فتح صفحة لعبة لا يعني أن المستخدم بدأ اللعب فعلًا.

أفكر في اعتبار game_started حدث التفعيل الأساسي، لكن قد يكون هذا مبسطًا أكثر من اللازم. المستخدم الذي يبدأ لعبة ثم يغادر خلال ثوانٍ ربما لم يحصل على قيمة.

ربما يكون التعريف الأفضل هو واحد من التالي:

• بدء لعبة واحدة والبقاء داخلها لمدة معقولة؛
• بدء لعبتين في الجلسة نفسها؛
• العودة إلى الموقع مرة ثانية خلال فترة محددة؛
• حفظ لعبة؛
• فتح عدة ألعاب من التصنيف نفسه؛
• إكمال أي اثنين من هذه الإجراءات.

كيف تقيسون التفعيل في منتج ترفيهي قصير الجلسات؟

الأحداث التي أفكر في إرسالها من SDK

لا أريد جمع عشرات الأحداث التي لن تؤثر في قرار منتج أو رسالة لاحقة. القائمة الأولية هي:

app_opened
home_viewed
category_viewed
game_card_clicked
game_page_viewed
game_started
game_load_failed
game_exited
similar_game_clicked
search_performed
game_saved
game_unsaved
notification_opened
notification_dismissed

الخصائص المحتملة لكل حدث:

category_name
game_id
game_type
device_type
locale
traffic_source
session_number
days_since_first_visit
games_started_in_session
time_before_game_start
game_load_status

لا أريد تتبع ما يفعله المستخدم داخل لعبة مقدمة من طرف ثالث إذا لم أكن أملكها، ولا أريد جمع بيانات لا أحتاج إليها.

الهدف هو فهم المسار داخل المنتج نفسه:

• أي تصنيف اختاره المستخدم؟
• هل وجد لعبة وبدأها؟
• هل فشل تحميل اللعبة؟
• هل انتقل إلى لعبة مشابهة؟
• هل بحث ولم يجد نتيجة؟
• هل عاد إلى النوع نفسه لاحقًا؟

هل هذه القائمة كافية للمرحلة الأولى، أم أن هناك أحداثًا ضرورية أغفلتها؟

كيف أفرق بين تجربة سيئة وجلسة قصيرة ناجحة؟

هذه من أصعب النقاط بالنسبة لي.

قد يدخل المستخدم، يفتح لعبة واحدة، يلعب عشر دقائق ثم يغادر. هذه جلسة ناجحة على الأرجح، حتى إذا لم يفتح أي صفحة أخرى.

وفي حالة أخرى، قد يفتح خمس صفحات ألعاب لأن أزرار التشغيل غير واضحة أو لأن الألعاب لا تعمل. عدد الصفحات هنا مرتفع، لكنه علامة سيئة.

لذلك لا أريد استخدام مدة الجلسة أو عدد الصفحات وحدهما.

أفكر في دمج عدة إشارات:

• هل بدأ المستخدم اللعبة؟
• هل حدث خطأ تحميل؟
• هل عاد إلى صفحة التصنيف فورًا؟
• هل جرب لعبة ثانية؟
• هل حفظ لعبة؟
• هل عاد في يوم مختلف؟
• هل كرر زيارة النوع نفسه؟

كيف يمكن بناء مقياس “جلسة لعب ناجحة” عندما تكون اللعبة نفسها داخل iframe أو مصدر خارجي ولا يمكنني قياس كل ما يحدث بداخلها؟

تقسيم المستخدمين حسب الاهتمام الفعلي

أريد أن تكون المجموعات سلوكية، لا ديموغرافية.

لا أحتاج إلى سؤال المستخدم عن عمره أو موقعه إذا لم تكن هذه المعلومات ضرورية. ما يهمني أكثر هو نوع الألعاب التي يختارها وطريقة استخدامه للموقع.

المجموعات الأولية التي أفكر فيها هي:

مستخدم جديد لم يبدأ أي لعبة

فتح الصفحة الرئيسية أو تصنيفًا، لكنه لم يصل إلى game_started.

الاستجابة المحتملة:

• تبسيط الصفحة الرئيسية في الزيارة التالية؛
• عرض ثلاثة تصنيفات فقط بدل قائمة طويلة؛
• إبراز ألعاب تبدأ بسرعة على الهاتف؛
• عدم إرسال أي إشعار بعد.

مستخدم مهتم بتصنيف واحد

بدأ عدة ألعاب طبخ مثلًا، ولم يفتح تصنيفات أخرى.

الاستجابة المحتملة:

• ترتيب ألعاب الطبخ في موضع أعلى؛
• عرض ألعاب مشابهة بعد نهاية الجلسة؛
• السماح له بمتابعة التصنيف إذا اختار ذلك؛
• عدم إرسال توصيات مكياج أو تلبيس غير مرتبطة بسلوكه.

مستخدم يجرب أنواعًا متعددة

ينتقل بين التلبيس والطبخ والديكور والعناية بالحيوانات.

الاستجابة المحتملة:

• تقديم قائمة “جربي شيئًا مختلفًا”؛
• إرسال ملخص أسبوعي اختياري بدل عدة إشعارات؛
• عدم تثبيت الصفحة الرئيسية على تصنيف واحد.

مستخدم يبدأ ألعابًا كثيرة ثم يغادر بسرعة

قد يعني ذلك أن الصور لا تمثل اللعب الحقيقي، أو أن الألعاب بطيئة، أو أن المستخدم لا يجد النوع المطلوب.

الاستجابة المحتملة:

• عدم اعتباره مستخدمًا عالي التفاعل تلقائيًا؛
• تحليل game_load_failed ووقت التحميل؛
• عرض ألعاب أخف وأوضح في الزيارة التالية؛
• سؤاله باختصار عن النوع الذي يبحث عنه، بدل إرسال إشعار عودة.

مستخدم يعود إلى لعبة محفوظة

هذا أقوى دليل لدي على وجود نية حقيقية.

الاستجابة المحتملة:

• إبراز الألعاب المحفوظة؛
• اقتراح لعبتين مشابهتين فقط؛
• إشعاره إذا أصبحت لعبة محفوظة غير متاحة أو أضيفت لعبة قريبة منها.

هل هذه المجموعات كثيرة على منتج في بدايته؟ هل الأفضل البدء بثلاث مجموعات فقط: جديد، بدأ اللعب، وعائد؟

تجربة الـ Onboarding

لا أريد أن أضع خمس شاشات قبل أن يرى المستخدم الألعاب.

التجربة الأساسية يجب أن تسمح بالتصفح فورًا. لكنني أفكر في اختبار سؤال اختياري واحد:

ما النوع الذي ترغبين في لعبه الآن؟

والخيارات مثل:

• تلبيس؛
• طبخ؛
• مكياج؛
• ديكور؛
• حيوانات؛
• أريد الاستكشاف.

يمكن تخطي السؤال مباشرة.

المتغير الأول في الاختبار:

• فتح الصفحة الرئيسية وعرض الألعاب فورًا.

المتغير الثاني:

• سؤال واحد عن النوع، ثم عرض ألعاب هذا التصنيف.

المقياس الأساسي لن يكون إكمال الـ Onboarding فقط، بل:

• الوقت حتى بدء أول لعبة؛
• نسبة من بدأوا لعبة؛
• عدد مرات الرجوع قبل بدء اللعب؛
• نسبة العودة في جلسة لاحقة؛
• نسبة من غيروا التصنيف بعد الاختيار الأول.

أفترض أن سؤالًا واحدًا قد يساعد المستخدم الذي يعرف ما يريد، لكنه قد يضيف خطوة غير ضرورية لمن يريد تصفح الصور.

هل تنصحون بسؤال البداية هذا، أم أن استنتاج الاهتمام من أول تصنيف يتم فتحه أفضل؟

متى أطلب إذن الإشعارات؟

لا أرى أي مبرر لطلب الإذن فور فتح التطبيق.

في تلك اللحظة لم ير المستخدم أي لعبة، ولا يعرف هل يريد العودة أصلًا. الموافقة التي نحصل عليها مبكرًا قد تكون ضعيفة الجودة، وقد يعطل المستخدم الإشعارات بعد أول رسالة غير مناسبة.

أفكر في طلب الإذن فقط بعد أحد هذه الإجراءات:

• حفظ لعبة؛
• بدء عدة ألعاب من التصنيف نفسه؛
• العودة إلى الموقع للمرة الثانية؛
• اختيار متابعة تصنيف محدد.

الرسالة يجب أن تشرح الفائدة بوضوح:

“هل تريدين معرفة الألعاب الجديدة التي تضاف إلى قسم الطبخ؟”

بدل رسالة عامة مثل:

“فعّلي الإشعارات حتى لا يفوتك شيء.”

هل اختيار التصنيف أو حفظ لعبة إشارة كافية لطلب الإذن، أم يجب الانتظار حتى الزيارة الثانية؟

استراتيجية الإشعارات التي أفكر فيها

أريد أن تكون الإشعارات نادرة ومرتبطة بالسلوك.

إضافة ألعاب إلى تصنيف متابع

“أضيفت ثلاث ألعاب طبخ جديدة إلى القسم الذي تتابعينه.”

لعبة مشابهة لما تم حفظه

“وجدنا لعبة تزيين كعك قريبة من اللعبة التي حفظتها.”

العودة إلى مجموعة محفوظة

“ألعابك المحفوظة ما زالت متاحة للعب من الهاتف.”

مشكلة تم إصلاحها

“اللعبة التي لم تعمل في زيارتك السابقة أصبحت متاحة الآن.”

لا أريد إرسال:

• إشعار يومي لمجرد أن المستخدم لم يفتح التطبيق؛
• رسالة عامة تطلب العودة دون سبب؛
• توصيات من تصنيفات لم يزرها؛
• إشعارات متكررة بعد تجاهل الرسائل السابقة.

الحدود الأولية التي أفكر فيها:

• إشعار سلوكي واحد كحد أقصى كل سبعة أيام؛
• لا إشعارات قبل وجود اهتمام واضح؛
• إيقاف رسائل إعادة التفاعل بعد تجاهل رسالتين؛
• السماح للمستخدم باختيار التصنيف والتكرار؛
• عدم اعتبار عدم العودة خلال سبعة أيام علامة على فقد المستخدم.

هل سبعة أيام كثيرة أم قليلة لهذا النوع من المنتجات؟ قد تكون دورة الاستخدام الطبيعية غير منتظمة؛ ربما يعود المستخدم عندما يشعر بالملل فقط، وليس وفق جدول أسبوعي.

تجارب A/B التي قد أبدأ بها

الاختبار الأول: عرض الألعاب فورًا أم سؤال عن الاهتمام؟

المتغير A: الصفحة الرئيسية مباشرة.

المتغير B: سؤال اختياري عن نوع اللعبة.

المقاييس:

• بدء أول لعبة؛
• الوقت حتى بدء اللعب؛
• عدد الصفحات قبل اللعب؛
• العودة في جلسة لاحقة.

الاختبار الثاني: زر “العب الآن” أم تشغيل اللعبة مباشرة؟

المتغير A: صورة وزر واضح، ثم تحميل اللعبة بعد النقر.

المتغير B: تحميل اللعبة تلقائيًا عند فتح الصفحة.

المقاييس:

• معدل بدء اللعبة؛
• وقت تحميل الصفحة؛
• معدل فشل اللعبة؛
• الرجوع السريع؛
• استهلاك البيانات على الهاتف إن أمكن قياسه بصورة مسؤولة.

الاختبار الثالث: توصيات حسب التصنيف أم حسب آخر لعبة؟

المتغير A: ألعاب أخرى من التصنيف نفسه.

المتغير B: ألعاب تشترك في طريقة اللعب نفسها، حتى لو كانت في تصنيف مختلف.

مثلًا، مستخدم لعب تزيين كعكة قد يفضل تصميم غرفة لأن النشاط في الحالتين يعتمد على الاختيار والتزيين، رغم اختلاف التصنيف.

الاختبار الرابع: توقيت حفظ اللعبة

المتغير A: زر الحفظ ظاهر منذ البداية.

المتغير B: شرح الحفظ بعد بدء اللعبة الأولى.

أخشى أن يكون ظهور زر الحفظ مبكرًا عنصرًا إضافيًا قبل أن يعرف المستخدم قيمة اللعبة. لكن إخفاءه قد يجعل ميزة العودة غير مكتشفة.

أي اختبار من هذه الاختبارات يعطي أكبر معلومة في المرحلة الأولى؟

المقاييس التي أريد استخدامها

المقاييس التقليدية مثل Day-1 وDay-7 مهمة، لكنها قد لا تشرح المنتج وحدها.

أفكر في قياس:

• الوقت حتى أول لعبة؛
• نسبة الزيارات التي تصل إلى game_started؛
• نسبة فشل تحميل الألعاب؛
• عدد الألعاب التي بدأت في الجلسة؛
• نسبة حفظ الألعاب؛
• العودة إلى لعبة محفوظة؛
• العودة إلى التصنيف نفسه؛
• فتح الإشعارات؛
• تعطيل الإشعارات؛
• عدد جلسات اللعب الناجحة لكل مستخدم؛
• نسبة المستخدمين الذين يجدون لعبة خلال عدد قليل من النقرات.

لا أريد زيادة مدة الجلسة بصورة مصطنعة. إذا وجد المستخدم اللعبة المناسبة بسرعة وبدأ اللعب، فهذا أفضل من إبقائه يتنقل بين الصفحات.

الأسئلة التي أحتاج إلى رأي عملي فيها

أود سماع تجارب من عمل على SDK للأحداث، تقسيم المستخدمين، Onboarding، إشعارات الدفع أو A/B Testing في تطبيقات الألعاب والمحتوى الخفيف.

أسئلتي الأساسية هي:

1. ما الحدث الأنسب لتعريف التفعيل في هذا النوع من المنتجات؟
2. كيف يمكن قياس نجاح جلسة لعبة داخل iframe خارجي؟
3. ما أقل مجموعة أحداث تكفي للإصدار الأول؟
4. هل تقسيم المستخدمين حسب نوع اللعبة وحده مفيد، أم يجب إضافة نمط السلوك؟
5. هل سؤال اهتمام واحد في البداية مفيد أم أنه يؤخر اللعب؟
6. متى يصبح طلب إذن الإشعارات منطقيًا؟
7. ما فترة عدم النشاط المناسبة عندما يكون الاستخدام غير منتظم؟
8. أي تجربة A/B يجب تنفيذها أولًا؟
9. كيف تفرقون بين مستخدم وجد لعبة بسرعة ومستخدم غادر بسبب مشكلة؟
10. ما البيانات التي يجب تجنب جمعها في منتج ألعاب بسيط؟

هدفي ليس زيادة عدد مرات فتح التطبيق بأي وسيلة. أريد أن يجد المستخدم لعبة مناسبة بسرعة، ثم يحصل على سبب حقيقي للعودة عندما توجد لعبة جديدة مرتبطة بما اختاره سابقًا.

أي اقتراحات عملية حول تسمية الأحداث، بنية خصائص المستخدم، قواعد التقسيم، حدود تكرار الإشعارات، أو تصميم التجارب ستكون مفيدة.