هناك تكلفة خفية لكل SDK إعلاني تدمجه في تطبيقك. كل واحد منها يضيف إلى حجم binary الخاص بتطبيقك، ويزيد من وقت cold start، ويُحدث تعارضات توافق محتملة، ويُنشئ تبعية إضافية تحتاج إلى تحديث عند صدور إصدارات نظام تشغيل جديدة. بالنسبة للناشرين الذين يشغّلون خمسة أو ثمانية أو حتى اثني عشر SDK، فإن التأثير التراكمي على أداء التطبيق وتجربة المستخدم قد يكون كبيراً — وغالباً ما يكون غير مرئي لأنه يحدث تدريجياً.
التكلفة الحقيقية لتضخم SDK
كل ميغابايت يُضاف إلى binary تطبيقك مهم. تُظهر الأبحاث باستمرار أن معدلات تحويل التثبيت تنخفض بشكل ملموس مع كل ميغابايت إضافي من حجم التنزيل. في الأسواق الناشئة حيث المساحة التخزينية محدودة والاتصالات أبطأ، يكون التأثير أكثر وضوحاً. ناشر يضيف ثلاثة SDK إعلانية بحجم إجمالي 15 ميغابايت قد يخسر من revenue بسبب انخفاض التثبيتات أكثر مما يكسبه من الطلب الإضافي الذي توفره تلك الحزم.
بخلاف حجم التنزيل، تستهلك الحزم موارد وقت التشغيل. كل SDK يتم تهيئته عند إطلاق التطبيق يضيف إلى وقت الإقلاع. المستخدمون الذين ينتظرون أكثر من ثلاث ثوانٍ لتحميل التطبيق أكثر عرضة بشكل ملحوظ للتخلي عنه. وكل SDK يعمل في الخلفية يستهلك الذاكرة والبطارية — موارد يلاحظها المستخدمون وتعاقب عليها متاجر التطبيقات بشكل متزايد.
تدقيق SDK
ابدأ بتدقيق مجموعة SDK الحالية لديك بشكل شامل. لكل SDK إعلاني في تطبيقك، قِس ثلاثة أشياء أساسية: حجم binary الذي يضيفه، و revenue الذي يولّده، و fill rate الخاص به. ستجد على الأرجح أن واحداً أو اثنين من SDK مسؤولان عن غالبية revenue الخاص بك، بينما يساهم العديد من الحزم الأخرى بشكل هامشي لكنها تضيف عبئاً كبيراً.
قاعدة 80/20 تنطبق
في معظم تطبيقات الناشرين، يولّد اثنان إلى ثلاثة SDK إعلانية 80 بالمائة أو أكثر من إجمالي revenue الإعلانات. تملأ الحزم المتبقية الفجوات لكن غالباً بتكلفة تتجاوز مساهمتها عند احتساب تأثير الأداء. الهدف ليس إزالة جميع الحزم — بل إيجاد الحد الأدنى من المجموعة التي تحقق أقصى revenue.
الحلول من جانب الخادم
الطريقة الأكثر فعالية لتقليل عدد SDK دون فقدان تنوع الطلب هي نقل تجميع الطلب من جانب العميل إلى جانب الخادم. يتيح Open Bidding من Google، على سبيل المثال، لشركاء demand متعددين التنافس على مخزونك دون الحاجة إلى دمج حزمهم الفردية في تطبيقك. تحصل على الضغط التنافسي لعدة مزايدين مع بساطة دمج SDK واحد.
نهج الطلب المُدار
يأخذ شريك demand المُدار هذا المفهوم إلى أبعد من ذلك. بدلاً من دمج عدة SDK بنفسك، تقوم بدمج نقطة اتصال واحدة — سواء عبر منصة mediation الحالية أو من خلال تكامل خفيف من جانب الخادم. يقوم الشريك المُدار بتجميع الطلب من عشرات المصادر على بنيته التحتية، ولا يرى تطبيقك سوى مصدر demand واحد فقط. والنتيجة هي تنوع أكبر في الطلب مع عبء SDK أقل.
الناشرون الأذكى لا يسألون "كم SDK يمكنني إضافتها؟" بل يسألون "ما الحد الأدنى من SDK الذي أحتاجه لتحقيق أقصى revenue؟" والجواب دائماً تقريباً أقل مما لديهم حالياً.
خطوات عملية لتقليل تضخم SDK
1. أزل الحزم ضعيفة الأداء
إذا كان SDK يولّد أقل من 5 بالمائة من إجمالي revenue الإعلانات، فكّر جدياً في إزالته. تكلفة الأداء على الأرجح تتجاوز مساهمته في الإيرادات.
2. وحّد من خلال mediation
استخدم محولات mediation المدمجة في منصتك بدلاً من عمليات دمج SDK المستقلة حيثما أمكن. محولات mediation عادةً أخف وزناً من عمليات دمج SDK الكاملة.
3. استفد من المزايدة من جانب الخادم
انقل شركاء demand الذين يدعمون المزايدة من جانب الخادم إلى هذا النموذج. هذا يزيل SDK الخاص بهم من تطبيقك مع الحفاظ على طلبهم في waterfall الخاص بك.
4. استخدم شريكاً مُداراً للطلب طويل الذيل
بدلاً من دمج خمسة SDK متخصصة للطلب الإقليمي أو المتخصص، استخدم شريكاً مُداراً واحداً يجمّع هذا الطلب من جانب الخادم.
قياس الأثر
بعد تقليل عدد SDK في تطبيقك، راقب ثلاثة مقاييس رئيسية: تقليص حجم التطبيق، وتحسن وقت الإقلاع، وإجمالي revenue الإعلانات. يجب أن يُظهر تقليل SDK المنفذ بشكل جيد تحسينات ملموسة في المقياسين الأولين دون تغيير كبير — أو حتى تحسن — في الثالث، حيث يؤدي تقليص حجم التطبيق إلى معدلات تثبيت أعلى واحتفاظ أفضل بالمستخدمين.