هر SDK تبلیغاتی که در اپلیکیشن خود ادغام میکنید، هزینه پنهانی دارد. هر کدام به binary size شما اضافه میکند، زمان cold start را افزایش میدهد، تداخلات سازگاری بالقوه ایجاد میکند و یک وابستگی دیگر میسازد که با انتشار نسخههای جدید OS نیاز به بهروزرسانی دارد. برای ناشرانی که پنج، هشت یا حتی دوازده SDK اجرا میکنند، تأثیر تجمعی بر عملکرد اپلیکیشن و تجربه کاربری میتواند قابل توجه باشد — و اغلب نامرئی است زیرا به تدریج اتفاق میافتد.
هزینه واقعی تورم SDK
هر مگابایتی که به binary اپلیکیشن شما اضافه میشود اهمیت دارد. تحقیقات به طور مداوم نشان میدهد که نرخ تبدیل نصب با هر مگابایت اضافی حجم دانلود به طور محسوسی کاهش مییابد. در بازارهای نوظهور که کاربران فضای ذخیرهسازی محدود و اتصالات کندتری دارند، تأثیر حتی بارزتر است. ناشری که سه SDK تبلیغاتی با حجم کل ۱۵ مگابایت اضافه میکند، ممکن است از کاهش نصبها بیشتر revenue از دست بدهد تا آنچه از تقاضای افزایشی که آن SDKها فراهم میکنند به دست میآورد.
فراتر از حجم دانلود، SDKها منابع runtime مصرف میکنند. هر SDK که هنگام راهاندازی اپلیکیشن مقداردهی اولیه میشود به زمان شروع شما اضافه میکند. کاربرانی که بیش از سه ثانیه منتظر بارگذاری اپلیکیشن میمانند، احتمال ترک آن به طور قابل توجهی بیشتر است. و هر SDK که در پسزمینه اجرا میشود حافظه و باتری مصرف میکند — منابعی که کاربران متوجه آن میشوند و فروشگاههای اپلیکیشن به طور فزایندهای بابت آن جریمه میکنند.
ممیزی SDK
با ممیزی پشته SDK فعلی خود شروع کنید. برای هر SDK تبلیغاتی در اپلیکیشنتان، سه چیز را اندازه بگیرید: binary size که اضافه میکند، revenue که تولید میکند و fill rate آن. تقریباً مطمئناً خواهید یافت که یک یا دو SDK مسئول بخش عمده revenue شما هستند، در حالی که چندین مورد دیگر سهم حاشیهای دارند اما سربار قابل توجهی اضافه میکنند.
قانون 80/20 صدق میکند
در اکثر اپلیکیشنهای ناشران، دو تا سه SDK تبلیغاتی ۸۰ درصد یا بیشتر از کل revenue تبلیغات را تولید میکنند. SDKهای باقیمانده شکافها را پر میکنند اما اغلب با هزینهای که وقتی تأثیر عملکردی را در نظر بگیرید از سهمشان فراتر میرود. هدف حذف همه SDKها نیست — بلکه یافتن حداقل مجموعهای است که حداکثر revenue را جذب کند.
راهحلهای سمت سرور
مؤثرترین راه برای کاهش تعداد SDK بدون از دست دادن تنوع تقاضا، انتقال تجمیع تقاضا از سمت کلاینت به سمت سرور است. Open Bidding گوگل، به عنوان مثال، به چندین demand partner اجازه میدهد بدون نیاز به SDKهای جداگانهشان در اپلیکیشن شما، برای inventory شما رقابت کنند. شما فشار رقابتی چندین bidder را با سادگی یک ادغام SDK واحد به دست میآورید.
رویکرد demand مدیریتشده
یک demand partner مدیریتشده این مفهوم را فراتر میبرد. به جای ادغام چندین SDK توسط خودتان، یک نقطه اتصال ادغام میکنید — یا از طریق پلتفرم mediation موجود یا از طریق یک ادغام سبک سمت سرور. partner مدیریتشده تقاضا را از دهها منبع در زیرساخت خود تجمیع میکند و اپلیکیشن شما فقط یک منبع demand میبیند. نتیجه تنوع بیشتر تقاضا با سربار SDK کمتر است.
هوشمندترین ناشران نمیپرسند "چند SDK میتوانم اضافه کنم؟" آنها میپرسند: "حداقل تعداد SDK که برای جذب حداکثر revenue نیاز دارم چقدر است؟" پاسخ تقریباً همیشه کمتر از آن چیزی است که در حال حاضر دارند.
گامهای عملی برای کاهش تورم SDK
1. SDKهای کمبازده را حذف کنید
اگر یک SDK کمتر از ۵ درصد کل revenue تبلیغات شما را تولید میکند، جداً حذف آن را در نظر بگیرید. هزینه عملکردی احتمالاً از سهم آن در revenue فراتر میرود.
2. از طریق mediation یکپارچه کنید
تا جایی که ممکن است به جای ادغامهای مستقل SDK از آداپتورهای داخلی پلتفرم mediation خود استفاده کنید. آداپتورهای mediation معمولاً سبکتر از ادغامهای کامل SDK هستند.
3. از server-side bidding بهره ببرید
demand partnerهایی که از server-side bidding پشتیبانی میکنند را به این مدل منتقل کنید. این کار SDK آنها را از اپلیکیشن شما حذف میکند در حالی که demand آنها را در waterfall شما حفظ میکند.
4. از یک partner مدیریتشده برای demand دمبلند استفاده کنید
به جای ادغام پنج SDK تخصصی برای demand منطقهای یا تخصصی، از یک partner مدیریتشده واحد استفاده کنید که آن demand را در سمت سرور تجمیع میکند.
اندازهگیری تأثیر
پس از کاهش تعداد SDK، سه معیار را رصد کنید: کاهش حجم اپلیکیشن، بهبود زمان راهاندازی و کل revenue تبلیغات. یک کاهش SDK بهخوبی اجرا شده باید بهبودهای قابل اندازهگیری در دو مورد اول بدون تغییر قابل توجه — یا حتی با بهبود — در سومی نشان دهد، زیرا حجم کمتر اپلیکیشن به نرخ نصب بالاتر و حفظ بهتر کاربران منجر میشود.