تحليل السبب الجذري

"مقياس انخفض 20% الأسبوع الماضي. كيف ستحقق؟" هذا السؤال يختبر قدرتك على حل المشاكل بشكل منظم تحت الغموض.

إطار عمل التحقيق

اتبع هذا النهج المنظم:

1. وضّح وحدد نطاق المشكلة
2. تحقق من البيانات
3. جزّئ الانخفاض
4. ولّد الفرضيات
5. اختبر الفرضيات بالبيانات
6. حدد السبب الجذري
7. أوصِ بالإجراءات

الخطوة 1: الإيضاح والتحديد

قبل الغوص، اسأل أسئلة توضيحية:

السؤال	لماذا يهم
أي مقياس بالضبط؟	"الإيرادات" قد تعني أشياء كثيرة
ما الفترة الزمنية؟	أسبوع-على-أسبوع مقابل سنة-على-سنة
كم حجم الانخفاض؟	5% مقابل 50% تتطلب إلحاحاً مختلفاً
أي أحداث معروفة؟	إطلاق منتج، عطلة، انقطاع

مثال: "قبل أن أحقق، أريد التأكيد: ننظر للمستخدمين النشطين يومياً، الذين انخفضوا 20% هذا الأسبوع مقارنة بالأسبوع الماضي. هل هذه أول مرة نرى هذا النمط، أم هو موسمي؟"

الخطوة 2: التحقق من البيانات

لا تفترض أبداً أن البيانات صحيحة:

الفحص	ما تبحث عنه
تغييرات التسجيل	هل تغير كود التتبع؟
تغييرات التعريف	هل تغير حساب المقياس؟
مشاكل خط البيانات	فشل ETL، التكرارات، التأخيرات
القيم المتطرفة	عميل كبير واحد أو نشاط روبوت

رؤية المقابلة: "خطوتي الأولى ستكون التحقق إذا كان هذا تغيير حقيقي أو مشكلة جودة بيانات. سأنظر إذا تغير التسجيل أو كان هناك فشل ETL."

الخطوة 3: تجزئة الانخفاض

حلل المقياس لإيجاد أين يتركز الانخفاض:

أبعاد التجزئة الشائعة:

• المنصة (iOS، Android، الويب)
• الجغرافيا (البلد، المنطقة)
• نوع المستخدم (جديد مقابل عائد)
• مصدر الحركة (عضوي، مدفوع، إحالة)
• الجهاز (موبايل، سطح المكتب)
• الوقت (يوم عمل مقابل نهاية الأسبوع، ساعة اليوم)

مبدأ MECE: متبادل الحصرية، شامل جماعياً - الشرائح لا يجب أن تتداخل ويجب أن تغطي كل شيء.

مثال تحليل:
إجمالي DAU: -20%
├── الموبايل: -25%
│   ├── iOS: -5%
│   └── Android: -40% ← المشكلة هنا!
└── سطح المكتب: -10%

الخطوة 4: توليد الفرضيات

بناءً على التجزئة، اقترح أسباباً ممكنة:

اكتشاف الشريحة	الأسباب الممكنة
انخفاض خاص بـAndroid	خطأ تحديث التطبيق، مشكلة Play Store، إطلاق منافس
المستخدمون الجدد فقط	انتهت حملة التسويق، تغيير الإعداد
جغرافيا محددة	حدث محلي، مشكلة معالج الدفع، تغيير تنظيمي
وقت محدد	انقطاع الخادم، ارتفاع الحركة، فشل API

هيكل فرضياتك:

• تقني داخلي (أخطاء، أداء)
• منتج داخلي (تغييرات الميزات، تحديثات UI)
• سوق خارجي (منافس، اقتصاد)
• تقني خارجي (تغييرات المنصة، تحديثات API)

الخطوة 5: الاختبار بالبيانات

رتب الفرضيات حسب الأولوية بـ:

1. الاحتمالية (بناءً على النمط)
2. توفر البيانات (هل يمكننا التحقق من هذا؟)
3. القابلية للتنفيذ (هل يمكننا إصلاحه؟)

مثال اختبار:

الفرضية: تحديث تطبيق Android سبب خطأ
الاختبار: تحقق من إصدار التطبيق في البيانات
الاكتشاف: 95% من الانخفاض من v4.2 أُصدر الاثنين
الخلاصة: على الأرجح وُجد السبب الجذري

مثال المقابلة

السؤال: "معدل تحويل الصفحة الرئيسية انخفض 15% أمس. امشني خلال تحقيقك."

إجابة قوية:

"سأتناول هذا بشكل منظم:

توضيح: هل هذا 15% نسبي (5% → 4.25%) أم مطلق؟ ما فترة الثقة؟

تحقق: تحقق إذا تغير كود التتبع، ابحث عن مشاكل خط البيانات.

تجزئة: تحليل حسب:

• الجهاز: هل منصة واحدة انخفضت أكثر؟
• مصدر الحركة: عضوي مقابل مدفوع مقابل بريد
• نوع المستخدم: جديد مقابل عائد
• الجغرافيا: مشاكل إقليمية؟
• وقت اليوم: انخفاض مفاجئ أم تدريجي؟

فرضيات بناءً على النمط:

• إذا انخفاض مفاجئ في وقت محدد → على الأرجح تقني (نشر، انقطاع)
• إذا تدريجي طوال اليوم → على الأرجح منتج/خارجي
• إذا مصدر حركة واحد → على الأرجح مشكلة إسناد أو تسويق

اختبار: سأستعلم كل فرضية:

SELECT
    DATE_TRUNC('hour', timestamp),
    platform,
    COUNT(*) as sessions,
    SUM(converted) / COUNT(*) as conversion_rate
FROM homepage_visits
WHERE date >= CURRENT_DATE - 2
GROUP BY 1, 2
ORDER BY 1, 2

السبب الجذري + التوصية: بناءً على النتائج، حدد السبب وأوصِ إما بتراجع، إصلاح، أو مزيد من التحقيق."

أفضل الإجابات تظهر تفكيراً منظماً واختبار فرضيات مبني على البيانات، ليس القفز للاستنتاجات. :::