Tətbiqinizə inteqrasiya etdiyiniz hər bir reklam SDK-sının gizli bir qiyməti var. Hər biri binary size-ınıza əlavə edir, cold start vaxtını artırır, potensial uyğunluq konfliktləri yaradır və yeni OS versiyaları çıxanda yenilənməsi lazım olan əlavə bir asılılıq formalaşdırır. Beş, səkkiz və ya hətta on iki SDK işlədən publisher-lər üçün tətbiq performansına və istifadəçi təcrübəsinə kumulyativ təsir əhəmiyyətli ola bilər — və bu, tədricən baş verdiyi üçün çox vaxt görünməzdir.
SDK şişkinliyinin real qiyməti
Tətbiq binary-nızə əlavə olunan hər meqabayt önəmlidir. Araşdırmalar ardıcıl olaraq göstərir ki, hər əlavə meqabayt yükləmə həcmi ilə tətbiq quraşdırma konversiya dərəcələri nəzərəçarpacaq dərəcədə azalır. Məhdud yaddaşa və yavaş əlaqələrə sahib inkişaf etməkdə olan bazarlarda təsir daha da güclüdür. Cəmi 15 meqabayt olan üç reklam SDK-sı əlavə edən publisher, bu SDK-ların təmin etdiyi artımlı demand-dan qazandığından daha çox revenue-nu azalmış quraşdırmalar səbəbindən itirə bilər.
Yükləmə həcmindən əlavə, SDK-lar runtime resursları istehlak edir. Tətbiq işə düşəndə hər bir inisializasiya olunan SDK başlanğıc vaxtınıza əlavə edir. Tətbiqin yüklənməsini üç saniyədən çox gözləyən istifadəçilərin onu tərk etmə ehtimalı əhəmiyyətli dərəcədə yüksəkdir. Və arxa planda işləyən hər SDK yaddaş və batareya istehlak edir — istifadəçilərin fərq etdiyi və platforma tətbiq mağazalarının getdikcə daha çox cəzalandırdığı resurslardır.
SDK auditi
Mövcud SDK yığınınızı audit etməklə başlayın. Tətbiqinizdəki hər bir reklam SDK-sı üçün üç şeyi ölçün: əlavə etdiyi binary size, yaratdığı revenue və fill rate-i. Demək olar ki, mütləq bir və ya iki SDK-nın revenue-nuzun əksəriyyətinə cavabdeh olduğunu, bir neçə başqasının isə marjinal töhfə verdiyini, lakin əhəmiyyətli yük əlavə etdiyini görəcəksiniz.
80/20 qaydası tətbiq olunur
Əksər publisher tətbiqlərində iki-üç reklam SDK-sı ümumi reklam revenue-sunun 80 faizi və ya daha çoxunu yaradır. Qalan SDK-lar boşluqları doldurur, lakin performans təsirini nəzərə aldıqda çox vaxt töhfələrini aşan qiymətlə. Məqsəd bütün SDK-ları aradan qaldırmaq deyil — maksimum revenue-nu ələ keçirən minimum dəsti tapmaqdır.
Server tərəfli həllər
Demand müxtəlifliyini itirmədən SDK sayını azaltmağın ən effektiv yolu demand aqreqasiyasını müştəri tərəfindən server tərəfinə köçürməkdir. Google-un Open Bidding-i, məsələn, çoxsaylı demand partnyorlarının tətbiqinizdə fərdi SDK-larını tələb etmədən inventarınız üçün rəqabət etməsinə imkan verir. Tək SDK inteqrasiyasının sadəliyi ilə çoxsaylı bidder-lərin rəqabət təzyiqini əldə edirsiniz.
İdarə olunan demand yanaşması
İdarə olunan demand partnyoru bu konsepsiyanı daha da irəli aparır. Özünüz bir neçə SDK inteqrasiya etmək əvəzinə, bir əlaqə nöqtəsi inteqrasiya edirsiniz — ya mövcud mediation platformanız vasitəsilə, ya da yüngül server tərəfli inteqrasiya ilə. İdarə olunan partnyorunuz onlarla mənbədən gələn demand-ı öz infrastrukturunda aqreqasiya edir və tətbiqiniz yalnız tək bir demand mənbəyi görür. Nəticə — daha az SDK yükü ilə daha çox demand müxtəlifliyi.
Ən ağıllı publisher-lər "neçə SDK əlavə edə bilərəm?" sualını vermirlər. Onlar soruşurlar: "maksimum revenue-nu ələ keçirmək üçün minimum neçə SDK lazımdır?" Cavab demək olar ki, həmişə hazırda sahib olduqlarından azdır.
SDK şişkinliyini azaltmaq üçün praktiki addımlar
1. Zəif performans göstərən SDK-ları silin
Əgər bir SDK ümumi reklam revenue-sunuzun 5 faizindən azını yaradırsa, onu silməyi ciddi şəkildə nəzərdən keçirin. Performans qiyməti çox güman ki, revenue töhfəsini aşır.
2. Mediation vasitəsilə birləşdirin
Mümkün olduqda müstəqil SDK inteqrasiyaları əvəzinə mediation platformanızın daxili adapterlərindən istifadə edin. Mediation adapterləri adətən tam SDK inteqrasiyalarından daha yüngüldür.
3. Server tərəfli bidding-dən yararlanın
Server tərəfli bidding-i dəstəkləyən demand partnyorlarını bu modelə köçürün. Bu, onların SDK-sını tətbiqinizdən çıxarır, eyni zamanda demand-larını waterfall-ınızda saxlayır.
4. Uzun quyruq demand üçün idarə olunan partnyordan istifadə edin
Regional və ya ixtisaslaşmış demand üçün beş niş SDK inteqrasiya etmək əvəzinə, bu demand-ı server tərəfindən aqreqasiya edən tək bir idarə olunan partnyordan istifadə edin.
Təsirin ölçülməsi
SDK sayınızı azaltdıqdan sonra üç metriki izləyin: tətbiq həcminin azalması, başlanğıc vaxtının yaxşılaşması və ümumi reklam revenue-su. Yaxşı icra edilmiş SDK azaltması ilk ikisində ölçülə bilən yaxşılaşmalar göstərməli, üçüncüsündə isə əhəmiyyətli dəyişiklik olmamalı — və ya hətta yaxşılaşma olmalıdır, çünki azaldılmış tətbiq həcmi daha yüksək quraşdırma dərəcələrinə və daha yaxşı istifadəçi saxlanmasına səbəb olur.