1. نبدأ بباقات حقيقية من المورد

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

2. نفصل البيانات الثابتة عن الباقات اليومية/FUP

الباقة التي تقدم “1GB يومياً” ليست نفس المنتج الذي يقدم 5GB إجمالاً. يصنف محرك الكتالوج النوعين بشكل منفصل حتى لا تحل باقة يومية مكان باقة البداية ذات البيانات الثابتة دون وضوح.

3. نطبق حداً أدنى للفائدة العملية

لا تدخل مجموعة باقات البداية إلا الباقات التي تحقق الحد الأدنى المحدد للبيانات ومدة الصلاحية. هذا يمنع أن يكون السعر الرئيسي مبنياً على منتج صغير جداً وغير عملي.

4. نطبق سقفاً لتكلفة الجملة

لا تتأهل لفئة $5 إلا الباقات التي تقع تكلفة الجملة الحالية لها داخل السقف المحدد. إذا ارتفعت تكلفة المورد فوق هامش الأمان، يبحث النظام عن باقة أخرى مؤهلة. وإذا لم توجد، يجب أن تختفي باقة $5 بدلاً من بيعها بهامش غير آمن.

5. نختار أقوى باقة بداية مؤهلة

بين الباقات المؤهلة، يفضل النظام إجمالي بيانات أكبر ومدة صلاحية مفيدة بدلاً من اختيار أرخص بند جملة فقط.

6. نسعّر الباقات الأكبر بشكل منفصل

يتم تسعير الترقيات انطلاقاً من تكلفة المورد باستخدام قواعد حد أدنى للربح الإجمالي وهامش مستهدف. لذلك لا يكون سعر باقة 10GB أو 20GB مجرد مضاعف ثابت لسعر $5.

7. نتحقق مرة أخرى قبل التنفيذ

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

مهم

إلى أن يتم إعداد بيانات اعتماد API المباشرة والمزامنة المجدولة، يستخدم المتجر أحدث نسخة مستوردة من قائمة أسعار المورد. بيانات الباقات وتكاليف الجملة حقيقية لتلك النسخة، لكن لا يمكن ضمان أنها محدثة دقيقة بدقيقة.