تحديث تطبيق سيّئ قد يُطلق موجة من عمليات ردّ الأموال، وإليك كيف تحتويها قبل أن تصل إلى أرباحك

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

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

لماذا يتحوّل تحديث التطبيق السيّئ إلى عمليات ردّ أموال

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

المال الذي تخسره أكبر من البيع

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

موجة ردّ الأموال تُحرّك أيضاً معدّل الاسترداد لديك

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

كيف توقف إصداراً سيّئاً على App Store

أداة الاحتواء لدى Apple هي الطرح المرحلي، وقيمته كلّها في أنّك تستطيع سحب المكابح قبل أن يرى معظم مستخدميك النسخة المعطوبة.

الطرح المرحلي يمتدّ على سبعة أيام

عندما تُفعّل الطرح المرحلي لتحديث نسخة، توصله Apple إلى عيّنة عشوائية من المستخدمين الذين فعّلوا التحديثات التلقائية. ويتصاعد الطرح وفق جدول ثابت: 1 بالمئة في اليوم الأول، ثم 2 و5 و10 و20 و50 و100 بالمئة على مدى سبعة أيام. ولأنّ الأيام الأولى تلامس جزءاً صغيراً من قاعدتك، فإنّ عيباً يُكتشف في اليوم الثاني يكون قد وصل إلى عدد أقل بكثير من الناس مما كان سيصل إليه إصدار كامل في اليوم نفسه.

أوقف اللحظة التي يبدو فيها شيء خاطئاً

إذا تسلّل تحديث تطبيق سيّئ، يمكنك إيقاف الطرح المرحلي في أيّ نقطة. تتيح لك Apple الإيقاف لمدة تصل إلى 30 يوماً دون حدّ لعدد مرّات الإيقاف، والرصيد تراكمي: أوقف 10 أيام، ثم استأنف، ويبقى لديك 20 يوماً من الإيقاف. وعندما تستأنف، يواصل الطرح من اليوم الذي توقّف فيه. الإيقاف لا يسحب النسخة من المستخدمين الذين يملكونها بالفعل، لذا اقرن الإيقاف بإصلاح ومراجعة معجّلة.

كيف توقف إصداراً سيّئاً على Google Play

يمنحك Google Play مكبحين، أحدهما لإصدار لا يزال قيد الطرح، والآخر لإصدار وصل بالفعل إلى الجميع.

أوقف طرحاً متدرّجاً قيد التنفيذ

الطرح المتدرّج على Google Play يتيح لك الإصدار إلى نسبة من المستخدمين ورفعها وفق جدولك الخاص. إذا وجدت مشكلة، افتح الإصدار واختر Manage rollout، ثم Halt rollout. لن يصل أيّ مستخدمين إضافيين إلى النسخة، ويبقى المستخدمون الذين حصلوا عليها بالفعل عليها. وإذا تبيّن أنّ النسخة سليمة في النهاية، تستأنف الطرح نفسه من حيث توقّف.

أوقف إصداراً وصل بالفعل إلى 100 بالمئة

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

عندما تكون عمليات ردّ الأموال والاعتراضات جارية بالفعل

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

معظم عمليات ردّ الأموال تُقرّر من دونك

استرداد Google Play الذاتي خلال 48 ساعة، وعمليات الردّ عبر الدعم، والمشتريات المُلغاة، كلّها يقرّرها المتجر وفق سياسته الخاصة. لا توجد قناة أدلة ولا استئناف. بالنسبة لتلك، سجلّك هو عملية الردّ نفسها والتكلفة التي تحمّلتها بالفعل. المكان الوحيد الذي يمكنك التصرّف فيه هو الوقاية، وهذا بالضبط سبب أهمية مكبح الطرح.

نافذتان فقط هما مدخلك الوحيد

عمليتان فقط تطلبان منك شيئاً. عندما يطلب عميل استرداداً على سلعة استهلاكية أو اشتراك متجدّد تلقائياً، تُرسل Apple إلى خادمك CONSUMPTION_REQUEST وتنتظر حتى 12 ساعة للحصول على بيانات الاستهلاك. وعلى Google Play، عملية شراء متنازع عليها تحتاج إلى مراجعة تُطلق ساعة مدتها 24 ساعة، وتُجيب عبر واجهة orders.reviewrefund. فوّت أياً من النافذتين ويُتّخذ القرار من دونك. لا تتيح لك أيّ من النافذتين التراجع عن إصدار سيّئ. إنّهما تتيحان لك فقط الاستجابة لتبعاته.

قائمة تدقيق الاحتواء

لا شيء من هذا غريب. إنّه روتين قصير تُنفّذه على كلّ إصدار، لا على تلك التي تتوقّع أن تتعطّل فقط.

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