Vsak ad SDK, ki ga integrirate v svojo aplikacijo, ima skrito ceno. Vsak poveča binary size, podaljša čas cold start, uvede morebitne konflikte združljivosti in ustvari še eno odvisnost, ki jo je treba posodobiti ob izidu novih verzij operacijskega sistema. Za publishers, ki uporabljajo pet, osem ali celo dvanajst SDK-jev, je lahko kumulativni vpliv na zmogljivost aplikacije in uporabniško izkušnjo znaten — in pogosto je neviden, ker se dogaja postopoma.
Dejanski stroški napihnjenosti SDK
Vsak megabajt, dodan k binary size vaše aplikacije, šteje. Raziskave dosledno kažejo, da se stopnje konverzije namestitev merljivo zmanjšajo z vsakim dodatnim megabajtom velikosti prenosa. Na nastajajočih trgih, kjer imajo uporabniki omejeno shranjevanje in počasnejše povezave, je vpliv še bolj izrazit. Publisher, ki doda tri ad SDK-je v skupni velikosti 15 megabajtov, morda izgublja več prihodkov zaradi zmanjšanih namestitev, kot jih pridobi z dodatnim povpraševanjem, ki ga ti SDK-ji zagotavljajo.
Poleg velikosti prenosa SDK-ji porabljajo vire med izvajanjem. Vsak SDK, ki se inicializira ob zagonu aplikacije, podaljša čas zagona. Uporabniki, ki čakajo več kot tri sekunde, da se aplikacija naloži, jo bistveno pogosteje zapustijo. In vsak SDK, ki teče v ozadju, porablja pomnilnik in baterijo — vire, ki jih uporabniki opazijo in za katere trgovine z aplikacijami platform vse pogosteje kaznujejo.
Revizija SDK-jev
Začnite z revizijo vašega trenutnega sklada SDK-jev. Za vsak ad SDK v vaši aplikaciji izmerite tri stvari: binary size, ki ga doda, prihodek, ki ga ustvari, in njegov fill rate. Skoraj zagotovo boste ugotovili, da sta eden ali dva SDK-ja odgovorna za večino vašega prihodka, medtem ko jih več prispeva marginalno, a dodaja znatne režijske stroške.
Pravilo 80/20 velja
V večini aplikacij publishers dva do trije ad SDK-ji ustvarijo 80 odstotkov ali več celotnega prihodka od oglasov. Preostali SDK-ji zapolnjujejo vrzeli, vendar pogosto po ceni, ki presega njihov prispevek, ko upoštevate vpliv na zmogljivost. Cilj ni odpraviti vse SDK-je — temveč najti minimalni nabor, ki zajame največji prihodek.
Rešitve na strežniški strani
Najučinkovitejši način za zmanjšanje števila SDK-jev brez izgube raznolikosti povpraševanja je premik agregacije povpraševanja s strani odjemalca na stran strežnika. Googlova storitev Open Bidding na primer omogoča več partnerjem za povpraševanje, da tekmujejo za vaš inventar, ne da bi zahtevali njihove posamezne SDK-je v vaši aplikaciji. Dobite konkurenčni pritisk več bidders s preprostostjo ene same integracije SDK.
Pristop upravljanega povpraševanja
Partner za upravljano povpraševanje ta koncept nadgradi. Namesto da sami integrirate več SDK-jev, integrirate eno samo točko povezave — bodisi prek vaše obstoječe platforme mediation bodisi prek lahke integracije na strežniški strani. Upravljani partner agregira povpraševanje iz deset virov na svoji infrastrukturi, vaša aplikacija pa vidi le en sam vir povpraševanja. Rezultat je več raznolikosti povpraševanja z manj režijskimi stroški SDK-jev.
Najpametnejši publishers ne sprašujejo „koliko SDK-jev lahko dodam?“ Sprašujejo „kakšno je najmanjše število SDK-jev, ki jih potrebujem za zajemanje največjega prihodka?“ Odgovor je skoraj vedno manj, kot jih trenutno imajo.
Praktični koraki za zmanjšanje napihnjenosti SDK
1. Odstranite neučinkovite SDK-je
Če SDK ustvari manj kot 5 odstotkov vašega celotnega prihodka od oglasov, resno razmislite o njegovi odstranitvi. Stroški zmogljivosti verjetno presegajo prispevek k prihodku.
2. Konsolidirajte prek Mediation
Uporabite vgrajene adapterje vaše platforme mediation namesto samostojnih integracij SDK, kjer je to mogoče. Adapterji mediation so običajno lažji od polnih integracij SDK.
3. Izkoristite Bidding na strežniški strani
Premaknite partnerje za povpraševanje, ki podpirajo bidding na strežniški strani, na ta model. S tem odstranite njihov SDK iz vaše aplikacije, hkrati pa ohranite njihovo povpraševanje v vašem waterfall.
4. Uporabite upravljanega partnerja za nišno povpraševanje
Namesto integracije petih nišnih SDK-jev za regionalno ali specializirano povpraševanje uporabite enega upravljanega partnerja, ki agregira to povpraševanje na strežniški strani.
Merjenje vpliva
Po zmanjšanju števila SDK-jev spremljajte tri meritve: zmanjšanje velikosti aplikacije, izboljšanje časa zagona in celotni prihodek od oglasov. Dobro izvedeno zmanjšanje SDK-jev bi moralo pokazati merljive izboljšave pri prvih dveh brez bistvene spremembe — ali celo z izboljšanjem — pri tretji, saj zmanjšana velikost aplikacije vodi do višjih stopenj namestitve in boljšega zadrževanja uporabnikov.