تحرّك metric ويحتاج أحدهم أن يعرف لماذا قبل الاجتماع. الـ signups منخفضة، والإيرادات ثابتة، والـ churn قفز — وأسوأ إجابة ممكنة هي تخمين واثق يتبيّن أنه query معطوب أو يوم بيانات مفقود. هذا النظام يجد السبب الحقيقي: يؤطّر الحركة مقابل baseline، ويفصّلها حسب الـ dimension الذي يفسّرها فعلًا، و — وهذا الأهم — يستبعد artifact في البيانات قبل أن يستنتج أن العمل التجاري تغيّر. الفرق بين «انهارت إعلانات paid ads» و«سلّمني أحدهم export نصف محمّل» هو هذا الانضباط.
- الـ metric والنافذة الزمنية: «signups، آخر أسبوع مقابل الأسابيع الأربعة قبله» — والملف الخام أو الـ table الذي خلفه، مثلًا
signups.csv. - baseline تثق به: الأسابيع السابقة، أو نفس الأسبوع من العام الماضي، أو تقرير الشهر الماضي — حتى يكون لكلمة 'تحرّك' شيءٌ يتحرّك مقابله.
- أي أحداث معروفة في النافذة — حملة انتهت، تغيير في التسعير، انقطاع خدمة، تغيير في الـ tracking — حتى لا يُخلط بين سبب من العالم الحقيقي وbug في البيانات، أو العكس.
-
قِس الحركة مقابل baseline
قبل مطاردة الأسباب، حدّد حجم التغيير بدقّة. في Claude Code Desktop، افتح المجلد الذي فيه ملف بيانات الـ metric واسأل في المحادثة — دون الحاجة إلى Terminal. «منخفض بكثير» يرسلك تبحث عن أزمة؛ «منخفض 9% أسبوعًا عن أسبوع، ضمن التأرجح الطبيعي» قد يكون مجرد ضجيج. ثبّته على baseline حتى تعرف إن كانت ثمّة حركة حقيقية تستحق التفسير أصلًا.
أنت تطلبمن signups.csv، أعطني إجمالي signups آخر أسبوع مقابل كلٍّ من الأسابيع الأربعة السابقة، إضافة إلى متوسط تلك الأربعة. وحدّد التغيير كرقم مطلق وكنسبة مئوية. هل هذه الحركة خارج التأرجح الأسبوعي الطبيعي الذي تراه في الـ baseline؟ما تحصل عليه «آخر أسبوع 1,180 signup؛ الأسابيع الأربعة السابقة بمتوسط 2,310 — انخفاض 49%. التأرجح الأسبوعي في الـ baseline كان ±8%، فانخفاض 49% خارج المعدّل الطبيعي بوضوح». الآن تعرف أنها إشارة حقيقية، لا ضجيج، وكم حجمها.
قِس الحركة دائمًا مقابل التأرجح الطبيعي للـ baseline أولًا. نصف أسئلة 'لماذا انخفض' تتلاشى حين ترى أن الـ metric كان ضمن مداه المعتاد.
-
استبعد البيانات والـ query أولًا
هذه هي الخطوة التي يتخطّاها الجميع ثم يندمون. انخفاض 49% هو تمامًا كيف يبدو يومٌ مفقود، أو تغيير في الـ tracking، أو bug في filter. صفّ هذه أولًا قبل أن تخبر أي أحد بأن العمل التجاري تغيّر.
أنت تطلبقبل أن نستنتج أن العمل التجاري تغيّر، استبعد artifact في البيانات. هل آخر أسبوع فيه الأيام السبعة كلها حاضرة (لا تواريخ مفقودة)؟ وهل قفز عدد الصفوف أو معدّل القيم الفارغة لأي column مقابل الأسابيع السابقة؟ وهل يمكن أن يفسّره تغيير في الـ tracking أو في الـ schema؟ وهل يَعُدّ الـ query آخر أسبوع على الأساس نفسه الذي يَعُدّ به أسابيع الـ baseline؟ما تحصل عليه شهادة سلامة أو دليل دامغ: «الأيام السبعة كلها موجودة؛ القيم الفارغة مستقرّة؛ لكن
sourceبقيمة NULL في 40% من صفوف آخر أسبوع مقابل 12% قبله — تغيير في الـ tracking يُرجّح أنه يُحصي أقل من اللازم، وقد يكون هذا جزئيًا artifact». في الحالتين صرتَ تعرف الآن إن كنت تطارد سببًا حقيقيًا. -
فصّلها حسب الـ dimension الذي يفسّرها
الحركة في السطر الأعلى هي مجموع حركات قطاعات. فكّكها حسب الـ dimension الأرجح أن يحمل السبب — channel، أو source، أو region، أو plan — حتى تعزل ماذا تحرّك بدل الجزم بـ لماذا.
أنت تطلبالآن فصّل انخفاض آخر أسبوع حسب الـ source مقابل الـ baseline. لكل source، أظهر آخر أسبوع، ومتوسط الـ baseline، والتغيير. أي source يفسّر معظم التراجع — هل هو متركّز في واحد، أم عريض عبرها كلها؟ما تحصل عليه تفصيل يحدّد الموقع: «paid_ads هبط من 1,040 إلى 95 (−91%)؛ وكل source آخر بقي ضمن ±6%». انخفاض متركّز في قطاع واحد يشير إلى سبب محدّد؛ وانخفاض عريض يشير إلى شيء منهجي — وهما تحقيقان مختلفان.
-
صُغ الفرضية واختبرها بالضغط
الآن تستطيع تسمية سبب — لكن اجعل Claude يجادل ضدّه أيضًا. الهدف استنتاج يصمد أمام متشكّك، مع الفحص الواحد الذي يؤكّده أو يقتله.
أنت تطلبإذن signups الـ paid_ads انهارت بينما ثبت كل شيء آخر. أعطني التفسيرات الثلاثة الأرجح لذلك الانخفاض المحدّد، والفحص الواحد الذي يؤكّد أو يستبعد كلًّا منها، وحدّد أي تفسير تدعمه البيانات أكثر — وما الدليل الذي قد يغيّر رأيك.ما تحصل عليه «الأرجح أن الحملة الـ paid انتهت أو بلغت سقف ميزانيتها يوم الثلاثاء — يؤكّده هبوط paid_ads إلى ما يقارب الصفر منتصف الأسبوع، لا تدريجيًا. أقل ترجيحًا: تعطّل ad-tracking (لكن المصادر الأخرى سليمة). افحص إنفاق منصّة الإعلانات لآخر أسبوع للتأكيد». سبب قابل للدفاع عنه مع تحقّق، لا حدس.
- هل تحرّك التعريف، لا العمل التجاري؟ قبل أن تلوم العالم، راجع قاموس المقاييس: تعريفٌ تغيّر بهدوء — 'active' صار يَعُدّ حدثًا مختلفًا، أو انزاح حدّ الشهر — يُنتج 'انخفاضًا' هو في الحقيقة تعديل. استبعد تغيّر التعريف جنبًا إلى جنب مع artifact في البيانات (انظر ابنِ قاموس المقاييس الذي يرثه كل query وكل تقرير).
- صعد الرقم على نحو غير متوقّع: التدفّق نفسه تمامًا يعمل مع قفزة مفاجئة — واستبعاد bug في العدّ المزدوج أو import مكرّر يهمّ هنا أكثر، لأن الأخبار الجيدة تخضع لتدقيق أقل.
- لم تعمل profile للملف بعد: إن كنت تحدّق في export طازج، شغّل استجوب الـ dataset قبل أن تلمسه أولًا — المدى الزمني ومعدّل القيم الفارغة اللذان يُبرزهما هما نصف خطوة 'استبعد البيانات' هنا.
- يظلّ يتحرّك (Power Track): إن كان الـ metric يتأرجح كثيرًا، اطوِ هذا داخل scheduled agent أو command باسم
/why(انظر تبويب Capabilities) يشغّل الـ baseline والتفصيل تلقائيًا ويُعلِم بالقطاع الذي تحرّك — لتبدأ التحقيق وأنت مُوجَّه نحو السبب أصلًا.
- لا تتخطَّ خطوة استبعاد-البيانات لتصل إلى قصة. «المنتج يفشل» المقولة بثقة وهي في الحقيقة يوم بيانات مفقود هي أغلى خطأ في هذه الصفحة — تحقّق من البيانات قبل أن تلوم العمل التجاري.
- الارتباط ليس سببًا. «paid_ads انخفض نفس الأسبوع الذي غيّرنا فيه التسعير» فرضية، لا اكتشاف — سمِّ الفحص الواحد الذي يؤكّدها، وعامل الاستنتاج كمؤقّت حتى تجريه.
- يستطيع Claude تحديد موقع الحركة وترتيب التفسيرات؛ أما القرار بشأن ما يجري حقًا فهو لك. اختبر فرضيّته الأولى بالضغط مقابل ما تعرف أنه حدث ذلك الأسبوع قبل أن تكرّرها كحقيقة.
- السبب الذي تُبلّغ عنه ادّعاء تتصرّف الشركة بناءً عليه — فتملّكه كما يليق. على مستوى المؤسسة، تُمرَّر إجابة 'لماذا تحرّك' إلى القرارات والميزانيات بسرعة. أرفِق الفحص المؤكِّد الواحد بالنتيجة، وأبقِ المحلّل الذي وجد السبب منفصلًا عن القائد الذي يتصرّف بناءً عليه، ولا تدع فرضية مؤقّتة تصعد للأعلى مصوغةً كسبب مؤكَّد.
ستحصل في النهاية على إجابة قابلة للدفاع عنها عن «لماذا تحرّك» — مقيسة مقابل baseline، ومصفّاة من artifacts البيانات، ومحدّدة الموقع في القطاع الذي تحرّك فعلًا، ومدعومة بالفحص الواحد الذي يؤكّدها — بدل تخمين ينهار أمام سؤال واحد.
أسئلة يطرحها الناس
- ما الذي أحتاج إعداده قبل البدء؟
- الـ metric وملف البيانات الخام (مثلًا `signups.csv`)، وbaseline تثق به (أسابيع سابقة أو نفس الأسبوع من العام الماضي أو تقرير الشهر الماضي)، وملاحظة بأي أحداث معروفة في النافذة الزمنية — حملة انتهت أو انقطاع خدمة أو تغيير في الـ tracking — حتى لا تخلط بين سبب من العالم الحقيقي وbug في البيانات.
- ماذا لو تبيّن أن التراجع مشكلة بيانات لا مشكلة تجارية؟
- هذا هو بالضبط ما تُعالجه خطوة 'استبعد البيانات أولًا'. يوم بيانات مفقود أو تغيير في الـ tracking أو bug في فلتر يمكن أن يبدو مطابقًا لانخفاض 49% في المبيعات — تصفية هذه الاحتمالات قبل إخبار أي أحد بأن العمل التجاري تغيّر هي الانضباط الذي يفصل بين اكتشاف مدروس وتراجع محرج.
- هل يمكنني استخدام هذا الـ playbook حين يصعد الرقم على نحو غير متوقّع؟
- نعم — نفس التدفّق يعمل مع قفزة مفاجئة. استبعاد bug في العدّ المزدوج أو import مكرّر يهمّ هنا أكثر، لأن الأخبار الجيدة تخضع لتدقيق أقل وهي بالتساوي عُرضة لوجود artifact في البيانات خلفها.
- Claude حدّد سببًا محتملًا — هل يمكنني الإبلاغ عنه مباشرةً؟
- تعامل معه كفرضية لا كاكتشاف حتى تُجري الفحص الواحد المؤكِّد. يطلب الـ playbook من Claude أن يسمّي الفحص الذي يؤكّد أو يستبعد كل تفسير — أجرِ هذا الفحص أولًا، ثم أبلغ عن الاستنتاج كمؤكَّد لا كتخمين من نموذج.