Jokaiseen sovellukseesi integroituun ad SDK:hon liittyy piilokustannus. Jokainen SDK kasvattaa binary-kokoa, pidentää cold start -aikaa, tuo mukanaan mahdollisia yhteensopivuusongelmia ja luo uuden riippuvuuden, joka vaatii päivityksen uusien käyttöjärjestelmäversioiden myötä. Julkaisijoille, jotka käyttävät viittä, kahdeksaa tai jopa kahtatoista SDK:ta, kumulatiivinen vaikutus sovelluksen suorituskykyyn ja käyttökokemukseen voi olla merkittävä — ja se on usein näkymätön, koska muutos tapahtuu vähitellen.
SDK-paisumisen todellinen hinta
Jokaisella sovelluksen binary-kokoon lisätyllä megatavulla on merkitystä. Tutkimukset osoittavat johdonmukaisesti, että sovellusasennusten konversioprosentit laskevat mitattavasti jokaisen lisämegatavun myötä. Kehittyvillä markkinoilla, joissa käyttäjillä on rajallinen tallennustila ja hitaammat yhteydet, vaikutus on vielä voimakkaampi. Julkaisija, joka lisää kolme ad SDK:ta yhteensä 15 megatavua, saattaa menettää enemmän tuloja vähentyneiden asennusten vuoksi kuin mitä nuo SDK:t tuovat lisäkysynnällään.
Latauskoon lisäksi SDK:t kuluttavat suoritusaikaisia resursseja. Jokainen sovelluksen käynnistyksen yhteydessä alustettava SDK pidentää käynnistysaikaa. Käyttäjät, jotka joutuvat odottamaan sovelluksen latautumista yli kolme sekuntia, hylkäävät sen huomattavasti todennäköisemmin. Lisäksi jokainen taustalla toimiva SDK kuluttaa muistia ja akkua — resursseja, jotka käyttäjät huomaavat ja joista sovelluskaupat rankaisevat yhä enemmän.
SDK-auditointi
Aloita auditoimalla nykyinen SDK-pinosi. Mittaa jokaisesta sovelluksesi ad SDK:sta kolme asiaa: binary-koko jonka se lisää, sen tuottama revenue ja sen fill rate. Lähes varmasti huomaat, että yksi tai kaksi SDK:ta tuottaa suurimman osan tuloistasi, kun taas useat muut kontribuoivat marginaalisesti mutta lisäävät merkittävää ylikuormaa.
80/20-sääntö pätee
Useimmissa julkaisijasovelluksissa kaksi tai kolme ad SDK:ta tuottaa 80 prosenttia tai enemmän kokonais-ad-revenueta. Loput SDK:t täyttävät aukkoja, mutta usein kustannuksin, joka ylittää niiden kontribuution, kun suorituskykyvaikutus huomioidaan. Tavoitteena ei ole eliminoida kaikkia SDK:ita — vaan löytää minimaalinen joukko, joka tuottaa maksimaalisen revenuen.
Palvelinpuolen ratkaisut
Tehokkain tapa vähentää SDK-määrää menettämättä kysynnän monimuotoisuutta on siirtää kysynnän aggregointi asiakaspuolelta palvelinpuolelle. Googlen Open Bidding esimerkiksi mahdollistaa useiden demand-kumppaneiden kilpailun inventaarista ilman yksittäisten SDK:iden integrointia sovellukseesi. Saat useiden tarjoajien kilpailupaineen yhden SDK-integraation yksinkertaisuudella.
Hallittu kysyntä -lähestymistapa
Hallittu demand-kumppani vie tämän konseptin pidemmälle. Sen sijaan, että integroisit useita SDK:ita itse, integroi yksi yhteyspiste — joko olemassa olevan mediation-alustasi kautta tai kevyen palvelinpuolen integraation kautta. Hallittu kumppani aggregoi kysynnän kymmenistä lähteistä omalla infrastruktuurillaan, ja sovelluksesi näkee vain yhden demand-lähteen. Tuloksena on enemmän kysynnän monimuotoisuutta vähemmällä SDK-ylikuormalla.
Älykkäimmät julkaisijat eivät kysy "kuinka monta SDK:ta voin lisätä?" He kysyvät "mikä on minimaalinen SDK-määrä, jolla saan maksimaaliset tulot?" Vastaus on lähes aina vähemmän kuin heillä tällä hetkellä on.
Käytännön askeleet SDK-paisumisen vähentämiseen
1. Poista alisuoriutuvat SDK:t
Jos SDK tuottaa alle 5 prosenttia kokonais-ad-revenueta, harkitse vakavasti sen poistamista. Suorituskykykustannus ylittää todennäköisesti tuottokontribuution.
2. Konsolidoi mediation-alustan kautta
Käytä mediation-alustasi sisäänrakennettuja adaptereita erillisten SDK-integraatioiden sijaan aina kun mahdollista. Mediation-adapterit ovat tyypillisesti kevyempiä kuin täydet SDK-integraatiot.
3. Hyödynnä palvelinpuolen biddingiä
Siirrä palvelinpuolen biddingiä tukevat demand-kumppanit kyseiseen malliin. Tämä poistaa heidän SDK:nsa sovelluksestasi säilyttäen heidän kysyntänsä waterfallissasi.
4. Käytä hallittua kumppania long-tail-kysynnälle
Sen sijaan, että integroisit viisi niche-SDK:ta alueelliselle tai erikoistuneelle kysynnälle, käytä yhtä hallittua kumppania, joka aggregoi kyseisen kysynnän palvelinpuolella.
Vaikutuksen mittaaminen
SDK-määrän vähentämisen jälkeen seuraa kolmea mittaria: sovelluksen koon pienentymistä, käynnistysajan paranemista ja kokonais-ad-revenueta. Hyvin toteutetun SDK-vähennyksen tulisi osoittaa mitattavia parannuksia kahdessa ensimmäisessä ilman merkittävää muutosta — tai jopa parannusta — kolmannessa, sillä pienempi sovelluskoko johtaa korkeampiin asennusmääriin ja parempaan käyttäjien pysyvyyteen.