الطلب المسبق للتطبيق ليس عملية بيع حتى يوم الإطلاق، والكثير منها يتلاشى قبل أن يُخصم المبلغ

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

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

لماذا الطلب المسبق وعد وليس دفعًا

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

ما الذي يحدث بين الطلب المسبق والخصم

على App Store، يقع الخصم عند الإصدار وليس قبله

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

على Google Play، يُفحص الدفع قبل نحو يومين

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

أين تتلاشى الطلبات المسبقة بهدوء

الإلغاء المجاني الذي لا يتعين على أحد أن يخبرك به

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

إخفاقات الدفع عند خط النهاية

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

ماذا تكلفك هذه الفجوة فعلًا

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

سعة تجهّزها لمشترين لا يصلون أبدًا

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

مكافآت أنت مدين بها سواء دفعوا أم لا

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

تاريخ إطلاق متأخر يمكن أن يسترد الدفتر كله

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

قاعدة السعر التي قد تخفض ما يدفعه طالبو الطلب المسبق

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

بعد الإطلاق، الطلب المسبق مجرد عملية شراء عادية

تنتهي القواعد الخاصة لحظة إصدار التطبيق. بمجرد أن يُخصم الطلب المسبق ويُنزَّل التطبيق، يصبح عملية شراء عادية ويتبع مسار الاسترداد العادي. على Google Play يعني ذلك أن للمشتري نافذة الـ48 ساعة القياسية التي يمكن لـGoogle خلالها منح استرداد كامل من تلقاء نفسه، وبعدها يأتون إليك. على App Store يعني ذلك أن المشتري يطلب استردادًا عبر Apple، وApple تقرر. إذن الطلب المسبق لا يمنح المشتري أي حقوق استرداد إضافية بعد الإطلاق، ولا يمنحك أنت أي حماية إضافية. كل ما تعرفه بالفعل عن الاسترداد على كل متجر ينطبق من يوم الإصدار فصاعدًا، دون تغيير.

لحظة أن يُخصم الطلب المسبق عند الإصدار، يصبح عملية شراء على App Store Server Notifications وReal-time Developer Notifications نفسها التي يقرأها RefundHalt بالفعل. الحجوزات التي لم تُخصم أبدًا لا تترك أثرًا على تلك التغذيات، لأنه لم يتحرك أي مال قط. ما يظهر هو عمليات الاسترداد والإلغاء التي تلي الإطلاق، لذا مراقبة تلك التغذيات تخبرك بما تساويه مجموعة طلباتك المسبقة فعلًا بعد أن ينتهي الجزء المجاني ويبدأ الجزء المدفوع.

باختصار

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