SDK பருமன் உங்கள் செயலியைக் கொல்கிறது: இலகுரக பணமாக்கல் அடுக்கை எவ்வாறு உருவாக்குவது

உங்கள் செயலியில் ஒருங்கிணைக்கும் ஒவ்வொரு ad SDK-க்கும் மறைந்த செலவு உண்டு. ஒவ்வொன்றும் binary size-ஐ அதிகரிக்கிறது, cold start நேரத்தை நீட்டிக்கிறது, இணக்கத்தன்மை முரண்பாடுகளை உருவாக்குகிறது, புதிய OS பதிப்புகளுக்கு புதுப்பிக்க வேண்டிய சார்புநிலையை சேர்க்கிறது. ஐந்து, எட்டு அல்லது பன்னிரெண்டு SDK-களை இயக்கும் publishers-க்கு, செயல்திறன் மற்றும் பயனர் அனுபவத்தில் ஒட்டுமொத்த தாக்கம் குறிப்பிடத்தக்கதாக இருக்கும் — படிப்படியாக நடப்பதால் கண்ணுக்குத் தெரிவதில்லை.

SDK பருமனின் உண்மையான செலவு

உங்கள் செயலியின் binary size-க்கு சேர்க்கப்படும் ஒவ்வொரு மெகாபைட்டும் முக்கியமானது. பதிவிறக்க அளவின் ஒவ்வொரு கூடுதல் மெகாபைட்டிலும் நிறுவல் மாற்ற விகிதங்கள் அளவிடக்கூடிய வகையில் குறைவதை ஆராய்ச்சி தொடர்ச்சியாகக் காட்டுகிறது. பயனர்கள் வரையறுக்கப்பட்ட சேமிப்பகம் மற்றும் மெதுவான இணைப்புகளைக் கொண்டிருக்கும் வளர்ந்து வரும் சந்தைகளில், தாக்கம் இன்னும் அதிகமாக உள்ளது. மொத்தம் 15 மெகாபைட் கொண்ட மூன்று ad SDK-களைச் சேர்க்கும் ஒரு publisher, அந்த SDK-கள் வழங்கும் கூடுதல் தேவையிலிருந்து பெறுவதை விட குறைந்த நிறுவல்களால் அதிக வருவாயை இழக்கக்கூடும்.

பதிவிறக்க அளவுக்கு அப்பால், SDK-கள் இயக்க நேர வளங்களை நுகர்கின்றன. செயலி தொடங்கும்போது துவக்கப்படும் ஒவ்வொரு SDK-யும் உங்கள் தொடக்க நேரத்தை அதிகரிக்கிறது. ஒரு செயலி ஏற்றப்பட மூன்று வினாடிகளுக்கு மேல் காத்திருக்கும் பயனர்கள் அதை கைவிட அதிக வாய்ப்புள்ளது. மேலும் பின்னணியில் இயங்கும் ஒவ்வொரு SDK-யும் நினைவகம் மற்றும் பேட்டரியை நுகர்கிறது — பயனர்கள் கவனிக்கும் மற்றும் தளம் செயலிக் கடைகள் அதிகமாக அபராதம் விதிக்கும் வளங்கள்.

SDK தணிக்கை

உங்கள் தற்போதைய SDK அடுக்கைத் தணிக்கை செய்வதில் தொடங்குங்கள். உங்கள் செயலியில் உள்ள ஒவ்வொரு ad SDK-க்கும், மூன்று விஷயங்களை அளவிடுங்கள்: அது சேர்க்கும் binary size, அது உருவாக்கும் வருவாய், மற்றும் அதன் fill rate. ஒன்று அல்லது இரண்டு SDK-கள் உங்கள் வருவாயின் பெரும்பகுதிக்கு பொறுப்பு என்பதையும், பல மற்றவை குறைந்த அளவில் பங்களிக்கின்றன ஆனால் குறிப்பிடத்தக்க மேல்நிலைச் செலவை சேர்க்கின்றன என்பதையும் நீங்கள் கிட்டத்தட்ட நிச்சயமாகக் கண்டறிவீர்கள்.

80/20 விதி பொருந்தும்

பெரும்பாலான publisher செயலிகளில், இரண்டு முதல் மூன்று ad SDK-கள் மொத்த விளம்பர வருவாயில் 80 சதவிகிதம் அல்லது அதற்கு மேல் உருவாக்குகின்றன. மீதமுள்ள SDK-கள் இடைவெளிகளை நிரப்புகின்றன, ஆனால் செயல்திறன் தாக்கத்தைக் கணக்கில் கொள்ளும்போது அவற்றின் பங்களிப்பை விட அதிக செலவில் இருக்கும். எல்லா SDK-களையும் நீக்குவது குறிக்கோள் அல்ல — அதிகபட்ச வருவாயைப் பிடிக்கும் குறைந்தபட்ச தொகுப்பைக் கண்டறிவதே குறிக்கோள்.

சேவையக பக்க தீர்வுகள்

தேவை பன்முகத்தன்மையை இழக்காமல் SDK எண்ணிக்கையைக் குறைக்க, தேவை ஒருங்கிணைப்பை கிளையன்ட் பக்கத்திலிருந்து சேவையக பக்கத்திற்கு மாற்றுவது சிறந்தது. Google-இன் Open Bidding பல தேவை கூட்டாளர்களை தனிப்பட்ட SDK-கள் இல்லாமல் உங்கள் இன்வெண்டரிக்காக போட்டியிட அனுமதிக்கிறது. ஒற்றை SDK ஒருங்கிணைப்பின் எளிமையுடன் பல bidders-இன் போட்டி அழுத்தத்தைப் பெறுவீர்கள்.

நிர்வகிக்கப்படும் தேவை அணுகுமுறை

நிர்வகிக்கப்படும் தேவை கூட்டாளர் இந்தக் கருத்தை மேலும் முன்னெடுக்கிறார். பல SDK-களை நீங்களே ஒருங்கிணைப்பதற்குப் பதிலாக, ஒரே இணைப்புப் புள்ளியை ஒருங்கிணைக்கிறீர்கள் — உங்கள் தற்போதைய mediation தளம் வழியாக அல்லது இலகுரக சேவையக பக்க ஒருங்கிணைப்பு வழியாக. நிர்வகிக்கப்படும் கூட்டாளர் தனது உள்கட்டமைப்பில் பல்வேறு மூலங்களிலிருந்து தேவையை ஒருங்கிணைக்கிறார், உங்கள் செயலி ஒரே ஒரு தேவை மூலத்தை மட்டுமே பார்க்கிறது. இதன் விளைவாக குறைவான SDK மேல்நிலைச் செலவுடன் அதிக தேவை பன்முகத்தன்மை கிடைக்கிறது.

புத்திசாலியான publishers "எத்தனை SDK-களைச் சேர்க்க முடியும்?" என்று கேட்பதில்லை. அவர்கள் "அதிகபட்ச வருவாயைப் பிடிக்க எனக்குத் தேவையான குறைந்தபட்ச SDK-கள் எண்ணிக்கை என்ன?" என்று கேட்கிறார்கள். பதில் எப்போதும் கிட்டத்தட்ட அவர்களிடம் தற்போது உள்ளதை விடக் குறைவாகவே இருக்கும்.

SDK பருமனைக் குறைப்பதற்கான நடைமுறை நடவடிக்கைகள்

1. செயல்திறன் குறைவான SDK-களை நீக்குங்கள்

ஒரு SDK உங்கள் மொத்த விளம்பர வருவாயில் 5 சதவிகிதத்திற்கும் குறைவாக உருவாக்கினால், அதை நீக்குவதை தீவிரமாகக் கருதுங்கள். செயல்திறன் செலவு வருவாய் பங்களிப்பை விட அதிகமாக இருக்கக்கூடும்.

2. Mediation மூலம் ஒருங்கிணையுங்கள்

முடிந்த இடங்களில் தனித்த SDK ஒருங்கிணைப்புகளுக்குப் பதிலாக உங்கள் mediation தளத்தின் உள்ளமைக்கப்பட்ட அடாப்டர்களைப் பயன்படுத்துங்கள். Mediation அடாப்டர்கள் பொதுவாக முழு SDK ஒருங்கிணைப்புகளை விட இலகுவானவை.

3. சேவையக பக்க Bidding-ஐ பயன்படுத்துங்கள்

சேவையக பக்க bidding-ஐ ஆதரிக்கும் தேவை கூட்டாளர்களை அந்த மாதிரிக்கு மாற்றுங்கள். இது உங்கள் waterfall-இல் அவர்களின் தேவையைப் பராமரிக்கும் அதே நேரத்தில் உங்கள் செயலியிலிருந்து அவர்களின் SDK-ஐ நீக்குகிறது.

4. நீண்ட வால் தேவைக்கு நிர்வகிக்கப்படும் கூட்டாளரைப் பயன்படுத்துங்கள்

பிராந்திய அல்லது சிறப்பு தேவைக்காக ஐந்து நிஷ் SDK-களை ஒருங்கிணைப்பதற்குப் பதிலாக, அந்த தேவையை சேவையக பக்கத்தில் ஒருங்கிணைக்கும் ஒரே நிர்வகிக்கப்படும் கூட்டாளரைப் பயன்படுத்துங்கள்.

தாக்கத்தை அளவிடுதல்

உங்கள் SDK எண்ணிக்கையைக் குறைத்த பிறகு, மூன்று அளவீடுகளைக் கண்காணியுங்கள்: செயலி அளவு குறைப்பு, தொடக்க நேர மேம்பாடு, மற்றும் மொத்த விளம்பர வருவாய். நன்றாக செயல்படுத்தப்பட்ட SDK குறைப்பு முதல் இரண்டிலும் அளவிடக்கூடிய மேம்பாடுகளை மூன்றாவதில் குறிப்பிடத்தக்க மாற்றமின்றி — அல்லது மேம்பாட்டுடன் கூட — காட்ட வேண்டும், ஏனெனில் குறைக்கப்பட்ட செயலி அளவு அதிக நிறுவல் விகிதங்களுக்கும் சிறந்த பயனர் தக்கவைப்புக்கும் வழிவகுக்கிறது.