Det finns en dold kostnad för varje ad SDK du integrerar i din app. Var och en ökar din binary size, förlänger tiden för cold start, introducerar potentiella kompatibilitetskonflikter och skapar ytterligare ett beroende som behöver uppdateras när nya OS-versioner släpps. För publishers som kör fem, åtta eller till och med tolv SDK:er kan den kumulativa påverkan på appens prestanda och användarupplevelsen vara betydande — och den är ofta osynlig eftersom den sker gradvis.
Den verkliga kostnaden för SDK-överlast
Varje megabyte som läggs till din apps binary size spelar roll. Forskning visar konsekvent att konverteringsgraden för installationer minskar mätbart med varje ytterligare megabyte av nedladdningsstorlek. På framväxande marknader där användare har begränsat lagringsutrymme och långsammare anslutningar är påverkan ännu mer uttalad. En publisher som lägger till tre ad SDK:er på totalt 15 megabyte kan förlora mer intäkter från minskade installationer än de tjänar på den inkrementella efterfrågan som dessa SDK:er ger.
Utöver nedladdningsstorleken förbrukar SDK:er körtidsresurser. Varje SDK som initialiseras vid appstart ökar din starttid. Användare som väntar mer än tre sekunder på att en app ska laddas är betydligt mer benägna att överge den. Och varje SDK som körs i bakgrunden förbrukar minne och batteri — resurser som användare märker och som plattformarnas appbutiker i allt högre grad bestraffar.
SDK-revisionen
Börja med att granska din nuvarande SDK-stapel. För varje ad SDK i din app, mät tre saker: den binary size den lägger till, de intäkter den genererar och dess fill rate. Du kommer nästan säkert att upptäcka att en eller två SDK:er står för merparten av dina intäkter, medan flera andra bidrar marginellt men lägger till betydande overhead.
80/20-regeln gäller
I de flesta publisher-appar genererar två till tre ad SDK:er 80 procent eller mer av de totala annonsintäkterna. De återstående SDK:erna fyller luckor men ofta till en kostnad som överstiger deras bidrag när man räknar in prestandapåverkan. Målet är inte att eliminera alla SDK:er — det är att hitta den minsta uppsättningen som fångar maximala intäkter.
Lösningar på serversidan
Det mest effektiva sättet att minska antalet SDK:er utan att förlora efterfrågemångfald är att flytta efterfrågeaggregeringen från klientsidan till serversidan. Googles Open Bidding låter till exempel flera efterfrågepartners konkurrera om ditt inventarium utan att kräva deras individuella SDK:er i din app. Du får konkurrensstrycket från flera bidders med enkelheten av en enda SDK-integration.
Den hanterade efterfrågeansatsen
En hanterad efterfrågepartner tar detta koncept vidare. Istället för att integrera flera SDK:er själv integrerar du en enda anslutningspunkt — antingen genom din befintliga mediation-plattform eller genom en lättviktig integration på serversidan. Den hanterade partnern aggregerar efterfrågan från dussintals källor på sin infrastruktur, och din app ser bara en enda efterfrågekälla. Resultatet är mer efterfrågemångfald med mindre SDK-overhead.
De smartaste publishers frågar inte "hur många SDK:er kan jag lägga till?" De frågar "vad är det minsta antalet SDK:er jag behöver för att fånga maximala intäkter?" Svaret är nästan alltid färre än de för närvarande har.
Praktiska steg för att minska SDK-överlast
1. Ta bort underpresterande SDK:er
Om en SDK genererar mindre än 5 procent av dina totala annonsintäkter, överväg allvarligt att ta bort den. Prestandakostnaden överstiger sannolikt intäktsbidraget.
2. Konsolidera genom Mediation
Använd din mediation-plattforms inbyggda adaptrar istället för fristående SDK-integrationer där det är möjligt. Mediation-adaptrar är typiskt lättare än fullständiga SDK-integrationer.
3. Utnyttja Bidding på serversidan
Flytta efterfrågepartners som stöder bidding på serversidan till den modellen. Detta tar bort deras SDK från din app samtidigt som deras efterfrågan bibehålls i din waterfall.
4. Använd en hanterad partner för långsvansefterfrågan
Istället för att integrera fem nisch-SDK:er för regional eller specialiserad efterfrågan, använd en enda hanterad partner som aggregerar den efterfrågan på serversidan.
Mätning av påverkan
Efter att ha minskat ditt SDK-antal, övervaka tre mätvärden: minskning av appstorlek, förbättring av starttid och totala annonsintäkter. En välgenomförd SDK-minskning bör visa mätbara förbättringar i de två första utan någon betydande förändring — eller till och med en förbättring — i den tredje, eftersom minskad appstorlek leder till högre installationsgrader och bättre användarretention.