الإجابة المختصرة: أغلب الفرق تتبع كل شيء ثم لا تقرأ شيئًا. تحليلات التطبيق المفيدة تبدأ بستة أحداث فقط: الفتح الأول، وبداية المهمة الأساسية، وإتمامها، والتسجيل، والفشل، والعودة في اليوم التالي. هذه الستة تجيب عن السؤال الوحيد الذي يهمّ في البداية: أين يتوقف الناس؟ أما تتبع كل ضغطة زر فينتج لوحات جميلة لا تغيّر قرارًا واحدًا، ويستهلك وقت المطوّرين، ويضخّم ما تعلنه من جمع بيانات في المتجرين.
القاعدة التي نعمل بها: لا تضف حدثًا حتى تعرف أي قرار سيغيّره. إن لم يكن للحدث قرار مرتبط به، فلا تتبعه.
الأحداث الستة الأساسية
1. الفتح الأول. متى فتح المستخدم التطبيق أول مرة، ومن أي مصدر جاء. هذا خط البداية لكل قياس لاحق.
2. بداية المهمة الأساسية. ما المهمة التي وُجد التطبيق لأجلها؟ الطلب، أو الحجز، أو البحث، أو رفع مستند. سجّل لحظة بدئها لا إتمامها فقط.
3. إتمام المهمة. اللحظة التي تحقّقت فيها القيمة. والنسبة بين هذا الحدث وسابقه هي أهم رقم في تطبيقك كله.
4. التسجيل أو تسجيل الدخول. بخطواته: فتح الشاشة، وإدخال الرقم، وإدخال الرمز، والنجاح. هذه الخطوات الأربع تكشف أكثر نقاط التسرّب شيوعًا.
5. الفشل. كل رسالة خطأ يراها المستخدم: فشل دفع، ورمز خاطئ، وانقطاع شبكة، وحقل مرفوض. سجّل نوع الخطأ وأين حدث.
6. العودة. فتح ثانٍ في يوم مختلف. هذا ما يبني منحنى الاحتفاظ، وهو الرقم الذي شرحنا أهميته في الاحتفاظ بمستخدمي التطبيق.
بهذه الستة تستطيع رسم المسار كاملًا: فتح ← بدأ ← تسجيل ← أتمّ ← عاد. وكل هبوط بين مرحلتين مشروع إصلاح واضح.
ما لا يستحق التتبع في البداية
كل ضغطة على كل زر. ضجيج يخفي الإشارة. التمرير وعمق التمرير في شاشات ليست محتوى طويلًا. وقت البقاء في كل شاشة بلا سؤال محدد تجيب عنه. فتح القائمة الجانبية. تغيير الإعدادات إلا إن كان إعدادًا حرجًا كتعطيل الإشعارات. كل شاشة على حدة قبل أن تعرف أي مسار يهمّك.
والقاعدة: ابدأ بستة، وأضف حدثًا واحدًا كلما واجهك سؤال لا تستطيع إجابته. النمو من الحاجة أفضل من التتبع الاحترازي.
المؤشرات التي تُقرأ أسبوعيًا
| المؤشر | ما يخبرك | متى يقلق | |—|—|—| | نسبة إتمام المهمة | صحة المنتج الأساسية | هبوط مفاجئ بعد إصدار | | احتفاظ اليوم الأول | قوة الدقيقة الأولى | أقل من نصف ما اعتدته | | احتفاظ اليوم السابع | قيمة حقيقية أم فضول | هبوط متواصل شهرين | | معدل الخطأ لكل جلسة | جودة تقنية وتجربة | ارتفاع بعد تحديث | | معدل الانهيار | استقرار | أي ارتفاع مفاجئ | | نسبة إكمال التسجيل | احتكاك البوابة | أقل من ثلثي من بدأ | | تعطيل الإشعارات | ضرر رسائلك | ارتفاع بعد حملة |
الخطأ الأشيع: قياس ما يسهل قياسه
عدد التحميلات وعدد المستخدمين النشطين رقمان يسهل عرضهما في اجتماع، ويصعب أن يغيّرا قرارًا.
لماذا؟ لأنهما يرتفعان بالإنفاق الإعلاني بغضّ النظر عن جودة المنتج. والرقم الذي لا يهبط حين يسوء منتجك ليس مؤشرًا بل زينة.
البديل: اقرأ النسب لا الأعداد. نسبة من أتمّ إلى من بدأ، ونسبة من عاد إلى من نزّل. النسب تكشف ما تخفيه الأعداد الكبيرة.
كيف تربط التحليلات بالخصوصية؟
كل حدث تجمعه يجب أن ينعكس في ما تعلنه للمتجرين، وأي تفاوت سبب رفض أو إيقاف كما شرحنا في نشر تطبيق على جوجل بلاي.
قواعد عملية:
لا تسجّل بيانات شخصية داخل أسماء الأحداث أو خصائصها. لا أرقام جوال، ولا بريدًا، ولا عناوين. استخدم معرّفًا داخليًا.
افصل التشخيص عن التتبع التسويقي. تقارير الأعطال ضرورة تقنية، وتتبع الإعلانات غرض آخر يخضع لأذونات مختلفة.
اجرد المكتبات دوريًا. كل أداة تحليلات أو إعلان تضيف بيانات ترسلها بلا أن يكتبها فريقك.
واحذف ما لا تستعمله. الحدث الذي لم يُقرأ منذ ستة أشهر يُحذف — يخفّف التطبيق، ويقلّل ما تعلنه، ويوفّر صيانة.
اقرأ المسار لا الشاشات
الطريقة العملية لاستخدام هذه الأحداث أن ترسم مسارًا من خمس نقاط وتقرأ الهبوط بينها:
افتح ← ابدأ: إن كان الهبوط هنا كبيرًا، فالشاشة الأولى لا تشرح ماذا يفعل التطبيق.
ابدأ ← سجّل: الهبوط هنا يعني بوابة تسجيل ثقيلة، وعلاجها في تسجيل الدخول في التطبيق.
سجّل ← أتمّ: الهبوط هنا يعني عائقًا في المهمة نفسها: حقول كثيرة، أو دفع فاشل، أو بطء.
أتمّ ← عاد: الهبوط هنا يعني تطبيقًا بلا سبب للعودة، وهي مشكلة منتج لا واجهة.
والقاعدة: أصلح أكبر هبوط واحد، ثم أعد القياس. إصلاح خمسة أشياء معًا يمنعك من معرفة ما نفع.
الفرق بين التحليلات وتقارير الأعطال
خلط شائع يجعل الفرق تظن أن أداة واحدة تكفي. الأداتان تجيبان عن سؤالين مختلفين:
التحليلات تجيب: أين توقّف المستخدم؟ وهي تصف سلوكًا، لا خللًا. المستخدم قد يتوقف لأن الشاشة مربكة، لا لأن شيئًا انكسر.
تقارير الأعطال تجيب: ماذا انكسر ولماذا؟ وهي تعطيك سطر الكود والجهاز ونسخة النظام.
والقراءة معًا تكشف ما لا تكشفه إحداهما: هبوط مفاجئ في إتمام المهمة + ارتفاع في الانهيارات على نظام معيّن = خلل يخصّ تلك الأجهزة. أما الهبوط بلا انهيارات فمشكلة تجربة لا برمجة.
أدوات: ماذا تحتاج فعلًا؟
ثلاث طبقات تكفي أغلب التطبيقات:
تحليلات المنتج لقياس الأحداث والمسارات والاحتفاظ.
تقارير الأعطال لمعرفة الانهيارات والأخطاء، وتفصيلها في انهيار التطبيق.
لوحات المتجرين لقياس ما قبل التحميل: مرات الظهور، والزيارات، ونسبة التحويل إلى تنزيل — وهي بيانات لا تعطيها لك أي أداة أخرى.
وما لا تحتاجه في البداية: أدوات تسجيل جلسات المستخدمين، ومنصات تجزئة معقّدة، وأي أداة تحتاج مهندسًا متفرغًا لصيانتها.
كيف تسمّي الأحداث؟
هذه تفصيلة تبدو شكلية، وهي سبب فوضى لا تُصلَح لاحقًا إلا بإعادة بناء. بعد عام من التطوير غير المنظّم تجد لديك ثلاثة أحداث تعني الشيء نفسه بأسماء مختلفة، فلا تثق بأي رقم.
اتفق على نمط واحد وسجّله في ملف يقرأه كل مطوّر:
فعل + كائن. مثل «بدأ_الطلب»، «أتمّ_الطلب»، «فشل_الدفع». لا أسماء شاشات، ولا أسماء أزرار.
اللغة واحدة. إن اخترت الإنجليزية للأسماء التقنية فالتزم بها كاملة؛ الخلط يُنتج ازدواجية بمرور الوقت.
الخصائص بدل الأحداث المتعددة. حدث واحد اسمه «أتمّ_الطلب» بخاصية «طريقة الدفع» أفضل من ثلاثة أحداث لكل طريقة. وإلا انفجر عدد الأحداث بلا فائدة.
وثّق كل حدث في جدول: الاسم، ومتى يُرسَل، وخصائصه، ومن طلبه ولماذا. صفحة واحدة تكفي، وغيابها يعني أن أحدًا بعد سنة لن يعرف معنى «حدث_٧».
من يملك القياس؟
المشكلة الشائعة ليست تقنية بل تنظيمية: التحليلات مسؤولية الجميع، فلا يقرؤها أحد.
الترتيب الذي ينجح:
شخص واحد مسؤول عن قراءة المؤشرات أسبوعيًا وإرسال ملخّص قصير.
اجتماع قصير كل أسبوعين يبدأ بالأرقام لا بالآراء، وينتهي بقرار واحد على الأقل.
قاعدة صارمة: أي طلب ميزة جديدة يُسأل عنه — أي رقم سيحرّكه؟ هذا السؤال وحده يوقف نصف الطلبات، ويحوّل النقاش من «أعجبني» إلى «يستحق».
ومراجعة ربع سنوية تحذف الأحداث الميتة والمؤشرات التي لم تغيّر قرارًا.
علامات أن قياسك معطوب
أرقام تختلف بين أداتين. طبيعي أن تختلف قليلًا، وغير طبيعي أن تتباعد كثيرًا. غالبًا السبب اختلاف تعريف «الجلسة» أو «المستخدم النشط» بينهما — وحلّها أن تعتمد أداة واحدة مرجعًا.
أرقام مثالية بلا تسرّب. إن كانت نسبة إتمام المهمة عالية جدًا، فغالبًا أنك تقيس من أتمّ فقط ولا تقيس من بدأ.
صفر أخطاء. لا يوجد تطبيق بلا أخطاء؛ الصفر يعني أنك لا تسجّلها.
رقم لم يتغيّر منذ شهور. إما أن الحدث توقّف عن الإرسال بعد إصدار، أو أنك تقرأ رقمًا مجمّدًا. افحص التسجيل قبل أن تفرح بالاستقرار.
أسئلة شائعة
متى أضيف أداة تحليلات؟
قبل الإطلاق بأسبوعين على الأقل، وجرّب أن الأحداث تصل فعلًا. أسوأ اكتشاف بعد الإطلاق أن البيانات لم تُسجَّل من أول يوم.
كيف أتأكد أن الأحداث تُسجَّل صحيحة؟
افتح وضع التصحيح في الأداة، وامشِ في المسار كاملًا على جهاز حقيقي، وتحقّق من ظهور كل حدث بخصائصه. وكرّر هذا الفحص بعد كل إصدار كبير — الأحداث تنكسر بصمت عند إعادة كتابة الشاشات.
هل أقيس المستخدمين مجهولي الهوية؟
نعم، وهذا ضروري لتعرف ما يحدث قبل التسجيل — وهو غالبًا حيث تفقد أغلب الناس.
كم مؤشرًا أعرض في لوحة الإدارة؟
خمسة إلى سبعة. اللوحة التي تحوي ثلاثين رقمًا لا يقرؤها أحد، والقرارات تُتخذ في اجتماع مدته ربع ساعة.
هل أقارن نفسي بمتوسطات السوق؟
بحذر. الأرقام المنشورة تخلط أنواعًا مختلفة جدًا من التطبيقات. المقارنة الأنفع مع نفسك عبر الزمن، ومع الإصدار السابق تحديدًا.
هل أتتبع المستخدمين بين التطبيق والموقع؟
مفيد إن كانت رحلة العميل تمرّ بالاثنين، لكنه يضاعف تعقيد الإعداد وما تعلنه من جمع بيانات. أجّله حتى تستقر قياساتك داخل التطبيق وحده.
ماذا أفعل بالبيانات القديمة بعد تغيير أسماء الأحداث؟
احتفظ بالقديم للمقارنة التاريخية، وابدأ سلسلة جديدة بوضوح، ودوّن تاريخ التغيير في ملف التوثيق. أسوأ ما يحدث أن يقارن أحد بعد سنة بين رقمين يقيسان شيئين مختلفين بلا أن يدري.
هل التحليلات تُبطئ التطبيق؟
إن أُسيء استخدامها نعم: إرسال كل حدث فور وقوعه على شبكة ضعيفة يستهلك أداءً وبطارية. الصحيح تجميع الأحداث وإرسالها دفعات، وهذا سلوك الأدوات الجيدة افتراضيًا.
من يقرأ هذه الأرقام في الشركة؟
شخص واحد مسؤول عن قراءتها أسبوعيًا ورفع ملخّص من ثلاثة أسطر: ما تحسّن، وما ساء، وما القرار. اللوحة بلا قارئ مسؤول تتحوّل إلى ديكور خلال شهر.
مثال كامل: تطبيق حجز مواعيد
لنطبّق كل ما سبق على حالة واقعية. تطبيق حجز في عيادة، والمهمة الأساسية: حجز موعد.
الأحداث الستة تصير:
- فتح أول (مع المصدر)
- بدأ_الحجز (فتح شاشة اختيار التخصص)
- سجّل_الدخول (بخطواته الأربع)
- أتمّ_الحجز (بخصائص: التخصص، والفرع، وكم يومًا قبل الموعد)
- فشل (نوعه: رمز خاطئ، لا مواعيد متاحة، فشل دفع)
- عاد (فتح في يوم لاحق)
وبعد أسبوعين تقرأ المسار فتجد مثلًا: من كل مئة فتحوا التطبيق، بدأ الحجز ستون، وأكمل التسجيل ثلاثون، وأتمّ الحجز خمسة وعشرون.
ماذا يعني ذلك؟ أكبر هبوط بين «بدأ» و«سجّل»: نصف من أراد الحجز توقّف عند بوابة التسجيل. وهذا يوجّه العمل فورًا إلى تبسيط الدخول لا إلى إضافة تخصصات أو تحسين الألوان.
وحدث الفشل يخبرك بالسبب الدقيق: إن كان أغلبه «لا مواعيد متاحة»، فمشكلتك تشغيلية لا تقنية — وهذه معلومة تخصّ الإدارة لا المطوّرين.
هذا هو الفرق كله: لوحة تخبرك بعدد المستخدمين لا تفيدك بشيء، ومسار من خمس نقاط يعطيك مهمة محددة لهذا الأسبوع.
الرقم الذي يستحق أن يعرفه الجميع
اختر مؤشرًا واحدًا يمثّل صحة المنتج — غالبًا نسبة إتمام المهمة الأساسية — واجعله معروفًا لكل من في الفريق.
لماذا واحد؟ لأن الفريق الذي يتابع عشرين رقمًا لا يتابع شيئًا. والرقم الواحد المعلن يوحّد القرارات: كل اقتراح يُقاس به، وكل إصدار يُحكم عليه بحركته.
وأضف إليه لاحقًا حين يستقر، لا قبل أن يصير مألوفًا للجميع.
الخلاصة: البيانات لا تنفع إلا حين تقود إلى قرار. ستة أحداث تُقرأ أسبوعيًا وتُغيّر شيئًا أنفع من ستين حدثًا في لوحة لا يفتحها أحد. ابدأ بالمسار الأساسي، وأصلح أكبر هبوط، وأعد القياس — وستتحسّن تطبيقك بخطوات صغيرة مؤكدة بدل قفزات تعتمد على الحدس. وهذا الترتيب جزء من طريقتنا في بناء أي منتج ضمن تصميم تطبيقات الجوال.