Der er en skjult omkostning ved hvert reklame-SDK, du integrerer i din app. Hvert enkelt øger din binary size, forlænger cold start-tiden, introducerer potentielle kompatibilitetskonflikter og skaber endnu en afhængighed, der skal opdateres, når nye OS-versioner udkommer. For publishers, der kører fem, otte eller endda tolv SDK'er, kan den kumulative påvirkning på app-ydeevne og brugeroplevelse være betydelig — og den er ofte usynlig, fordi den sker gradvist.
Den reelle omkostning ved SDK-bloat
Hver megabyte, der tilføjes til din apps binary, tæller. Forskning viser konsekvent, at installationskonverteringsrater falder mærkbart med hver ekstra megabyte downloadstørrelse. På vækstmarkeder, hvor brugerne har begrænset lagerplads og langsommere forbindelser, er effekten endnu mere udtalt. En publisher, der tilføjer tre reklame-SDK'er med en samlet størrelse på 15 megabyte, kan miste mere revenue fra reducerede installationer, end de tjener fra den inkrementelle demand, som disse SDK'er leverer.
Ud over downloadstørrelsen forbruger SDK'er runtime-ressourcer. Hvert SDK, der initialiseres ved app-start, lægger til din opstartstid. Brugere, der venter mere end tre sekunder på, at en app indlæses, er markant mere tilbøjelige til at forlade den. Og hvert SDK, der kører i baggrunden, bruger hukommelse og batteri — ressourcer, som brugerne bemærker, og som platformenes app-butikker i stigende grad straffer for.
SDK-gennemgangen
Start med at gennemgå din nuværende SDK-stack. For hvert reklame-SDK i din app skal du måle tre ting: den binary size, det tilføjer, den revenue, det genererer, og dets fill rate. Du vil næsten helt sikkert finde, at ét eller to SDK'er er ansvarlige for størstedelen af din revenue, mens flere andre bidrager marginalt, men tilføjer betydelig overhead.
80/20-reglen gælder
I de fleste publisher-apps genererer to til tre reklame-SDK'er 80 procent eller mere af den samlede reklamerevenue. De resterende SDK'er udfylder huller, men ofte til en omkostning, der overstiger deres bidrag, når du medregner ydelsespåvirkningen. Målet er ikke at eliminere alle SDK'er — det er at finde det minimale sæt, der fanger den maksimale revenue.
Serversideløsninger
Den mest effektive måde at reducere SDK-antallet uden at miste demand-diversitet er at flytte demand-aggregeringen fra klientsiden til serversiden. Googles Open Bidding lader f.eks. flere demand-partnere konkurrere om dit inventar uden at kræve deres individuelle SDK'er i din app. Du får det konkurrencemæssige pres fra flere bydere med enkelheden af en enkelt SDK-integration.
Den administrerede demand-tilgang
En administreret demand-partner tager dette koncept videre. I stedet for selv at integrere flere SDK'er integrerer du ét forbindelsespunkt — enten gennem din eksisterende mediation-platform eller via en letvægts-serverside-integration. Den administrerede partner aggregerer demand fra snesevis af kilder på deres infrastruktur, og din app ser kun én demand-kilde. Resultatet er mere demand-diversitet med mindre SDK-overhead.
De klogeste publishers spørger ikke "hvor mange SDK'er kan jeg tilføje?" De spørger: "hvad er det minimale antal SDK'er, jeg har brug for, for at fange maksimal revenue?" Svaret er næsten altid færre, end de aktuelt har.
Praktiske skridt til at reducere SDK-bloat
1. Fjern underpræsterende SDK'er
Hvis et SDK genererer mindre end 5 procent af din samlede reklamerevenue, bør du seriøst overveje at fjerne det. Ydeevneomkostningen overstiger sandsynligvis dets bidrag til revenue.
2. Konsolider gennem mediation
Brug din mediation-platforms indbyggede adaptere i stedet for selvstændige SDK-integrationer, hvor det er muligt. Mediation-adaptere er typisk lettere end fulde SDK-integrationer.
3. Udnyt serverside-bidding
Flyt demand-partnere, der understøtter serverside-bidding, til den model. Det fjerner deres SDK fra din app, mens deres demand bevares i dit waterfall.
4. Brug en administreret partner til long-tail demand
I stedet for at integrere fem niche-SDK'er til regional eller specialiseret demand, kan du bruge en enkelt administreret partner, der aggregerer den demand på serversiden.
Måling af effekten
Efter at have reduceret dit SDK-antal skal du overvåge tre metrikker: reduktion i app-størrelse, forbedring af opstartstid og samlet reklamerevenue. En veludført SDK-reduktion bør vise målbare forbedringer i de to første uden væsentlig ændring — eller endda med forbedring — i den tredje, da en reduceret app-størrelse fører til højere installationsrater og bedre fastholdelse af brugere.