أساس البيانات: أتقِن الوثائق الثلاث التي يقوم عليها كل تحليل

بين يدي فريقك الآن playbooks الـ dataset-profile والـ metrics-dictionary والـ analysis-brief — ثلاث وصفات مفصّلة تستجوب بها ملفًا، وتعرّف مؤشرًا، وتضبط نطاق طلب، خطوة خطوة. هذه الوحدة طبقة أعلى من الوصفة: هنا تُتقن الأشياء الثلاثة التي يستند إليها كل query ورسم بياني وعرض نتائج لاحق — ماذا تحتوي بياناتك فعلًا، وماذا تعني أرقامك فعلًا، وأي سؤال تجيب عنه فعلًا — وتبنيها على بيانات حقيقية، وتثبت أمام معايير تقييم أنك أهلٌ لذلك.

هذه هي الوحدة الأولى من مسار البيانات والمحلّلين المعتمَد، وقد تعمّدنا إبقاءها مفتوحة: اقرأها وأنجِز تكليفها، وستعرف بنفسك ماذا يساوي هذا العمق قبل أن تُلحق فريقًا ببقية المسار.

كل رقم يخرج من فريقك — كل لوحة متابعة، وكل نتيجة query، وكل عرض نتائج أمام الإدارة — إنما يُسحب من ثلاثة أرصدة: ماذا تحتوي البيانات فعلًا، وماذا يعني المؤشر فعلًا، وأي سؤال نجيب عنه فعلًا. ومعظم الفرق لم تودِع في الأرصدة الثلاثة شيئًا، فيبدأ كل تحليل بتوصيف أعمى، ويعيد حساب ‘active’ بطريقة جديدة، ويجيب عمّا قيل لا عمّا قُصد. الأساس هو الساعة التي تملأ فيها الأرصدة الثلاثة مرة واحدة — وهي أعلى ساعة مردودًا في المسار كله.

لماذا هذه الساعة هي الأعلى مردودًا في المسار كله

التحليل يفشل بصمت، لا بضجيج. لا أحد يسلّم تقريرًا مكتوبًا فيه «الإيراد: غير معروف»؛ بل يسلّم تقريرًا يقول «الإيراد: 474,800 درهم» — واثقًا، منسّقًا، في موعده — مبنيًّا على عمود لم يفحصه أحد، وفق تعريف لم يدوّنه أحد، جوابًا عن سؤال لم يقصده أحد. والرسم البياني يغسل الشكّ غسلًا: ما إن يستقر رقم في شريحة عرض حتى يكفّ الجميع عن إعادة اشتقاقه.

عطبان اثنان يقفان وراء كل رقم خاطئ يصل إلى الإدارة تقريبًا. الأول التحليل الأعمى — أن تستعلم من ملف لم تفتحه قط، واثقًا أن status يعني ما يوحي به اسمه، وأن نطاق التواريخ يغطي ما افترضته، وأن لكل عميل صفًّا واحدًا لا صفًّا عن كل تجديد. الافتراض الفاسد الذي يدخل في أول الطريق يسمّم كل ما يُبنى فوقه، ولا يظهر له أثر في الناتج — لأن الناتج يظل يشبه أي رقم طبيعي. والثاني التعريف المنزلق — محلّلان يسحبان «العملاء النشطين» فيخرجان برقمين مختلفين، وكلاهما مصيب، لأن ‘active’ لم يُكتب يومًا في مكان يقرؤه الاثنان. في الفريق الصغير هذه لحظة محرجة في اجتماع؛ وفي المؤسسة تسريبُ مصداقية: عرض مجلس الإدارة يقول شيئًا ولوحة العمليات تقول غيره، فيذهب الاجتماع كله في مطابقة التعريفات بدل البحث عن الخلاصة.

ثلاثة أشياء تسدّ العطبين معًا قبل أن يُكتب أي query. الملف الموصوف يعني أنك تعرف ما بين يديك بالضبط — عدد الصفوف، ومعنى كل عمود، ومواضع الاتساخ — قبل أن تثق بإجمالي واحد مبني عليه. وقاموس المؤشرات يعني أن لكل من ‘active’ و’churn’ و’revenue’ تعريفًا واحدًا معتمدًا له مالك، فيسحب محلّلان المؤشر نفسه ويخرجان بالرقم نفسه. والـ brief يعني أن السؤال مثبّت — القرار الذي يخدمه، والصيغة الدقيقة، وما هو خارج النطاق — قبل أن يلمس أحد أي query، فتبني التحليل الصحيح مرة واحدة بدل ثلاث مرات. ابنِ الثلاثة، وسترى أثرها في كل وحدة لاحقة: محرّك الاستعلام في الوحدة الثانية يثق بالأعمدة لأن الأولى وصّفتها؛ وعروض الوحدة الرابعة تستشهد بالـ churn مطمئنةً لأن الأولى عرّفته؛ والتقرير الدوري في الخامسة لا يعيد فتح النطاق كل شهر لأن brief الأولى رسم الحدّ.

اقفز فوق هذه الوحدة، وكل ما سيفعله Claude أنه يعين فريقك على الاستعلام بسرعة أكبر من بيانات لم يتحقق منها أحد، وفق تعريفات لم يتفق عليها أحد — وهذا أسوأ، لا أحسن: الرقم الخاطئ الواثق يصل أسرع من «لست متأكدًا بعد» الصادقة. املأ الأرصدة الثلاثة أولًا، وسيخرج كل تحليل بعدها أدقّ وأسلم دون جهد إضافي.

التوصيف — الحسّ الذي لا تعلّمك إياه الوصفة

الـ playbook يعطيك الخطوات: افتح الملف، واطلب من Claude أن يصفه لك. الإتقان هو الحسّ المهني داخل الخطوة — القرارات التي تفصل بين توصيف يمسك الاتساخ فعلًا، وآخر لا يفعل إلا تأكيد ما كنت تفترضه أصلًا.

• عدد الصفوف عقدُك مع الملف — تحقق منه ولا تقبله. قبل أن تبني شيئًا، لا بد أن يطابق العددُ الذي يذكره Claude رقمًا تستطيع فحصه من مصدر مستقل: عدّاد أداة التصدير نفسها، أو الرقم الذي أخبرك به صاحب الطلب، أو عدد الشهر الماضي زائدًا أو ناقصًا فرقًا معقولًا. توصيفٌ يقول «8,432 صفًّا» ويسكت لم يقل لك شيئًا؛ وتوصيفٌ يقول «8,432 صفًّا، ولوحة أداة التصدير تعرض 8,432 أيضًا» قال لك إن الملف غير مبتور. المسافة بين الجملتين هي قيمة التوصيف كلها.
• العمود الذي يكذب هو الذي يوقعك. في كل مجموعة بيانات عمودٌ واحد على الأقل يَعِد اسمُه بما لا تفي به قيمُه — حقل status فيه قيمة لا تعني قراءتها البديهية، وعمود plan يسجّل ما طُلب لا ما هو ساري المفعول، وعمود date هو في حقيقته طابع إنشاء متنكّر في هيئة تاريخ حدث. اقرأ عيّنة من القيم الفعلية لكل عمود قبل أن تصدّق عنوانه. العنوان فرضية؛ والقيم هي الدليل.
• الفراغات خلاصة بحدّ ذاتها، لا ضوضاء تُنحّى. عمودٌ فارغ في 12% من صفوفه ليس «سليمًا في معظمه» — بل حقيقة عن طريقة جمع بياناتك تغيّر ما يجوز لك ادّعاؤه. إن بنيت تفصيلًا على ذلك العمود وأسقطت الفراغات بصمت، فقد أخرجت من الجواب أكثر من عُشر صفوفك دون أن تخبر أحدًا. صرّح بنسبة الفراغ صراحةً، وقرّر عن قصد: هل تأخذ الفراغات فئةً خاصة بها، أم تُستبعد مع تنبيه معلن، أم يتوقف التحليل حتى يُصلَح نظام المصدر.
• التكرارات تختبئ في صفوف تبدو معقولة. حفنة صفوف مكررة بالحرف — الحدث نفسه سُجّل مرتين بسبب إعادة محاولة، أو السجل نفسه صُدّر في دفعتين — تنفخ بهدوء كلَّ عدٍّ يُبنى على الملف. افحص التكرارات التامة وشبه التامة (المفتاح نفسه بطابع زمني مختلف) قبل أن تبلّغ أي إجمالي، لا بعد أن يسأل أحدهم لماذا يبدو الرقم مرتفعًا.

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

قاموس المؤشرات — تعريفات لا تنزلق

قاموس المؤشرات ليس مسردًا لعبارات حسنة الوقع؛ إنه الوثيقة التي تنهي الجدال قبل أن يبدأ، والانضباط الذي يجعله يعمل هو الدقة، لا الإجماع.

• منطق، لا انطباعات. «النشط هو العميل الذي استخدم المنتج مؤخرًا» ليس تعريفًا — إنه انطباع. أما «النشط: حساب له فعلٌ مدفوع واحد على الأقل خلال آخر 30 يومًا، يُحسب من جدول events مرشَّحًا على event_type IN (billable_list)» فتعريف: يقرؤه من لم يكلّمك قط فيعيد إنتاج رقمك دون سؤال واحد. التعريف الذي لا يستطيع غريبٌ تحويله إلى query دون الرجوع إليك ليس دقيقًا بعد.
• لكل مؤشر مالك واحد. لكل مؤشر مالك مسمّى واحد بالضبط — الشخص الذي يعتمد أي تغيير على تعريفه. بلا مالك، «يحسّن» محلّلٌ حسن النية تعريف الـ churn في منتصف الربع، فيكفّ رقم الشهر الماضي عن قابلية المقارنة برقم هذا الشهر — بصمت. المالك ليس حارس بوابة يحرس سرًّا؛ إنه المسؤول عن أن يعني المؤشر الشيء نفسه في كل مرة يُبلَّغ فيها.
• الحالات الحدّية هي حيث ينشب الخلاف فعلًا. لا أحد يختلف على أن العميل النشط بوضوح نشط. الخلاف دائمًا على الحافة: هل يُحسب من هو على تجربة مجانية؟ وهل يُعدّ الاشتراك الموقوف — غير الملغى — من الـ churn؟ وهل يبقى المبلغ المسترد ضمن إيراد شهره؟ دوّن كل حالة حدّية تخطر لك وكيف تُحسم — هذا هو القسم الذي يمنع الخلاف القادم فعلًا، لا التعريف الرئيسي.
• القاموس لا يطلب منك الاتفاق على الصواب — بل تدوين ما تقرّر. تتعطل قواميس الفرق انتظارًا للتعريف «الصحيح» للـ churn، ولا يوجد غالبًا تعريف صحيح واحد للجميع؛ يوجد قرار يتخذه فريقك مرة واحدة ويثبت عليه. اختر منطقًا تستطيع الدفاع عنه، وسمِّ مالكًا، واكتب الحالات الحدّية، وامضِ. التعريف الموثّق الذي فيه شيء من النقص يغلب الجدال غير الموثّق في كل مرة يُبلَّغ فيها الرقم.

الـ brief — من طلب غامض إلى سؤال قابل للإجابة

«هل يمكنك أن تنظر في موضوع الـ churn؟» ليس سؤالًا تبني عليه query. الـ brief هو العشرون دقيقة التي تحوّل الطلب الغامض إلى شيء يمكن الإجابة عنه فعلًا — والقفز فوقه هو أشيع سبب منفرد لإعادة عمل التحليل من أوله.

• القرار هو المواصفة الحقيقية، لا السؤال كما قيل. صاحب الطلب نادرًا ما يذكر القرار الذي يخدمه سؤاله — يذكر السؤال فقط. «كم نسبة الـ churn عندنا؟» قد يخدم تحديثًا لمجلس الإدارة، أو قرار أولويات لمسار إنقاذ العملاء، أو فضولًا خالصًا — وهذه القرارات الثلاثة تريد ثلاثة تحليلات مختلفة تمامًا: تحديث المجلس يريد اتجاهًا بسياقه؛ وقرار الأولويات يريد churn مفصّلًا بالشرائح ومقوَّمًا بالمال؛ والفضول يريد رقمًا واحدًا. اسأل «ماذا سيتقرر بهذا الجواب؟» قبل أن تبني شيئًا — إنه أعلى أسئلة الـ brief مردودًا.
• «خارج النطاق» أثمن سطر ستكتبه. الـ brief الذي يعدّد ما ستغطيه دون ما لن تغطيه يفتح باب الـ scope creep لحظة أن تشارك مسودة — «وما دمتَ هناك، هل يمكنك أن تفصّله أيضًا حسب…». تسمية ما هو مستبعد صراحة من هذه الجولة، ولماذا، تعطي صاحب الطلب موضعًا نظيفًا للاعتراض قبل أن تبني شيئًا، لا بعده.
• ترجِم الطلب — لا تنقله كما هو. صاحب الطلب يكتب بمفرداته هو، وهي فضفاضة عن قصد في الغالب؛ ومهمتك أن تحوّلها إلى مؤشرات قاموسك ومصادره، لا أن تنسخ كلماته داخل query. «انظر في موضوع الـ churn» تصير «معدل الـ logo churn الشهري، كما هو معرّف في metrics.md، مفصّلًا حسب فئة الخطة والدولة، عن الربعين الأخيرين». وإن غيّرت الترجمةُ معنى ما طُلب، فليس ذلك تجاوزًا — بل هو الـ brief يؤدي عمله.

المعيار العربي — ما الذي يتطلبه عرض نتائج ثنائي اللغة فعلًا

لفريق يرفع تقاريره إلى قيادة ثنائية اللغة، ليست هذه خطوة ترجمة تُجرى على الشريحة الجاهزة؛ إنها معيار يثبّته الـ brief من البداية، لأن العطب هنا محدد بدقة: عرضٌ إنجليزي وعرضٌ عربي يستشهدان — من حيث لا يدري أحد — برقمين مختلفين، لأنهما بُنيا في جولتين منفصلتين في وقتين مختلفين.

• اكتب السرد العربي من البداية؛ لا تترجم السرد الإنجليزي. العرض العربي الذي كُتب بالإنجليزية ثم مُرّر على الترجمة يحمل بنية الجملة الإنجليزية ويُقرأ كتقرير مستورد. اكتب السرد العربي من الأرقام المطابَقة نفسها، بالسجلّ الذي تقرؤه قيادة خليجية فعلًا — مباشر، الأرقام في الصدارة، بلا حشو — تمامًا كما تكتب النسخة الإنجليزية من الصفر.
• الأرقام تبقى غربية؛ العربية للسرد وحده. يبقى 474,800 هو 474,800 في العرض العربي — لا يُحوَّل أبدًا إلى الأرقام الهندية — وتبقى العملة AED. هذا عُرف مستقر لا مسألة ذوق، وقلبُه هو أوضح علامة منفردة على أن العرض تُرجم آليًا ولم يُكتب.
• اللغتان تستشهدان بملحق واحد مُطابَق — لا اثنين أبدًا. الانضباط الذي يمنع الإنجليزية والعربية من الافتراق في رقم انضباطٌ بنيوي: ابنِ ملحق أرقام واحدًا مطابَقًا، واجعل السردين يحيلان إليه بدل أن يحمل كلٌّ منهما نسخته من الإجماليات. إن تغيّر رقم، تغيّر مرة واحدة، في موضع واحد، وتحدّثت اللغتان معًا.

تكليفك

ابنِ وثائق الأساس الثلاث لـمجموعة بيانات واحدة وطلب حقيقي واحد — بياناتك أنت (وهذا ما ننصح به: الناتج بنية تحتية يستعلم منها فريقك كله)، أو العلامة النموذجية «ميزان»، أداة مسك دفاتر SaaS للمنشآت الصغيرة في الخليج، التي ترافقك محلّلة أعمالها مايا حدّاد في المسار كله. افتح مجلدًا يضم ملف التصدير الخام في Claude Desktop، ووافق على كل قراءة من نافذة Ask permissions، واعمل داخل المحادثة — لا حاجة إلى terminal إطلاقًا.

ناتج الوحدة الأولى — أساس البيانات

1. dataset-profile.md  (صفحة واحدة، عن ملف حقيقي واحد)
   - عدد صفوف متحقَّق منه (وكيف فُحص مقابل مصدر ثانٍ)
   - كل عمود مشروح بلغة واضحة، مفحوصًا على عيّنة من قيمه —
     لا مفترضًا من عنوانه
   - نطاق التواريخ الحقيقي وكيف تأكّدتَ منه
   - نسبة الفراغ لكل عمود فيه أي فراغ
   - فحص التكرارات: عدد التامة وشبه التامة
   - «عمود يكذب» واحد على الأقل مضبوطًا — إن كان في الملف واحد

2. metrics.md  (صفحة واحدة، 4–6 مؤشرات يبلّغ عنها فريقك فعلًا)
   - لكل مؤشر: معناه بلغة واضحة، ومنطقه الدقيق (ترشيح/معادلة
     بدقة تكفي لتحويله إلى query دون سؤال لاحق)
   - مالك مسمّى لكل مؤشر
   - 2–3 حالات حدّية لكل مؤشر، وكيف تُحسم كل منها

3. analysis-brief.md  (صفحة واحدة، عن طلب حقيقي واحد)
   - القرار الذي سيخدمه الجواب — لا السؤال كما قيل فحسب
   - السؤال الدقيق، مترجمًا إلى مفردات metrics.md
   - المصادر والشرائح بالضبط
   - ما هو خارج نطاق هذه الجولة صراحةً، ولماذا

للفرق الثنائية اللغة: دوّن أين سيحتاج عرضُ نتائج هذا الـ brief إلى
سرد عربي يستشهد بالملحق المطابَق نفسه الذي تستشهد به الإنجليزية.

وحقيبة أدوات الأساس تعطيك قالبًا جاهزًا للتعبئة لكل وثيقة من هذه، مع الـ prompts التي تبنيها — فتبدأ من هيكل قائم، لا من ملف فارغ.

كيف يجري التقييم — المعايير

هذا ما لا يملكه الـ playbook المجاني، وهو ما يعطي الاعتماد وزنه. تُقيَّم ملفّاتك الثلاثة وفق خمسة معايير، درجة كل معيار مستوفٍ / قريب / ليس بعد — و«قريب» في أي معيار يعني إعادة التسليم، لا النجاح.

معايير تقييم الأساس

1. التوصيف صادق ومكتمل
   عدد الصفوف متحقَّق منه مقابل مصدر ثانٍ، لا مذكور فحسب. كل عمود
   مشروح من قيمه الفعلية لا من عنوانه. نسبة الفراغ وعدد التكرارات
   مذكوران معًا.
2. المؤشرات منطق، لا انطباعات
   كل تعريف دقيق إلى حدّ أن يحوّله غريبٌ إلى query دون سؤال لاحق.
   ولكل مؤشر مالك مسمّى.
3. الحالات الحدّية مدوّنة
   حالتان حقيقيتان على الأقل لكل مؤشر، لكل منهما حسم معلن —
   لا «حسب التقدير».
4. الـ brief قابل للإجابة فعلًا
   القرار الذي يخدمه مسمًّى. السؤال مترجم إلى مفردات metrics.md.
   النطاق صريح، وفيه بند واحد على الأقل معلَن خارج النطاق.
5. معيار العرض الثنائي اللغة سليم
   (للفرق الثنائية اللغة) اللغتان تستشهدان بملحق واحد مطابَق.
   الأرقام غربية؛ والسرد العربي مكتوب من البداية لا مترجم عن
   المسودة الإنجليزية.

هذه الصرامة مقصودة، وهي عين ما يطلبه رئيس تحليلات متشكك: التوصيف السطحي، والمؤشر المبهم، والـ brief الذي بقي غامضًا بعد كتابته — كلها تفشل بصمت في كل تحليل يُبنى فوقها، فلا بد أن تُضبط هنا، قبل أن تتسرّب.

المستوى المطلوب، معروضًا — نموذج إجابة (ميزان)

لن نتركك تخمّن كيف يبدو «المستوفي». هذه مقتطفات ناجحة للعلامة النموذجية — والمطلوب من ملفاتك ليس أن تشبهها، بل أن تبلغ المستوى نفسه. هذه وثائق مايا حدّاد، محلّلة الأعمال في «ميزان»، من الأسبوع الذي طلبت فيه الإدارة قراءةً للـ churn.

dataset-profile.md — signups.csv (مقتطف)

عدد الصفوف: 8,432 صفًّا.
التحقق: ملخص التصدير في أداة التسويق نفسها يعرض 8,432 تسجيلًا
للفترة ذاتها — العددان متطابقان.

الأعمدة (فُحص كل عمود على 30 قيمة معيّنة، لا افتراضًا من العنوان):
  signup_date  تاريخ إرسال نموذج التسجيل التجريبي. تأكدنا أنه طابع
               إنشاء لا تاريخ تفعيل — 6% من الصفوف لها signup_date
               دون إنشاء حساب مقابل، أي أن النموذج أُرسل ولم يُجهَّز
               الحساب قط. يُنقل هذا إلى الـ brief: «التسجيلات» في
               هذا الملف تعني إرسالات نموذج، لا حسابات تجريبية
               مُجهَّزة.
  source       إسناد قناة التسويق. فارغ في 12% من الصفوف — تسجيلات
               بلا وسم UTM، معظمها زيارات مباشرة بحسب فحص يدوي
               لعشرين صفًّا فارغًا. لا تُسقطها من تفصيلات القنوات؛
               اجعلها فئة «غير موسومة».
  country      رمز الدولة ISO. لا فراغات. 84% الإمارات/السعودية/
               قطر/الكويت — متسق مع قاعدة عملاء خليجية.
  plan         العمود الذي يكذب: يسجّل فئة الخطة التي طُلبت عند
               التسجيل، لا الخطة الحالية لمن حوّل اشتراكه. 340 صفًّا
               تُظهر طلب تجربة "Pro" لحسابات هي اليوم على "Starter" —
               خفّضوا خطتهم بعد التجربة. لا تستخدم هذا العمود
               لتقارير الخطة الحالية؛ اربط بجدول الاشتراكات بدلًا منه.

نطاق التواريخ: من 2026-03-01 إلى 2026-03-13. مؤكَّد مقابل مرشِّح
التصدير الذي سُحب به الملف (احتفظنا بلقطة شاشة لمحدد التاريخ).

التكرارات: 3 صفوف مكررة بالحرف (signup_date + بصمة البريد + source
نفسها)، متسقة مع خلل إرسال مزدوج معروف في نموذج التجربة. حُذفت
قبل تبليغ أي عدّ. ولا شبه تكرارات سوى هذه الثلاثة.

metrics.md — ميزان (مقتطف: 3 من 5)

ACTIVE CUSTOMERS — العملاء النشطون
  المعنى:  حساب مدفوع باشتراك سارٍ.
  المنطق:  COUNT(DISTINCT account_id) FROM subscriptions
           WHERE status = 'active' AND plan != 'trial'
  المالكة: مايا حدّاد (محلّلة الأعمال)
  حالات حدّية:
    - الاشتراك الموقوف (غير الملغى): يُستبعد من عدّ النشطين،
      ويدخل في عدّ «المعرَّضين للخطر». الإيقاف إشارة churn،
      لا حدث عابر.
    - الحساب في منتصف تخفيض خطة (القديمة تنتهي والجديدة تبدأ
      في اليوم نفسه): يُحسب مرة واحدة، على الخطة الجديدة،
      لا مرتين على الاثنتين.

MONTHLY LOGO CHURN — الـ churn الشهري بعدد العملاء
  المعنى:  حصة العملاء النشطين في أول الشهر الذين ألغوا قبل آخره.
           churn بعدد الحسابات لا بالإيراد — الحساب الملغى بقيمة
           AED 49 شهريًا والملغى بقيمة AED 249 يُحسبان سواء.
  المنطق:  cancelled_this_month / active_at_month_start
  المالكة: نادية السيّد (رئيسة عمليات العملاء)
  حالات حدّية:
    - عميل يلغي ويعيد الاشتراك في الشهر نفسه: يُحسب churn.
      العودة لاحقًا لا تمحو الإلغاء بأثر رجعي.
    - الـ churn غير الطوعي (فشل دفع بلا نجاح بعد 3 محاولات):
      يدخل في الـ churn موسومًا على حدة «churn دفع» — علاجه
      مختلف (dunning) عن علاج الـ churn الطوعي (منتج/نجاح عملاء).

MRR (الإيراد الشهري المتكرر)
  المعنى:  إيراد الاشتراكات الشهري المعدَّل عبر كل الحسابات
           النشطة، كما هو في آخر يوم من الشهر.
  المنطق:  SUM(plan_price / billing_interval_months) WHERE status='active'
  المالك:  المالية (يُطابَق شهريًا مع إقفال دفتر الأستاذ العام)
  حالات حدّية:
    - الخطط السنوية: تُقسم على 12، ولا تُحسب دفعة واحدة في شهر
      فوترتها — هذا ما يجعل MRR قابلًا للمقارنة شهرًا بشهر.
    - تغيير الخطة في منتصف الشهر: يُحسب المبلغ بنسبة الأيام،
      لا بسعر الخطة الجديدة كاملًا، كي لا يتضخم شهر التغيير.

analysis-brief.md — «هل يمكن أن تبنوا لنا لوحة متابعة للـ churn؟» (نادية السيّد)

الطلب الأصلي (نصًّا، من Slack):
  «مرحبًا — هل يستطيع أحد أن يبني لنا لوحة متابعة للـ churn؟
   أريد أن أبقى مطّلعة على الوضع مع دخولنا الربع الثاني.»

القرار الذي يخدمه: هل تُطلق عملياتُ العملاء مسارَ إنقاذ (تواصلًا
  استباقيًا مع الحسابات المعرَّضة) في الربع الثاني، وأي شريحة
  يستهدفها أولًا. ليس مؤشر مجلس إدارة — قرار أولويات تشغيلي.

السؤال الدقيق: ما الـ logo churn الشهري (وفق metrics.md)، اتجاهًا
  عبر الربعين الأخيرين، مفصّلًا حسب فئة الخطة والدولة — وأي شريحة
  تجمع بين أعلى معدل churn وحجمٍ يكفي لتبرير مسار إنقاذ مخصص؟

المصادر: جدول subscriptions‏ (status, plan, cancelled_at)، وجدول
  customers‏ (country) — مربوطان على account_id.

الشرائح: فئة الخطة (Starter / Pro / Business)، والدولة (الإمارات /
  السعودية / قطر / الكويت / غيرها).

خارج نطاق هذه الجولة:
  - churn الإيراد وصافي بقاء الإيراد — هذه الجولة logo churn فقط.
    (churn الإيراد هو التتمة الطبيعية في الوحدة الثانية بعد
    تسليم هذا.)
  - لوحة حيّة تتحدّث ذاتيًا — النسخة الأولى عرض شهري ثابت.
    اللوحة الحقيقية من نواتج الوحدة الخامسة (منظومة التقارير).
  - تعليل *لماذا* تتسرب أي شريحة — هذا الـ brief يجيب «أين ننظر»
    لا «لماذا»؛ ذاك تحليل سبب جذري مستقل بعد أن نعرف الشريحة.

أكّدت مايا هذا النطاق مع نادية قبل أن تبني شيئًا — وسطرُ «لا سبب
جذري، ولا churn إيراد، ولا لوحة حيّة» هو ما جعل هذا العمل brief
يومين بدل مشروع لوحة يستغرق أسبوعين.

ما الذي أثبتّه — وما التالي

باجتيازك هذه المعايير تكون قد أنجزت ما لا يستطيع المسار المجاني أن يشهد لك به: بنيت أساس بيانات حقيقيًا بمستوى احترافي، وأظهرت الحسّ المهني الذي وراءه. هذه هي مرحلة الأساس من اعتماد «البيانات والتحليل مع Claude».

من هنا يمضي المسار في تحويل الأساس إلى منظومة تحليلات قائمة، وكل وحدة تُقيَّم بالطريقة نفسها:

• الوحدة 2 — محرّك الاستعلام والدمج: كتابة queries يستطيع غريبٌ مراجعتها، وتحويل ملفّين فوضويين إلى مجموعة بيانات واحدة تصلح فعلًا لبناء تقرير.
• الوحدة 3 — الجودة والسبب الجذري: تدقيق مجموعة بيانات قبل أن تُغذّي ما له وزن، ومعرفة سبب تحرّك رقم دون تخمين.
• الوحدة 4 — التجارب والرسوم البيانية: قراءة اختبار A/B بصدق تحت ضغط الإطلاق، وتحويل ملف CSV إلى رسم يصمد أمام نظرة ثانية.
• الوحدة 5 — منظومة التقارير: بناء التقرير الدوري الذي يخرج بالطريقة نفسها كل شهر، ثم المشروع الختامي — «الرؤية الجاهزة» (Insight-in-a-Box)، التحقيق الكامل من ملف التصدير الخام إلى الشهادة.

لكن قبل ذلك، اجعل ما بنيته قابلًا لإعادة الاستخدام: خذ حقيبة أدوات الأساس — ملف CLAUDE.md الخاص بالبيانات والقوالب الثلاثة التي تحوّل الوثائق التي كتبتها للتوّ إلى ملفات يستعلم منها فريقك كله من اليوم الأول. وإن كنت تنشر هذا على مستوى فريق، فـدليل التشغيل هو طبقة أمان البيانات والتحقق التي يقوم عليها كل ما سبق.