كيفية تحويل بيانات استخدام المنتج إلى تقرير تبني الميزات (2026)

إن تصدير بيانات الاستخدام عبارة عن قائمة طويلة من الأحداث: معرف المستخدم، واسم الحدث، والطابع الزمني، وربما خاصية أو اثنتين. أما تقرير اعتماد الميزات فهو عبارة عن نسبة مئوية واحدة. والمسافة بينهما تكمن في ثلاثة قرارات، وليست مجرد معادلة حسابية.

من هم المستخدمون الذين ينتمون إلى المقام. ما الذي يُعتبر استخداماً للميزة. وما هو الإطار الزمني الذي تقيس خلاله.

غيّر أيًا من هذه القرارات وستتغير النسبة بمقدار عشرات النقاط المئوية. ومع ذلك، سيظل التقرير يبدو صحيحاً، وهذه هي المشكلة بعينها.

يغطي هذا الدليل ما يجب تحديده أولاً، والطرق اليدوية الثلاث، ومواطن الخلل في كل منها.

ما تحتاجه قبل البدء

أنت بحاجة إلى صفوف على مستوى الحدث، وليس ملخصاً مجمعاً مسبقاً. صف واحد لكل حدث، يحتوي على معرف المستخدم والطابع الزمني.

تحتاج إلى اسم الحدث الذي يمثل الميزة فعلياً. نادراً ما يكون هذا الأمر بسيطاً كما يبدو، لأن معظم الميزات تطلق عدة أحداث. ولا يمكن لنسبة اعتماد الميزة أن تكون دقيقة إلا بقدر دقة هذا الربط.

تحتاج أيضاً إلى معرفة من كان بإمكانه استخدامها. إذا تم إطلاق الميزة خلف علامة (flag) لمجهة فرعية من الحسابات، فإن بقية المستخدمين لا ينتمون إلى المقام.

إجراء فحص سريع للسلامة يوفر عليك ساعة من العمل لاحقاً. احسب عدد المستخدمين الفريدين في البيانات المصدرة وقارنه بعدد المستخدمين النشطين المعروف لديك. إذا كان هناك اختلاف كبير، فهذا يعني أن البيانات المصدرة قد تمت تصفيتها بطريقة لم تلاحظها.

القرارات الثلاثة التي تغير النسبة

المقام. جميع المستخدمين المسجلين، أو المستخدمون النشطون شهرياً، أو فقط المستخدمون المؤهلون لاستخدام الميزة. تنتج هذه الخيارات ثلاث نسب مئوية مختلفة من نفس الأحداث. كل رقم لاعتماد الميزات هو عبارة عن كسر، لذا حدد كلا النصفين قبل حساب أي شيء.

عادةً ما يكون اختيار "المؤهلين" هو الخيار الأكثر مصداقية للميزات التي تم إطلاقها حديثاً. أما "جميع المستخدمين المسجلين" فهو الرقم الذي يبدو الأسوأ ولكنه الأسهل للدفاع عنه كتقدير متحفظ.

ما يعنيه "الاستخدام". إطلاق الحدث مرة واحدة، أو مرتين، أو في جلستين منفصلتين. نقرة واحدة أثناء جولة تعريفية لا تعني اعتماد الميزة، ومعظم الفرق تتعلم هذا الدرس بالطريقة الصعبة.

اختر حداً أدنى واكتبه في التقرير. يُعد الاستخدام مرتين في يومين مختلفين قاعدة شائعة ومنطقية.

الإطار الزمني. الاعتماد ليس نقطة زمنية محددة. بل هو نسبة المستخدمين المؤهلين الذين قاموا بالإجراء خلال فترة معينة، وبالتالي فإن هذه الفترة هي جزء من التعريف.

إليك تفصيلاً دقيقاً وموثقاً يجدر بك معرفته قبل نسخ منهجية أي أداة. توضح وثائق الاحتفاظ الخاصة بـ Amplitude كيفية عمل حساباتها. فهي "تحسب بيانات الاحتفاظ بمقارنة تاريخ ذلك الحدث البدائي بتاريخ حدث العودة الذي حددته".

ينطبق النطاق الزمني على الحدث الأول فقط. وتذكر Amplitude بوضوح أنه "ليس على المستخدمين تفعيل حدث العودة خلال تلك الفترة للظهور في التحليل".

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

كيفية القيام بذلك يدوياً

الخيار 1: حساب عدد المستخدمين الفريدين، ثم القسمة

ابدأ بإزالة التكرار، لأن الأعداد الخام للأحداث لا تمثل المعتمدين الفعليين للميزة. استخرج قائمة المستخدمين الفريدين باستخدام الدالة UNIQUE.

ثم احسب عدد هؤلاء المستخدمين الذين أطلقوا حدث الميزة، باستخدام الدالة COUNTIFS مع اسم الحدث ونطاق التاريخ. ثم اقسم الناتج على عدد المستخدمين المؤهلين لديك.

احتفظ بالعددين في خلايا مرئية بدلاً من دمجهما في صيغة واحدة. سيسألك أحدهم يوماً ما عن المقام، وستحتاج إلى الإشارة إليه مباشرة.

العيب الأساسي هنا هو أن هذا يمنحك رقماً واحداً مجرداً. ستعرف أن 18% قد اعتمدوا الميزة، دون معرفة أي تفاصيل عن هويتهم.

الخيار 2: بناء جدول مؤشرات على مستوى المستخدم

صف واحد لكل مستخدم مؤهل، وعمود واحد لكل سؤال. هل أطلقوا الحدث، وكم عدد المرات، وفي كم يوماً فريداً.

الآن يمكنك تقسيم البيانات. الاعتماد حسب الخطة، أو حسب مجموعة التسجيل (cohort)، أو حسب حجم الحساب، أو حسب ما إذا كانوا قد أكملوا مرحلة التهيئة والتدريب.

هنا يصبح اعتماد الميزة قابلاً للتطبيق الفعلي وليس مجرد رقم للتقرير. فالنسبة الإجمالية البالغة 18% تخفي حقيقة أن المستخدمين الجدد يمثلون 40% بينما مستخدمو العام الماضي يمثلون 4%.

هذه الفجوة هي النتيجة الأهم. يغطي دليلنا حول تحليل المجموعات المشتركة (cohort analysis) سبب تغير الرقم الإجمالي كلما تغير حجم التسجيل، حتى لو لم يتغير السلوك.

العائق هنا هو حجم البيانات وعمليات الربط (joins). فتصدير مليون صف بالإضافة إلى جدول الحسابات يتجاوز الحد الذي تظل فيه الصيغ البرمجية سهلة ومريحة.

الخيار 3: الاحتفاظ بتبويب للتعريفات بجانب الأرقام

دوّن اسم الحدث، والحد الأدنى، والإطار الزمني، والمقام، ومن كان مؤهلاً.

هذا ما يجعل التقرير قابلاً للمقارنة في الشهر التالي. وهو أيضاً التبويب الذي يتم تجاهله عندما يحتاج شخص ما إلى الرقم في غضون عشر دقائق.

العيب هنا هو أن توثيق التعريف لا يعني تطبيقه تلقائياً. سيظل هناك من يعيد بناء الفلاتر الخمسة نفسها في كل دورة عمل.

العائق المشترك. تفترض الطرق الثلاث أن أسماء الأحداث واضحة ومنظمة. عندما يتم إطلاق نفس الإجراء تحت ثلاثة أسماء مختلفة بعد إعادة هيكلة الكود (refactor)، فإن العمل الحقيقي يكمن في التوفيق بينها قبل البدء في أي عملية حسابية.

أين تتباطأ الطريقة اليدوية

يستغرق التقرير الأول صباحاً كاملاً. أما التقرير الرابع فيستغرق وقتاً أطول، لأنه بحلول ذلك الوقت يكون التعريف قد انحرف تدريجياً دون أن يشعر أحد.

تتغير أسماء الأحداث عندما يتغير المنتج. وتغيير الاسم في قاعدة الكود يظهر كمنحدر حاد في مخططك البياني، ويبدو تماماً وكأن المستخدمين قد تخلوا عن الميزة. هكذا ينتهي الأمر بمخطط اعتماد الميزة إلى الإبلاغ عن تغيير في الكود بدلاً من قرار اتخذه العميل.

تؤدي تغييرات الإطلاق (rollout) إلى إفساد المقام. فعندما تصل الميزة إلى 100% من الحسابات، يبدو أن نسبة الاعتماد قد انخفضت، وذلك لمجرد أن عدد المستخدمين المؤهلين قد تضاعف ثلاث مرات.

ثم هناك خطأ الحساب الذي يستمر لأطول فترة. إن جمع أعداد الأحداث بدلاً من المستخدمين الفريدين يؤدي إلى تضخيم نسبة الاعتماد كلما قام عدد قليل من المستخدمين المتميزين (power users) باستخدام الميزة بكثافة.

وهناك تكلفة إضافية لا تظهر إلا عند اقتراب الموعد النهائي. عندما يسأل شخص ما "هل هذا جيد؟"، لا يمكن لنسبة مئوية واحدة أن تجيب، ويصبح بناء المقارنة مشروعاً ثانياً قائماً بذاته.

كيفية بناء التقرير باستخدام Powerdrill Bloom

الخطوة 1: تحميل ملف تصدير الاستخدام الخاص بك

قم بتحميل ملف تصدير الأحداث، أو ملفات الأحداث والحسابات معاً. يقوم Powerdrill Bloom بتحليل الأعمدة فور وصولها، مما يتيح الكشف عن أسماء الأحداث غير المتسقة ومعرفات المستخدمين المفقودة قبل حساب أي نسبة مئوية.

الخطوة 2: وصف التعريف بلغة طبيعية

حدد القواعد بدلاً من بنائها يدوياً. اذكر اسم الحدث، والحد الأدنى، والإطار الزمني، والمستخدمين المؤهلين.

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

الخطوة 3: تصدير المخطط البياني أو التقرير أو العرض التقديمي

استخرج اتجاه الاعتماد، أو جدولاً حسب الشريحة، أو شريحة عرض تجمع بين الرقم والتعريف معاً.

لماذا يتفوق هذا الحل على إعادة بناء التقرير في كل دورة

	الطريقة اليدوية	Powerdrill Bloom
إزالة تكرار المستخدمين من الأحداث	أعمدة مساعدة لكل ملف	طلب المستخدمين الفريدين مباشرة
التقسيم حسب المجموعة المشتركة أو الخطة	ربط الجداول وإعادة بناء الجدول	طلب تفصيل البيانات مباشرة
تغيير أسماء الأحداث بعد الإطلاق	اكتشافه في المخطط البياني لاحقاً	يظهر فوراً عند التحميل
تغيير فئة المستخدمين المؤهلين	إعادة تعديل المقام	تحديد القاعدة الجديدة ببساطة

الصف الثالث هو المكان الذي تُكسب فيه الدقة أو تُفقد. فحدث تم تغيير اسمه وانخفاض حقيقي في الاستخدام يبدوان متطابقين تماماً في المخطط الخطي، وواحد منهما فقط يتطلب اتخاذ إجراء بشأن المنتج.

أخطاء شائعة

حساب الأحداث بدلاً من المستخدمين. عشرة آلاف حدث من مائتي شخص لا يعني اعتماد الميزة. قم بإزالة التكرار أولاً، دائماً.

استخدام جميع المستخدمين المسجلين كمقام لميزة محددة بعلامة (flag). إذا كان بإمكان ثلث الحسابات فقط رؤيتها، فإن الثلثين الآخرين ليسوا أشخاصاً لم يعتمدوا الميزة، بل هم غير مؤهلين لرؤيتها من الأساس.

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

مقارنة معدل إجمالي عبر الأشهر. يتبنى المستخدمون الجدد والحاليون الميزات بمعدلات مختلفة، لذا فإن تغير هذا المزيج يغير الرقم تلقائياً. قسّم البيانات حسب المجموعات المشتركة (cohorts) قبل استخلاص أي استنتاج.

تجاهل تغيير اسم الحدث. تؤدي إعادة هيكلة الكود إلى هبوط حاد يبدو وكأنه تراجع في الاستخدام (churn). تحقق من قاموس الأحداث قبل أن تبدأ في فحص سلوك المستخدمين.

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

تقديم النسبة المئوية دون إرفاق تعريفها. الرقم لا معنى له بدون المقام والحد الأدنى للاستخدام. ضع كليهما على المخطط البياني، تماماً كما تفعل لوحة قياس مؤشرات الأداء الرئيسية (KPI dashboard) الجيدة في تصنيف مقاييسها.

خاتمة

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

ما يجعل هذا الأمر مكلفاً هو ضرورة استمرار هذا التعريف رغم تغييرات المنتج. فأسماء الأحداث التي تم تغييرها وعمليات الإطلاق الموسعة كلاهما يغير الرقم دون أن يلمس أحد التقرير.

إذا كان هذا هو المكان الذي تضيع فيه دورة إعداد التقارير الخاصة بك، فجرّب Powerdrill Bloom على ملف تصدير الاستخدام الخاص بك. راجع أيضاً دليلنا حول بناء مخطط الاحتفاظ بالمجموعات المشتركة (cohort retention chart)، ومجموعتنا المختارة من أدوات AI لتحليلات المنتج، وصفحة مساعد CSV AI.

الأسئلة الشائعة

ما هو اعتماد الميزات؟

هو نسبة المستخدمين المؤهلين الذين استخدموا ميزة ما خلال إطار زمني محدد، ويُقاس بعدد المستخدمين الفريدين وليس بعدد الأحداث. ولا يكون هذا التعريف صحيحاً إلا إذا تم تحديد المقام والحد الأدنى للاستخدام بوضوح.

كيف يمكنني حسابه من ملف تصدير الأحداث؟

احسب عدد المستخدمين الفريدين الذين أطلقوا حدث الميزة داخل إطارك الزمني، ثم اقسم الناتج على عدد المستخدمين المؤهلين. قم بإزالة التكرار أولاً، لأن مستخدماً واحداً يمكنه توليد مئات الأحداث.

هل يجب أن يكون المقام هو جميع المستخدمين أم المستخدمين النشطين؟

استخدم فئة المستخدمين المؤهلين، وهم المستخدمون الذين يمكنهم الوصول إلى الميزة بالفعل. فاستخدام "جميع المستخدمين المسجلين" يعطي رقماً متحفظاً ويقلل من القيمة الفعلية للاعتماد عندما تكون الميزة خلف علامة إطلاق (rollout flag).

كم يجب أن تكون مدة الإطار الزمني للقياس؟

يجب أن تكون طويلة بما يكفي لتغطية دورة الاستخدام الطبيعية؛ أي أسبوعية للمنتجات ذات الاستخدام اليومي، وشهرية للمنتجات ذات الاستخدام الدوري. حافظ على ثباتها عبر التقارير، لأن تغييرها يغير الرقم بالتبعية.

لماذا يختلف رقمي عن رقم أداة التحليلات؟

يرجع ذلك عادةً إلى الإطار الزمني أو قاعدة إزالة التكرار. فغالباً ما تطبق حسابات الاحتفاظ الموثقة فلتر التاريخ على الحدث الأول فقط، وهو ما لن يتمكن جدول البيانات المبني على تصفية كلا الحدثين من تكراره.