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

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

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

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

شراء لمرة واحدة

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

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

الاشتراك

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

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

مجاني مع إعلانات

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

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

نموذج «فريميوم»

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

مجاني

أما بالنسبة للأدوات، فنحن نريدها أن تظل موجودة في جميع الأحوال. وتندرج ضمن هذه الفئة بعض تطبيقاتنا الأصغر حجمًا. وهي تُمول من عائدات التطبيقات المدفوعة.

الأخطاء التي ارتكبناها

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

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