EN
تعلّم المسارات المرجع مقالات المحفوظات
playbook

ابنِ قاموس المقاييس الذي يرثه كل query وكل تقرير

حوّل المقاييس التي يتجادل فيها فريقك — active وchurn والإيرادات — إلى قاموس واحد: لكلٍّ منها معنى واضح بلغة بسيطة، والمنطق الدقيق الذي يحسبه، ومالكٌ مسؤول عنه، وحالاته الحدّية، حتى يَعُدّ كل query وكل chart وكل تقرير الشيء نفسه أخيرًا.

متوسّط ~1.5 ساعة للبناء، يُعاد استخدامه في كل تحليل
متى تلجأ إلى هذا

كل فريق بيانات يعاني الإخفاق الصامت نفسه: محلّلان يسحبان عدد 'active users' فيحصلان على رقمين مختلفين، وكلاهما محقّ — لأن لا أحد كتب ما الذي يعنيه 'active'. على مستوى المؤسسة هذا ليس طُرفة، بل تسريبٌ للمصداقية: عرض مجلس الإدارة ولوحة العمليات يتناقضان، فيقضي الفريق اجتماعاته في التوفيق بين التعريفات بدل اكتشاف الرؤى. الحل قاموس مقاييس — ملف metrics.md يحمل مدخلًا واحدًا معتمدًا لكل مقياس: المعنى الواضح بلغة بسيطة، والمنطق الدقيق، ومن يملكه، والحالات الحدّية. ابنِه مرة واحدة فيزداد كل Data playbook آخر حدّةً، لأن 'أرقامنا' تشير أخيرًا إلى مستند واحد. هذا هو ما الذي نَعُدّه؛ أما الـ playbooks الأخرى فهي كيف نَعُدّه.

جهّز هذا أولًا
  • المقاييس التي تُبلّغ عنها فعلًا — اسحب لوحة تحكّم حديثة أو عرض مجلس إدارة أو تحديثًا أسبوعيًا واسرد كل رقم فيه. حتى المتنازَع عليها (بل المتنازَع عليها قبل غيرها).
  • الـ queries أو جداول البيانات وراء بعضها، حتى يستطيع Claude أن يقرأ ما الذي يحسبه الرقم حاليًا، لا ما يقول الناس إنه يعنيه فحسب.
  • مَن سيكون مسؤولًا عن كل رقم لو شكّك فيه أحد نوّاب الرئيس — وأي خلافات قائمة ('لا نتفق أبدًا على churn') حتى تُحسَم على الصفحة، لا في الاجتماع القادم.
الـ workflow
  1. اجرُد المقاييس التي تُبلّغ عنها — وأظهِر التضاربات

    افتح المجلد الذي يحوي مخرجات لوحة التحكّم والـ queries وراءها في Claude Desktop، واسأل في المحادثة — دون الحاجة إلى Terminal. قبل أن تعرّف أي شيء، احصل على القائمة الكاملة والتقط المقياس نفسه حين يُعرَّف بطريقتين. المكرّرات هي السبب الكامل لوجودك هنا.

    أنت تطلب
    إليك لوحة تحكّم حديثة والـ queries وراءها. اسرد كل مقياس متمايز نُبلّغ عنه. ولكلٍّ منها، أخبرني بما يبدو أنه يقيسه من الـ query، ونبّهني على أي حالة يُحسَب فيها الاسم نفسه بطريقتين مختلفتين، أو يعني فيها اسمان الشيء نفسه بوضوح. لا تكتب تعريفات بعد — أعطني الجرد والتضاربات فقط.

    ما تحصل عليه جردٌ نظيف إضافةً إلى قائمة تضاربات: «'active users' هو COUNT(DISTINCT user_id) في query الإدارة التنفيذية لكنه يَعُدّ sessions في query العمليات؛ 'الإيرادات' تشمل المردودات في موضع وتستثنيها في آخر». التضاربات هي المقاييس التي تُحسَم أولًا.

    قاوِم رغبة التعريف أثناء التقدّم. رؤية القائمة كاملة أولًا — وأين تناقض نفسها — هي ما يمنع القاموس من تكريس التضارب نفسه الذي يُفترض أن يُصلحه.

  2. عرّف كل مقياس — المعنى الواضح والمنطق الدقيق

    لكل مقياس، اكتب شيئين: الجملة التي يفهمها مَن ليس محلّلًا، والمنطق الدقيق الذي يحسبه. كلاهما مهم — الجملة تُبقي الفريق صادقًا، والمنطق يجعله قابلًا لإعادة الإنتاج.

    أنت تطلب
    لكل مقياس في الجرد، صُغ مدخل قاموس يحوي: تعريفًا واضحًا من جملة واحدة بلغة بسيطة يقرأه أي أحد؛ والحساب الدقيق (الـ columns والـ filter والتجميع — مثلًا المستخدمون المتمايزون الذين لديهم حدث login واحد على الأقل خلال الشهر التقويمي)؛ والمستوى الذي يُحسَب عنده (لكل مستخدم، لكل حساب، لكل يوم). وحيثما تعارَض تعريفان، اقترح التعريف الذي توحّد عليه واشرح السبب.

    ما تحصل عليه مسوّدة أولى لمدخلٍ لكل مقياس — معنى واضح، ومنطق دقيق، ومستوى الحساب — مع حلٍّ مقترح لكل تضارب. صار لديك الآن شيء ملموس تصادق عليه بدل جدالٍ تظل تخوضه.

  3. ثبّت الحالات الحدّية التي تغيّر الرقم بهدوء

    معظم النزاعات حول المقاييس ليست على العنوان الرئيسي — بل على الأطراف التي لم يحدّدها أحد. المنطقة الزمنية، وإزالة التكرار، وما يُستثنى، وكيف تُعامَل القيم الفارغة. أجبِر كلًّا منها على الظهور على الصفحة.

    أنت تطلب
    لكل مقياس، اجعل القرارات الصامتة صريحة: أي منطقة زمنية تحدّد حدّ اليوم/الشهر؛ وهل نزيل التكرار وعلى أي مفتاح؛ وما يُستثنى (الحسابات الاختبارية، المستخدمون الداخليون، المردودات، الطلبات بقيمة $0)؛ وكيف تُعامَل القيم الفارغة والبيانات المتأخّرة الوصول. اسرد أي حالة حدّية اضطُررت فيها إلى تخمين نيّتنا، حتى أقرّرها أنا بدلًا منك.

    ما تحصل عليه كتلة حالات حدّية تحت كل مقياس — «الشهر = الشهر التقويمي بتوقيت UTC؛ يستثني النطاقات الداخلية وtest_account=true؛ المردودات تُخصَم صافيةً في الإيرادات؛ صفوف plan الفارغة مُستثناة وتُحسَب على حدة» — وقائمة قصيرة من القرارات المُنبَّه عليها لتتخذها أنت، الإنسان.

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

  4. عيّن مالكًا ومصدر حقيقة لكل مقياس

    التعريف بلا مالك ينحرف عائدًا إلى الفوضى خلال ربعٍ واحد. سمِّ شخصًا يستطيع أن يكون مسؤولًا عن كل مقياس، والنظام الذي يمثّل مصدر حقيقته، حتى تمرّ التغييرات عبر شخص، لا بالصدفة.

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

    ما تحصل عليه كل مدخل يحمل الآن مالكًا ومصدر حقيقة، مع التنبيه على المقاييس اليتيمة أو ثنائية المصدر — ثغرات الحوكمة مُسمّاة لتُسنَد، لا تُترَك للانحراف.

  5. اجمع ملف metrics.md من صفحة واحدة الذي يستشهد به كل مخرَج

    اجمعه في ملف واحد معتمد، مرتّب وسهل التصفّح. أبقِه مُحكمًا — القاموس الذي لا يستطيع أحد أن يحتفظ به في ذهنه لا يُستشهَد به. هذا الملف هو ما يشير إليه كل تعليق query وكل تسمية chart وكل تقرير.

    أنت تطلب
    اجمع كل شيء في ملف metrics.md واحد: مقدّمة قصيرة عن كيفية استخدامه، ثم مدخل واحد لكل مقياس يحوي التعريف الواضح، والمنطق الدقيق، ومستوى الحساب، والحالات الحدّية، والمالك، ومصدر الحقيقة. أضِف في الأعلى اصطلاح changelog من سطر واحد (التاريخ، المقياس، ما الذي تغيّر، من اعتمده). أبقِ كل مدخل في بضعة أسطر حتى يبقى الكل قابلًا للتصفّح السريع.

    ما تحصل عليه ملف metrics.md واحد جاهز للّصق — مصدر الحقيقة الذي يرثه كل query وكل chart وكل تقرير، مع changelog حتى لا يتغيّر التعريف إلا عن قصد ومُوثَّقًا.

    احفظ هذا الملف في جذر مجلد التحليل. من الآن فصاعدًا، سؤال 'كيف تعرّف active؟' في كل Data playbook آخر له إجابة واحدة: أشِر إلى metrics.md.

اجعله ملكك
  • سلّمه لكل query: تنزل كتلة المنطق من القاموس مباشرةً إلى اكتب الـ query وتعلّم الـ SQL — الصق التعريف فيها كتعليق على الـ query حتى يصير الرقم قابلًا لإعادة الإنتاج بيد شخص لم يكن في الغرفة (انظر playbooks الأنظمة).
  • أسماء مقاييس ثنائية اللغة: إن كنت تُبلّغ بالعربية والإنجليزية، أضِف الاسم العربي وتعريفًا من سطر واحد بجانب كل مقياس حتى يقرأ مجلس الإدارة ثنائي اللغة المعنى نفسه بأي لغة — اكتب التعريف العربي بالعربية، لا تترجم الإنجليزي كلمةً بكلمة.
  • اجعله skill (Power Track): حمّل metrics.md كـ skill قابل لإعادة الاستخدام أو كـ /define command (انظر تبويب Features) حتى يُراجَع كل تحليل تلقائيًا مقابل التعريفات المتّفق عليها، لا من الذاكرة.
  • حدّثه عند التغيير الحقيقي فقط: أعِد تشغيل هذا حين يتغيّر مقياس فعلًا — استثناء جديد، أو إعادة تعريف — وحدّث الـ changelog. التعريف الذي يتقادم بصمت أسوأ من عدم وجوده، لأن الجميع لا يزال يثق به.
انتبه إلى
  • التعريف بلا مالك ينحرف. القيمة كلها مصدر حقيقة واحد؛ إن استطاع الجميع تعديله، فخلال ربعٍ واحد تعود إلى ثلاثة أرقام لـ 'active'. مالك واحد لكل مقياس، والتغييرات تُراجَع وتُوثَّق — عامِل الملف كالمستند المضبوط الذي هو عليه، لا كـ wiki يحقّ لأي أحد أن 'يحسّنه' بهدوء.
  • «يبدو معقولًا» ليس «مُتّفقًا عليه». يستطيع Claude أن يصوغ تعريفًا، لكن على الفريق أن يصادق عليه — خاصةً حلول التضاربات. القاموس غير المتنازَع عليه لأنه غير مقروء هو خلافٌ ينتظر أن يطفو من جديد أمام أحد أصحاب المصلحة.
  • القاموس يحكم المعنى، لا الصحّة. يجعل الجميع يَعُدّون الشيء نفسه؛ لكنه لا يضمن أن البيانات الأساسية صحيحة — ما زلت تطابق كل نتيجة مقابل إجمالي معروف. المتّسق والخاطئ يظل خاطئًا.
  • ثبّت الأطراف وإلا تسرّب القاموس. سيتفق محلّلان على 'active users' ويظلّان يحصلان على رقمين مختلفين إن أسقط أحدهما الحسابات الاختبارية ولم يسقطها الآخر. كتلة المنطقة الزمنية/إزالة التكرار/الاستثناء هي ما يجعل التعريف قابلًا لإعادة الإنتاج فعلًا.

ستحصل في النهاية على ملف `metrics.md` من صفحة واحدة — كل مقياس مُبلَّغ عنه بمعنى واضح، ومنطق دقيق، وحالات حدّية، ومالك، ومصدر حقيقة — يرثه كل query وكل chart وكل تقرير، حتى تتفق المؤسسة كلها أخيرًا على ما تعنيه أرقامها وتتوقّف عن التوفيق بين التعريفات في الاجتماعات.

أسئلة يطرحها الناس

ما الفرق بين قاموس المقاييس وكتابة queries جيدة فحسب؟
الـ query يحسب رقمًا؛ أما قاموس المقاييس فيقرّر ما الذي *يُفترض* أن يعنيه الرقم قبل أن يكتب أحد أي query. بدونه، يمكن لـ queryين صحيحين أن يُرجعا رقمَي 'active users' مختلفين لأنهما يرمّزان تعريفين غير مذكورين. القاموس هو التعريف المتّفق عليه الذي يستشهد به كل query بعدئذ — وهو ما يجعل الأرقام قابلة لإعادة الإنتاج وللمقارنة عبر الأشخاص والأشهر، لا قابلة للتشغيل فحسب.
مَن ينبغي أن يملك قاموس المقاييس؟
مالك واحد لكل مقياس — عادةً المحلّل أو قائد التحليلات الأقرب إليه — إضافةً إلى مالك واحد شامل للملف. القيمة كلها أنه مصدر حقيقة واحد؛ إن استطاع الجميع تعديله بحرّية، انحرف عائدًا إلى التضارب الذي كان يُفترض أن يُصلحه. عامِل تغيير التعريف كتحديث مُراجَع ومُوثَّق له مُعتمِد، لا فوضى مفتوحة للجميع، وأعِد تشغيل الـ playbook فقط حين يتغيّر مقياس فعلًا.
ما الذي أحتاجه قبل أن أبدأ؟
لوحة تحكّم حديثة أو عرض مجلس إدارة أو تقرير أسبوعي حتى تسرد كل مقياس تنشره فعلًا، إضافةً إلى الـ queries أو جداول البيانات وراء بعضها حتى يستطيع Claude أن يقرأ ما الذي يحسبه كل رقم حاليًا. أحضِر أي خلافات قائمة أيضًا — 'لا نتفق أبدًا على churn' هو بالضبط نوع التضارب الذي بُني هذا الـ playbook ليحسمه على الصفحة.
هل يضمن القاموس أن أرقامنا صحيحة؟
لا — يضمن أنها *متّسقة*، وهذا أمر مختلف. القاموس يجعل الجميع يَعُدّون الشيء نفسه بالطريقة نفسها؛ لكنه لا يشهد بأن البيانات الأساسية نظيفة أو أن المنطق خالٍ من الأخطاء. ما زلت تطابق كل نتيجة مقابل إجمالي معروف وتدقّق بيانات المصدر. المتّسق والخاطئ يظل خاطئًا؛ القاموس يزيل فقط الإخفاق الثاني القابل للتجنّب: المتّسق والمتنازَع عليه.