Det er en skjult kostnad ved hver reklame-SDK du integrerer i appen din. Hver enkelt øker binary size, forlenger cold start-tiden, introduserer potensielle kompatibilitetskonflikter og skaper nok en avhengighet som må oppdateres når nye OS-versjoner lanseres. For utgivere som kjører fem, åtte eller til og med tolv SDK-er, kan den kumulative effekten på appytelse og brukeropplevelse være betydelig — og den er ofte usynlig fordi den skjer gradvis.
Den reelle kostnaden ved SDK-oppblåsing
Hver megabyte som legges til app-binaryen din, betyr noe. Forskning viser konsekvent at konverteringsrater for appinstallasjoner synker merkbart med hver ekstra megabyte nedlastingsstørrelse. I fremvoksende markeder der brukere har begrenset lagringsplass og tregere tilkoblinger, er effekten enda tydeligere. En utgiver som legger til tre reklame-SDK-er på totalt 15 megabyte kan tape mer inntekt fra reduserte installasjoner enn de tjener fra den ekstra etterspørselen disse SDK-ene gir.
Utover nedlastingsstørrelse bruker SDK-er kjøretidsressurser. Hver SDK som initialiseres ved applanseringen, øker oppstartstiden. Brukere som venter mer enn tre sekunder på at en app skal laste, er betydelig mer tilbøyelige til å forlate den. Og hver SDK som kjører i bakgrunnen, bruker minne og batteri — ressurser som brukere legger merke til og som plattformenes appbutikker i økende grad straffer.
SDK-revisjonen
Start med å revidere den nåværende SDK-stakken din. For hver reklame-SDK i appen din, mål tre ting: binary size den legger til, inntekten den genererer og fill rate. Du vil nesten helt sikkert oppdage at én eller to SDK-er er ansvarlige for mesteparten av inntektene dine, mens flere andre bidrar marginalt, men legger til betydelig overhead.
80/20-regelen gjelder
I de fleste utgiverapper genererer to til tre reklame-SDK-er 80 prosent eller mer av de totale reklameinntektene. De gjenværende SDK-ene fyller hull, men ofte til en kostnad som overstiger bidraget deres når du tar med ytelsespåvirkningen. Målet er ikke å eliminere alle SDK-er — målet er å finne det minimale settet som fanger maksimal inntekt.
Serversideløsninger
Den mest effektive måten å redusere SDK-antallet uten å miste etterspørselsmangfold, er å flytte etterspørselsaggregering fra klientsiden til serversiden. Googles Open Bidding lar for eksempel flere etterspørselspartnere konkurrere om inventaret ditt uten å kreve deres individuelle SDK-er i appen din. Du får konkurransepresset fra flere budgivere med enkelheten til én SDK-integrasjon.
Den forvaltede etterspørselstilnærmingen
En forvaltet etterspørselspartner tar dette konseptet videre. I stedet for å integrere flere SDK-er selv, integrerer du ett tilkoblingspunkt — enten gjennom din eksisterende mediation-plattform eller gjennom en lettvekts serversideintegrasjon. Den forvaltede partneren aggregerer etterspørsel fra titalls kilder på sin infrastruktur, og appen din ser bare én etterspørselskilde. Resultatet er mer etterspørselsmangfold med mindre SDK-overhead.
De smarteste utgiverne spør ikke «hvor mange SDK-er kan jeg legge til?» De spør «hva er det minimale antallet SDK-er jeg trenger for å fange maksimal inntekt?» Svaret er nesten alltid færre enn de har i dag.
Praktiske steg for å redusere SDK-oppblåsing
1. Fjern SDK-er som presterer dårlig
Hvis en SDK genererer mindre enn 5 prosent av de totale reklameinntektene dine, bør du seriøst vurdere å fjerne den. Ytelseskostnaden overstiger sannsynligvis inntektsbidraget.
2. Konsolider gjennom mediation
Bruk mediation-plattformens innebygde adaptere i stedet for frittstående SDK-integrasjoner der det er mulig. Mediation-adaptere er vanligvis lettere enn fulle SDK-integrasjoner.
3. Utnytt serverside-bidding
Flytt etterspørselspartnere som støtter serverside-bidding til den modellen. Dette fjerner deres SDK fra appen din mens etterspørselen deres opprettholdes i waterfall-strukturen din.
4. Bruk en forvaltet partner for long tail-etterspørsel
I stedet for å integrere fem nisje-SDK-er for regional eller spesialisert etterspørsel, bruk én forvaltet partner som aggregerer den etterspørselen på serversiden.
Måle effekten
Etter å ha redusert SDK-antallet, overvåk tre målinger: reduksjon i appstørrelse, forbedring av oppstartstid og totale reklameinntekter. En godt gjennomført SDK-reduksjon bør vise målbare forbedringer i de to første uten vesentlige endringer i den tredje — eller til og med en forbedring — fordi redusert appstørrelse fører til høyere installasjonsrater og bedre brukerretensjon.