Madar AI
→ عودة للمدوّنة
ممارسة

ليه معدّل فقد عملاءك فعلاً 3 أرقام مختلفة (وكيف تستخدم كل واحد فيهم)

فقد العملاء بالعدد، فقد الإيرادات، الفقد القسري — التلات مقاييس التي أغلب المؤسسين بيخلطوا بينهم، إمتى تستخدم أي واحد، الأنماط الخاصة بـMENA التي بتخلّيهم يفترقوا، وكيف تنمذج كل واحد في توقعاتك

ليه معدّل فقد عملاءك فعلاً 3 أرقام مختلفة (وكيف تستخدم كل واحد فيهم)

مؤسس تطبيق اشتراك بيسأل فريقه “إيه معدّل الفقد بتاعنا الشهر ده؟” تلات ناس في الأوضة بيردّوا بتلات أرقام مختلفة. التلاتة صح. وهم كمان كلهم بيقيسوا حاجات مختلفة، واختيار الغلط لقرار معيّن هيبعت الاستراتيجية في الاتجاه الغلط بصمت.

في MENA الفجوة بين التلات أرقام دي أوسع من الأسواق الغربية، لأن البنية التحتية للمدفوعات أكتر تشتّت ومعدّلات رفض البطاقة مع البنوك والمعالجين المحليين هيكلياً أعلى. الفريق التي بيُبلّغ عن “معدّل فقد” واحد من غير ما يقول أي واحد بيخفي معلومات مهمة عن نفسه.

دي التلات معدّلات التي بتفرق، إيه استخدام كل واحد، والنمط في MENA التي يجعلهم يفترقوا.

1. فقد العملاء (مبني على العدد)

بيقيس إيه: النسبة المئوية للعملاء الدافعين التي ألغوا في الفترة.

المعادلة: (العملاء المفقودين خلال الفترة) / (العملاء في بداية الفترة)

استخدامه: التقارير الحدسية للمجلس، أسئلة جودة المنتج (“هل المستخدمون بيتركوا المنتج نفسه؟”)، وسرد الاحتفاظ الرئيسي.

اللي بيفقده: فقد العملاء بيعامل مستخدم بيدفع $99 شهرياً ومستخدم بيدفع $9.99 شهرياً بنفس الطريقة. لو مستخدمين LTV العالي بيفقدوا بمعدّل مختلف عن مستخدمي LTV المنخفض — وده تقريباً دائمًا بيحصل — فقد العملاء هيضلّلك عن التأثير على الإيرادات.

معدّل فقد عملاء 5% ممكن يخفي معدّل فقد إيرادات 12% لو العملاء التي بيفقدوا بشكل غير متناسب هم عملاءك الأعلى قيمة، أو معدّل فقد إيرادات 2% لو العملاء التي بيفقدوا أغلبهم من المستوى الأدنى. الرقم لوحده، من غير تقسيم الإيرادات، ليس كفاية تتحرك بناءً عليه.

2. فقد الإيرادات (مبني على MRR)

بيقيس إيه: النسبة المئوية للإيرادات المتكرّرة الشهرية المفقودة في فترة، قبل عدّ أي توسّع.

المعادلة: (MRR المفقود من الإلغاءات والتنزيلات) / (MRR في بداية الفترة)

استخدامه: التوقع المالي، توقّعات إيرادات حزمة المجلس، حسابات LTV، وأي قرار بيتعلق بالفلوس أكتر من بيتعلق بعدد الرؤوس.

اللي بيفقده: فقد الإيرادات ما بيفرّقش بين “المستخدمين قرّروا يلغوا” و”بطاقتهم اترفضت وما قدرناش نسترجعها”. الاتنين بيقللوا MRR. لكن عندهم تفسيرات تشغيلية مختلفة جداً — واحد مشكلة منتج أو تسعير، التاني مشكلة بنية تحتية للمدفوعات.

ده صحيح خصوصاً في MENA بسبب الرقم التي جاي.

3. الفقد القسري (مبني على فشل الدفع)

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

المعادلة: (MRR المفقود من تجديدات فاشلة/مرفوضة بعد نوافذ إعادة المحاولة) / (MRR في بداية الفترة)

استخدامه: قرارات البنية التحتية للمدفوعات، ضبط المعالج وسياسة إعادة المحاولة، وعزل الفقد “الحقيقي” (المستخدمين بيتركوا بقصد) عن الفقد “التشغيلي” (المستخدمين بيتركوا بالخطأ).

ليه بيهم أكتر في MENA: معدّلات رفض البطاقة على تجديدات الاشتراك أعلى ماديّاً مع البطاقات التركية المعالجة عبر Iyzico، ومع البطاقات المُصدرة في مصر على القنوات الدولية، ومع البطاقات السعودية المُصدرة من Mada الموجّهة عبر معالجين دوليين، مما هي مع البطاقات الأمريكية المُصدرة على Stripe. بنشوف الفقد القسري بيتراوح من 1.5 لـ3 أضعاف الخط الأساسي العالمي في تطبيقات اشتراك MENA بإعدادات إعادة محاولة افتراضية.

تطبيق اشتراك MENA بفقد إيرادات 8% ممكن يكون شغّال 3% طوعي + 5% قسري. الفريق بيفسّر الـ8% على إنها “المنتج ليس بيحتفظ كويس” ويبدأ يشحن ميزات احتفاظ. المشكلة الحقيقية إن سياسة إعادة المحاولة بتسلّم بعد محاولة فاشلة واحدة بدل تلاتة، وإصلاح قناة الدفع هيقفل أغلب الفجوة من غير شغل منتج.

كيف التلاتة بيفترقوا في مجموعة MENA حقيقية

مثال مبسّط كي المحاسبة تبقى ملموسة (الأرقام للتوضيح، ليس من حساب معيّن):

  • 100 عميل دافع في بداية الشهر
  • 8 عملاء مفقودين → 8% فقد عملاء
  • من الـ8 دول: 5 من المستوى الأدنى ($5 شهرياً)، 3 من المستوى الأعلى ($25 شهرياً). إجمالي MRR مفقود: $100 من $1,000 MRR بداية → 10% فقد إيرادات
  • من الـ8 دول: 5 ألغوا بنشاط، 3 عندهم تجديد فاشل النظام سلّم بعد محاولة واحدة. الـ3 دول بيمثّلوا $30 من $100 المفقود → 3% فقد قسري (و7% طوعي)

تلات أرقام صالحة. تلات قصص تشغيلية مختلفة. رقم حزمة المجلس 10% (فقد إيرادات). رقم “إيه التي تصلّحه” هو الـ3% القسري، لأن إقفال الفجوة دي هي أعلى رافعة متاحة.

كيف تنمذج كل واحد في توقعاتك

الغلطة التي الفرق بتعملها هي توقّع “الفقد” كخط واحد. الطريقة الصح هي تنمذج كل مكوّن منفصل لأن كل واحد بيرد على روافع مختلفة:

فقد العملاء بيتجه مع توافق المنتج وجودة التهيئة. بيتحرك على مقاييس زمنية شهرية لربع سنوية وانت بتشحن تغييرات منتج. توقّعه حسب مستوى المستخدم وعمر المجموعة، ليس كرقم واحد.

فقد الإيرادات الطوعي (الجزء من فقد الإيرادات التي جاي من الإلغاءات النشطة) بيتجه مع نفس إشارة توافق المنتج لكن مرجّح بـLTV. لو مستخدمي LTV العالي بيغادروا أسرع من LTV المنخفض، خط فقد الإيرادات الطوعي هيفترق عن خط فقد العملاء — الافتراق ده هو المؤشر القائد إن مجموعاتك الأعلى قيمة ليس سعيدة.

فقد الإيرادات القسري بيتجه مع قرارات البنية التحتية للمدفوعات: سياسة إعادة المحاولة، طلبات تحديث البطاقة، تنوّع قناة الدفع. ممكن يتقصّ بـ30-60% في sprint واحد بإعادة بناء سياسة إعادة المحاولة، والتحسّن ده ثابت بشكل أساسي — على عكس شغل الاحتفاظ المدفوع بالمنتج، التي ينبغي أن يفضل يتصان كل ما قاعدة المستخدمين تتطور.

توقّع كل خط منفصل. حدد أهداف لكل خط. لما التلات خطوط بيتحركوا مع بعض، منتجك هو الرافعة. لما بيفترقوا، منتجك أو مدفوعاتك هو الرافعة — وأي واحد بيقولّك بالضبط فين الشغل.

الإشارة التي Madar بيظهرها هنا

لما Madar AI بيتوصّل ببيانات اشتراكاتك، أول شيء بيعملها هي إنه يقسم الفقد المبلَّغ عنه للتلات مكوّنات دي ويشير لأي واحد بيتحرّك. بنشوف روتينياً تطبيقات اشتراك MENA بـ”مشكلة فقد” بتطلع 60-70% منها قسرية — مشكلة بنية تحتية للمدفوعات متلبسة كمشكلة منتج.

لو تريد تشوف التقسيم ده على بياناتك الحقيقية، الديمو الحي بيعمله في أول 10 دقائق.