Terdapat kos tersembunyi pada setiap SDK iklan yang anda integrasikan ke dalam apl anda. Setiap satu menambah binary size, memanjangkan masa cold start, memperkenalkan potensi konflik keserasian, dan mewujudkan satu lagi kebergantungan yang perlu dikemas kini apabila versi OS baharu dikeluarkan. Bagi penerbit yang menjalankan lima, lapan, atau bahkan dua belas SDK, kesan kumulatif terhadap prestasi apl dan pengalaman pengguna boleh menjadi signifikan — dan ia sering kali tidak kelihatan kerana berlaku secara beransur-ansur.
Kos sebenar SDK yang membengkak
Setiap megabait yang ditambah pada binary apl anda adalah penting. Penyelidikan secara konsisten menunjukkan bahawa kadar penukaran pemasangan apl menurun secara ketara dengan setiap megabait tambahan saiz muat turun. Di pasaran membangun di mana pengguna mempunyai storan terhad dan sambungan yang lebih perlahan, kesannya lebih ketara. Penerbit yang menambah tiga SDK iklan berjumlah 15 megabait mungkin kehilangan lebih banyak hasil daripada pemasangan yang berkurangan berbanding yang diperoleh daripada permintaan tambahan yang disediakan oleh SDK tersebut.
Selain saiz muat turun, SDK menggunakan sumber masa jalan. Setiap SDK yang dimulakan semasa pelancaran apl menambah masa permulaan anda. Pengguna yang menunggu lebih daripada tiga saat untuk apl dimuatkan lebih cenderung untuk meninggalkannya. Dan setiap SDK yang berjalan di latar belakang menggunakan memori dan bateri — sumber yang pengguna perasan dan yang kedai apl platform semakin mengenakan penalti.
Audit SDK
Mulakan dengan mengaudit timbunan SDK semasa anda. Untuk setiap SDK iklan dalam apl anda, ukur tiga perkara: binary size yang ditambah, hasil yang dijana, dan fill rate-nya. Anda hampir pasti akan mendapati bahawa satu atau dua SDK bertanggungjawab untuk majoriti hasil anda, manakala beberapa yang lain menyumbang secara marginal tetapi menambah beban yang signifikan.
Peraturan 80/20 terpakai
Dalam kebanyakan apl penerbit, dua hingga tiga SDK iklan menjana 80 peratus atau lebih daripada jumlah hasil iklan. SDK yang selebihnya mengisi jurang tetapi sering kali pada kos yang melebihi sumbangan mereka apabila anda mengambil kira kesan terhadap prestasi. Matlamatnya bukan untuk menghapuskan semua SDK — ia adalah untuk mencari set minimum yang menangkap hasil maksimum.
Penyelesaian sisi pelayan
Cara paling berkesan untuk mengurangkan bilangan SDK tanpa kehilangan kepelbagaian permintaan adalah mengalihkan pengagregatan permintaan dari sisi klien ke sisi pelayan. Contohnya, Google Open Bidding membenarkan berbilang rakan permintaan bersaing untuk inventori anda tanpa memerlukan SDK individu mereka dalam apl anda. Anda mendapat tekanan persaingan berbilang pembida dengan kesederhanaan integrasi SDK tunggal.
Pendekatan permintaan terurus
Rakan permintaan terurus membawa konsep ini lebih jauh. Daripada mengintegrasikan berbilang SDK sendiri, anda mengintegrasikan satu titik sambungan — sama ada melalui platform mediation sedia ada anda atau melalui integrasi sisi pelayan yang ringan. Rakan terurus mengagregat permintaan daripada berpuluh-puluh sumber pada infrastruktur mereka, dan apl anda hanya melihat satu sumber permintaan. Hasilnya adalah lebih banyak kepelbagaian permintaan dengan kurang beban SDK.
Penerbit paling bijak tidak bertanya "berapa banyak SDK yang boleh saya tambah?" Mereka bertanya "apakah bilangan minimum SDK yang saya perlukan untuk menangkap hasil maksimum?" Jawapannya hampir selalu kurang daripada yang mereka miliki sekarang.
Langkah praktikal untuk mengurangkan SDK yang membengkak
1. Buang SDK yang berprestasi rendah
Jika SDK menjana kurang daripada 5 peratus daripada jumlah hasil iklan anda, pertimbangkan secara serius untuk membuangnya. Kos prestasi berkemungkinan melebihi sumbangan hasil.
2. Gabungkan melalui mediation
Gunakan penyesuai terbina dalam platform mediation anda dan bukannya integrasi SDK yang berdiri sendiri di mana mungkin. Penyesuai mediation lazimnya lebih ringan berbanding integrasi SDK penuh.
3. Manfaatkan bidding sisi pelayan
Pindahkan rakan permintaan yang menyokong bidding sisi pelayan kepada model tersebut. Ini membuang SDK mereka daripada apl anda sambil mengekalkan permintaan mereka dalam waterfall anda.
4. Gunakan rakan terurus untuk permintaan ekor panjang
Daripada mengintegrasikan lima SDK niche untuk permintaan serantau atau khusus, gunakan satu rakan terurus yang mengagregat permintaan tersebut di sisi pelayan.
Mengukur kesan
Selepas mengurangkan bilangan SDK anda, pantau tiga metrik: pengurangan saiz apl, peningkatan masa permulaan, dan jumlah hasil iklan. Pengurangan SDK yang dilaksanakan dengan baik seharusnya menunjukkan peningkatan yang ketara dalam dua yang pertama tanpa perubahan signifikan dalam yang ketiga — atau bahkan peningkatan — kerana saiz apl yang berkurangan membawa kepada kadar pemasangan yang lebih tinggi dan pengekalan pengguna yang lebih baik.