هناك فريقان أعرفهما يديران التطبيق نفسه، وقد أبلغا عن معدلات استرداد بلغت 3.1% و5.8% لنفس الشهر. لم يكن أي منهما يكذب. فقد عرّف كل منهما المقياس بطريقة مختلفة، ولم يكتب أحد التعريف في أي مكان.
هذا ما لا يذكره أحد في صفحات الميزات عن تحليلات استرداد الأموال في تطبيقات الجوال. فالرقم لا يكون دقيقًا إلا بقدر دقة قاعدة النسب (attribution) الكامنة خلفه، ومعظم لوحات التحكم (dashboards) لا تُفصح عن القاعدة التي تستخدمها.
لذلك يتناول هذا المقال ما تقوم به هذه الأدوات، والسؤال المنهجي الوحيد الذي يجب طرحه قبل الوثوق بأي منها. وللتعمق في آليات التتبع وحدها، كيفية تتبع عمليات استرداد الأموال في App Store يتناول الموضوع بتفصيل أكبر من جانب Apple.
أهم النقاط
نسب الاسترداد إلى المجموعة (cohort) أفضل من نسبها إلى الفترة الزمنية. احتسب عملية الاسترداد في الشهر الذي تمت فيه عملية الشراء، وليس الشهر الذي وصلت فيه عملية الاسترداد.
قد يمتد تأخر الاسترداد لأسابيع، وأحيانًا لفترة فوترة كاملة. أي لوحة تحكم تعرض معدل هذا الشهر إنما تعرض رقمًا غير مكتمل.
عمليات chargeback ليست عمليات استرداد. تذكر RevenueCat بوضوح أنها لا تحتسبها كاسترداد، لذا تحتاج إلى تغذية بيانات منفصلة.
لوحات تحكم المتاجر مجانية لكنها ضعيفة في رصد الاتجاهات. تمنحك Apple تقارير، وتمنحك Google واجهة API بحد يومي.
أفضل الأدوات لتتبع معدلات استرداد الأموال في تطبيقات الجوال هي تلك التي تنشر مقام حساباتها (denominator).
أولًا، مشكلة التعريف
هناك طريقتان لتتبع معدل استرداد الأموال في التطبيقات، وهما لا تتفقان.
طريقة الفترة الزمنية: عمليات الاسترداد التي وصلت في مارس، مقسومة على المعاملات المفوترة في مارس. سهلة البناء. لكنها خاطئة، لأن عملية استرداد في مارس كثيرًا ما تعود إلى عملية شراء تمت في يناير.
طريقة المجموعة (cohort): من كل ما تمت فوترته في يناير، ما هي النسبة التي تم استردادها منذ ذلك الحين. أصعب، لأن الرقم لا يتوقف عن التغير أبدًا.
توثّق Apphud ذلك بصراحة. مقام حساباتها هو المعاملات المفوترة خلال الفترة، والبسط هو عدد ما تم استرداده لاحقًا، بما في ذلك بعد إغلاق الفترة. هذا هو نهج المجموعة (cohort)، وهو يتطابق مع طريقة سلوك عمليات الاسترداد.
لذا تحتاج إلى نقطة قطع زمنية. تستقر الاشتراكات الشهرية في حدود 30 إلى 45 يومًا، بينما تظل الخطط السنوية متغيرة لأشهر. مقارنة رقم عمره 10 أيام برقم عمره 90 يومًا هي مقارنة ضجيج لا أكثر.
المستوى المجاني: لوحات تحكم المتاجر
ابدأ من هنا. فهو لا يكلف شيئًا، وهو المكان الذي تتوقف عنده معظم الفرق.
App Store Connect. يمنحك قسم Sales and Trends إلى جانب Financial Reports بيانات عمليات الاسترداد، والتقرير المالي يطابق دفعتك المالية. وهو يعتمد على الفترة الزمنية، ويدوي، ولا يوفر تجزئة حسب المنتج أو القناة. مناسب كفحص صحة شهري. لكنه عديم الفائدة في معرفة أي شاشة دفع (paywall) تستنزف الإيرادات.
أفضل تغذية بيانات مجانية ليست موجودة في لوحة التحكم إطلاقًا. فنقطة النهاية Get Refund History من Apple تُرجع قائمة مقسّمة إلى صفحات بكل معاملة تم استردادها لكل عميل، ويمكنك سحبها إلى مستودع بياناتك الخاص. وهي محدودة المعدل، وتوصي Apple باستخدام الإشعارات بدلًا من الاستطلاع الدوري (polling)، لذا تعامل معها كأداة تسوية فقط.
Google Play Console. تقارير مالية مرة أخرى، بالإضافة إلى Voided Purchases API التي تسرد المشتريات المستردة أو التي خضعت لعملية chargeback أو تم إلغاؤها خلال فترة زمنية معينة. وهي محدودة بـ6,000 طلب يوميًا و30 طلبًا كل 30 ثانية، لذا فهي مصممة لعمليات المسح المجدولة، وليس لأي شيء لحظي.
تشترك لوحتا التحكم في عيب واحد عند العمل على الاتجاهات. فهما تعرضان ما تمت تسويته، وليس ما تم طلبه، لذا لن ترى أبدًا الطلبات التي نجحت في الدفاع عنها.
RevenueCat
إذا كانت اشتراكاتك تمر عبرها بالفعل، فهذا هو الخيار الافتراضي.
معدل الاسترداد هو أحد مقاييسهم المرجعية: نسبة الاشتراكات المدفوعة التي تم استردادها خلال فترة الفوترة الأولى، مقارنة بالتطبيقات الأخرى في متجرك وفئتك. هذه المقارنة المرجعية هي الجزء المفيد فعلًا، إذ يصعب التصرف بناءً على رقم خام دون سياق مقارن. ويغطي تقريرهم State of Subscription Apps أكثر من 75,000 تطبيق، ويضع المتوسطات في حدود 3% إلى 5%.
كما يوجد مخطط App Store Refund Requests الذي يقسّم الطلبات إلى مقبولة ومرفوضة وملغاة ومعلقة بانتظار الحل. وهذا تفصيل على مستوى الطلب، وهو أمر تتجاهله معظم الأدوات.
هناك تحفظان. عمليات استرداد Play التي تمنحها Google وليس أنت قد تستغرق حتى 24 ساعة للظهور، وعمليات الاسترداد الصادرة دون تفعيل خانة الإلغاء لا تُكتشف إطلاقًا. كما أن RevenueCat لا تحتسب عمليات chargeback ضمن الاسترداد. تتحدث حالة الشراء، لكن معدل الاسترداد لا يتحرك.
Adapty
أقوى في التجزئة من معظم الأدوات الأخرى. يتم تقسيم تتبع الاسترداد حسب اليوم والخطة والمنتج وقناة الاكتساب، وهو التقسيم الذي يكشف المشكلات فعليًا. فمعدل يبدو جيدًا بشكل عام لكنه سيئ على قناة واحدة هو خلل في الرسالة التسويقية، وليس خللًا في المنتج.
تستند معاييرهم المرجعية إلى 1.9 مليار دولار من الإيرادات المتتبَّعة عبر أكثر من 11,000 تطبيق، والتفاوت بين الفئات كبير بما يكفي ليكون ذا دلالة: تطبيقات التعليم والصحة قرابة 4.7% إلى 5.1%، وتطبيقات السفر والخدمات أقرب إلى 1.5% إلى 2.1%. وتُسترد الخطط السنوية أكثر من الأسبوعية. وتسجل شاشات الدفع الصارمة (hard paywalls) نحو 5.8% مقابل 3.4% للنموذج المجاني المدعوم (freemium).
والمأخذ هنا هو نفسه في بقية منتجهم: هذه التحليلات الجيدة تفترض أنك تستخدم Adapty SDK.
Apphud
أصغر حجمًا وأرخص، وواضح بشكل غير معتاد فيما يتعلق بالمنهجية، وهذا وحده يكفي لإدراجه في القائمة المختصرة. توضح وثائقهم منطق المجموعة (cohort) بدلًا من إخفائه. لوحات تحكم لحظية، وحوالي 18 حدث اشتراك، وتسويق أقل من البدائل الأخرى.
إذا كنت تريد رقمًا يمكنك الدفاع عنه في اجتماع مجلس الإدارة، فالوضوح يتفوق على قائمة ميزات أطول.
تتبع مخصص لعمليات الاسترداد وchargeback
وهنا تكمن الفجوة. منصات الاشتراكات تحتسب عمليات الاسترداد التي تمت تسويتها. لا توجد أي منها داخل نافذة الرد، لذا لا يمكن لأي منها أن تخبرك بعدد الطلبات التي نجحت في الدفاع عنها، أو معدل نجاحك مقسّمًا حسب سبب الاسترداد.
هذه مجموعة بيانات مختلفة، ولا توجد إلا إذا كان هناك من يرد على هذه الطلبات. Refund Sensor يتتبع طلبات استرداد Apple ومراجعات chargeback في Google Play كحالات، مع جداول زمنية ونتائج وإيرادات تم الدفاع عنها، والمتجران معًا في لوحة تحكم واحدة. وهو يعرض الطلبات التي لم تتحول أبدًا إلى عمليات استرداد.
يستحق الأمر الجمع بينهما، لا الاستبدال. منصة اشتراكات لتحليلات المجموعة (cohort)، وبرنامج حماية إيرادات تطبيقات الجوال لاتجاهات مستوى الطلب. أسئلة مختلفة، ولا تغطي إحداهما الأخرى.
تتبع عمليات chargeback بشكل منفصل
اتجاهات chargeback ليست مجموعة فرعية من اتجاهات الاسترداد، والتعامل معها على هذا الأساس هو الخطأ الأكثر شيوعًا الذي أراه في تتبع عمليات الاسترداد لتطبيقات الجوال.
على Google Play تختلف الإشارات. ترسل Real-time developer notifications إشعار voidedPurchaseNotification عند إلغاء شيء ما، وإشعار pendingRefundReviewNotification عندما تحتاج عملية chargeback إلى إدخال منك. وتحمل Voided Purchases API حقل voidedReason بتسع قيم، من بينها fraud وfriendly_fraud وchargeback. وهذا أقرب شيء متاح لرصد اتجاه مجاني لعمليات chargeback.
أما على Apple فالأمر عبارة عن إشعار REFUND مع سبب إلغاء، بالإضافة إلى REFUND_DECLINED وREFUND_REVERSED للحالات التي لم تثبت.
للحصول على اتجاه صادق لعمليات chargeback، ارسم قيمة voidedReason التي تساوي chargeback عبر الزمن، مقسّمة حسب المنتج. ثم ارسم fraud وfriendly_fraud كلًا على حدة، لأن هذه الحسابات تتكرر وتحتاج إلى استجابة مختلفة. تناولنا أي تغذية بيانات تقوم بماذا في Voided Purchases API مقابل real-time developer notifications.
كيفية تتبع معدلات الاسترداد وchargebacks في تطبيقات الجوال
المنظومة التي سأبنيها فعليًا، بالترتيب:
اختر قاعدة نسب (attribution) ودوّنها: المجموعة (cohort)، مع نقطة قطع محددة لكل مدة خطة.
اربط تغذيات بيانات المتاجر. App Store Server Notifications V2، وRTDN على Play. فبدونها ستكون تقرأ ملفات CSV شهرية فقط.
خزّن كل حدث استرداد مرتبطًا بالمعاملة الأصلية، وليس بتاريخ اليوم.
أضف أحداث على مستوى الطلب، وإلا فلن ترى أبدًا ما منعت حدوثه.
افصل عمليات chargeback وامنحها رموز أسباب خاصة بها.
قارن مرجعيًا بفئتك، لا بمتوسط عالمي.
الخطوة 3 هي حيث تنهار الأنظمة المبنية داخليًا بصمت، والخطوة 6 هي حيث تضلل لوحات التحكم بصمت. لا شيء من الاثنين صعب. لكن كليهما غالبًا ما يُتجاوز.
أما بالنسبة لجانب التكلفة بدلًا من جانب المعدل، فإن كيف تكلفك عمليات الاسترداد فعليًا من إيرادات تطبيقك يقدم هذا الحساب. فالمعدل وحده لا يخبرك بما يجب فعله بعد ذلك.
المصادر
الأسئلة الشائعة
استخدم RevenueCat إذا كنت تريد معايير مرجعية حسب الفئة ومخططات على مستوى الطلبات من Apple. استخدم Adapty إذا كنت بحاجة إلى تجزئة حسب القناة والخطة. استخدم Apphud إذا كنت تريد أوضح منهجية منشورة. أضف أداة دفاع إذا كنت تريد أيضًا رؤية الطلبات التي لم تتحول أبدًا إلى عمليات استرداد.
قسّم عدد المعاملات المسترَدة على عدد المعاملات المدفوعة، مع نسبها إلى الفترة التي تمت فيها عملية الشراء. بعد ذلك، حدّد المدة التي تسمح فيها للمجموعة (cohort) بالنضوج قبل اعتبار الرقم نهائيًا. بالنسبة للخطط الشهرية، من 30 إلى 45 يومًا. أما الخطط السنوية فتحتاج مدة أطول.
ما بين 2% و5% من المعاملات المدفوعة بالنسبة لتطبيقات الاشتراكات. تطبيقات التعليم والصحة واللياقة البدنية تسجل معدلات أعلى، بينما تطبيقات السفر والخدمات تسجل معدلات أقل. إذا تجاوز المعدل 10%، توقف عن النظر في التسويق واذهب لمراجعة شاشة الدفع (paywall) الخاصة بك.
ليس بشكل كامل. تعرض التقارير المالية من Apple عمليات الاسترداد التي تمت تسويتها. وتعرض Voided Purchases API من Google المشتريات الملغاة مع رمز للسبب، وهو أقرب شيء متاح، لكنه محدود بـ6,000 طلب يوميًا ويتطلب عملية مسح مجدولة.
غالبًا ما يكون السبب هو تأخر النسبة (attribution lag). تقارير الإيرادات تعتمد على الفترة الزمنية، في حين ينبغي أن تعتمد معدلات الاسترداد على المجموعات (cohort)، ولا يتطابق الرقمان إلا بعد وصول كل عملية استرداد. تحقق أيضًا مما إذا كانت عمليات chargeback مشمولة، إذ تستبعدها بعض الأدوات.
لا تنشر Apple أي حد محدد لذلك، وسأكون متشككًا تجاه أي شخص يذكر رقمًا بثقة. أما الموثّق فعليًا فهو أن استمرار ارتفاع معدلات الاسترداد والنزاعات يمكن أن يؤثر على وضع الحساب في Google Play. وهذا سبب أقوى لتتبع الاتجاه بدلًا من التركيز على الرقم نفسه فقط.
