Svaki ad SDK koji integrirate u svoju aplikaciju nosi skriveni trošak. Svaki povećava veličinu vašeg binaryja, produžuje cold start vrijeme, uvodi potencijalne konflikte kompatibilnosti i stvara još jednu ovisnost koju treba ažurirati kada izađu nove verzije operativnog sustava. Za publishere koji koriste pet, osam ili čak dvanaest SDK-ova, kumulativni utjecaj na performanse aplikacije i korisničko iskustvo može biti značajan — i često je nevidljiv jer se događa postupno.
Stvarna cijena SDK bloata
Svaki megabajt dodan binaryju vaše aplikacije je važan. Istraživanja dosljedno pokazuju da stope konverzije instalacija mjerljivo padaju sa svakim dodatnim megabajtom. Na tržištima u razvoju gdje korisnici imaju ograničenu pohranu i sporije veze, utjecaj je još izraženiji. Publisher koji dodaje tri ad SDK-a ukupne veličine 15 megabajta možda gubi više prihoda od smanjenih instalacija nego što zarađuje od inkrementalnog demanda koji ti SDK-ovi pružaju.
Osim veličine preuzimanja, SDK-ovi troše resurse tijekom izvršavanja. Svaki SDK koji se inicijalizira pri pokretanju aplikacije dodaje na vaše vrijeme pokretanja. Korisnici koji čekaju više od tri sekunde da se aplikacija učita značajno će je vjerojatnije napustiti. A svaki SDK koji radi u pozadini troši memoriju i bateriju — resurse koje korisnici primjećuju i koje trgovine aplikacija sve više kažnjavaju.
SDK audit
Započnite auditom svog trenutnog SDK stacka. Za svaki ad SDK u vašoj aplikaciji izmjerite tri stvari: veličinu binaryja koju dodaje, revenue koji generira i njegov fill rate. Gotovo sigurno ćete otkriti da su jedan ili dva SDK-a odgovorni za većinu vašeg prihoda, dok ih nekoliko drugih marginalno doprinosi ali dodaje značajan overhead.
Pravilo 80/20 se primjenjuje
U većini publisherskih aplikacija dva do tri ad SDK-a generiraju 80 posto ili više ukupnog ad revenuea. Preostali SDK-ovi popunjavaju praznine, ali često po cijeni koja premašuje njihov doprinos kada se uzme u obzir utjecaj na performanse. Cilj nije eliminirati sve SDK-ove — već pronaći minimalni set koji hvata maksimalni revenue.
Rješenja na strani poslužitelja
Najučinkovitiji način smanjenja broja SDK-ova bez gubitka raznolikosti demanda je prebacivanje agregacije demanda sa strane klijenta na stranu poslužitelja. Googleov Open Bidding, na primjer, omogućuje višestrukim demand partnerima da se natječu za vaš inventar bez potrebe za njihovim pojedinačnim SDK-ovima u vašoj aplikaciji. Dobivate konkurentski pritisak višestrukih ponuđača uz jednostavnost jedne SDK integracije.
Pristup upravljanog demanda
Upravljani demand partner ovaj koncept vodi korak dalje. Umjesto da sami integrirate više SDK-ova, integrirate jednu točku povezivanja — bilo kroz svoju postojeću mediation platformu ili kroz laganu integraciju na strani poslužitelja. Upravljani partner agregira demand iz desetaka izvora na svojoj infrastrukturi, a vaša aplikacija vidi samo jedan izvor demanda. Rezultat je veća raznolikost demanda uz manji SDK overhead.
Najpametniji publisheri ne pitaju "koliko SDK-ova mogu dodati?" Oni pitaju "koji je minimalni broj SDK-ova koji mi treba za maksimalni revenue?" Odgovor je gotovo uvijek manji od onog što trenutno imaju.
Praktični koraci za smanjenje SDK bloata
1. Uklonite SDK-ove koji nedovoljno performiraju
Ako SDK generira manje od 5 posto vašeg ukupnog ad revenuea, ozbiljno razmislite o njegovu uklanjanju. Trošak performansi vjerojatno premašuje doprinos prihodu.
2. Konsolidirajte kroz mediation
Koristite ugrađene adaptere svoje mediation platforme umjesto samostalnih SDK integracija gdje god je moguće. Mediation adapteri su obično lakši od punih SDK integracija.
3. Iskoristite bidding na strani poslužitelja
Prebacite demand partnere koji podržavaju bidding na strani poslužitelja na taj model. To uklanja njihov SDK iz vaše aplikacije dok zadržava njihov demand u vašem waterfallu.
4. Koristite upravljanog partnera za long-tail demand
Umjesto integriranja pet nišnih SDK-ova za regionalni ili specijalizirani demand, koristite jednog upravljanog partnera koji agregira taj demand na strani poslužitelja.
Mjerenje utjecaja
Nakon smanjenja broja SDK-ova, pratite tri metrike: smanjenje veličine aplikacije, poboljšanje vremena pokretanja i ukupni ad revenue. Dobro provedeno smanjenje SDK-ova trebalo bi pokazati mjerljiva poboljšanja u prve dvije bez značajne promjene — ili čak poboljšanja — u trećoj, jer manja veličina aplikacije vodi do viših stopa instalacije i boljeg zadržavanja korisnika.