Minden ad SDK-nak, amelyet az alkalmazásodba integrálsz, van egy rejtett költsége. Mindegyik növeli a binary méreted, hosszabbítja a cold start időt, potenciális kompatibilitási konfliktusokat hoz be, és újabb függőséget hoz létre, amelyet frissíteni kell az új OS verziók megjelenésekor. Azoknak a publishereknek, akik öt, nyolc vagy akár tizenkét SDK-t futtatnak, az alkalmazás teljesítményére és felhasználói élményére gyakorolt kumulatív hatás jelentős lehet — és gyakran láthatatlan, mert fokozatosan történik.
Az SDK bloat valódi költsége
Minden megabájt, amelyet az alkalmazásod binaryjához adsz, számít. A kutatások következetesen azt mutatják, hogy az alkalmazás-telepítési konverziós ráták mérhető módon csökkennek minden további megabájttal. A fejlődő piacokon, ahol a felhasználóknak korlátozott a tárhelyük és lassabbak a kapcsolataik, a hatás még kifejezettebb. Egy publisher, aki három ad SDK-t ad hozzá összesen 15 megabájttal, több bevételt veszíthet a csökkent telepítések miatt, mint amennyit az adott SDK-k által biztosított inkrementális demandból nyer.
A letöltési méret mellett az SDK-k futásidejű erőforrásokat is fogyasztanak. Minden SDK, amely az alkalmazás indításakor inicializálódik, növeli az indulási időt. Azok a felhasználók, akik több mint három másodpercet várnak az alkalmazás betöltésére, szignifikánsan nagyobb valószínűséggel hagyják el azt. És minden háttérben futó SDK memóriát és akkumulátort fogyaszt — olyan erőforrásokat, amelyeket a felhasználók észrevesznek, és amelyekért az alkalmazásboltok egyre inkább büntetnek.
Az SDK audit
Kezdd a jelenlegi SDK stackod auditálásával. Az alkalmazásodban lévő minden ad SDK-ról mérj meg három dolgot: a binary méret, amit hozzáad, a revenue, amit generál, és a fill rate-jét. Szinte biztosan azt fogod találni, hogy egy vagy két SDK felelős a bevételed nagy részéért, míg több másik marginálisan járul hozzá, de jelentős overheadet ad hozzá.
A 80/20-as szabály érvényesül
A legtöbb publisher alkalmazásban két-három ad SDK generálja az összes ad revenue 80 százalékát vagy többet. A fennmaradó SDK-k réseket töltenek be, de gyakran olyan költséggel, amely meghaladja a hozzájárulásukat, ha a teljesítményre gyakorolt hatást is figyelembe vesszük. A cél nem az összes SDK eliminálása — hanem a minimális halmaz megtalálása, amely a maximális revenue-t fedi le.
Szerveroldali megoldások
Az SDK-k számának csökkentésére a leghatékonyabb módszer a demand diverzitás elvesztése nélkül a demand aggregáció áthelyezése a kliensoldalról a szerveroldalra. A Google Open Bidding például lehetővé teszi, hogy több demand partner versenyezzen az inventáryadért anélkül, hogy az egyedi SDK-jaikat az alkalmazásodba kellene integrálni. Megkapod több licitáló versenynyomását egyetlen SDK integráció egyszerűségével.
A menedzselt demand megközelítés
Egy menedzselt demand partner ezt a koncepciót tovább viszi. Ahelyett, hogy magad integrálnál több SDK-t, egyetlen csatlakozási pontot integrálsz — akár a meglévő mediation platformodon keresztül, akár egy könnyű szerveroldali integráción keresztül. A menedzselt partner tucatnyi forrásból aggregálja a demandot a saját infrastruktúráján, és az alkalmazásod csak egyetlen demand forrást lát. Az eredmény több demand diverzitás kevesebb SDK overheaddel.
A legokosabb publisherek nem azt kérdezik, hogy "hány SDK-t adhatok hozzá?" Azt kérdezik, hogy "mi a minimális SDK szám, amivel a maximális revenue-t fedhetem le?" A válasz szinte mindig kevesebb, mint amennyit jelenleg használnak.
Gyakorlati lépések az SDK bloat csökkentésére
1. Távolítsd el az alulteljesítő SDK-kat
Ha egy SDK a teljes ad revenue-d kevesebb mint 5 százalékát generálja, komolyan fontold meg az eltávolítását. A teljesítményköltség valószínűleg meghaladja a bevételi hozzájárulást.
2. Konszolidálj mediation-ön keresztül
Használd a mediation platformod beépített adaptereit önálló SDK integrációk helyett, ahol csak lehetséges. A mediation adapterek jellemzően könnyebbek, mint a teljes SDK integrációk.
3. Használd ki a szerveroldali biddinget
Helyezd át a szerveroldali biddinget támogató demand partnereket erre a modellre. Ez eltávolítja az SDK-jukat az alkalmazásodból, miközben a demandjukat megtartja a waterfallodban.
4. Használj menedzselt partnert a long-tail demandhoz
Ahelyett, hogy öt niche SDK-t integrálnál regionális vagy specializált demandhoz, használj egyetlen menedzselt partnert, aki ezt a demandot szerveroldalon aggregálja.
A hatás mérése
Az SDK-k számának csökkentése után figyelj három metrikát: az alkalmazásméret csökkenését, az indulási idő javulását és a teljes ad revenue-t. Egy jól végrehajtott SDK csökkentésnek mérhető javulásokat kell mutatnia az első kettőben, jelentős változás nélkül — vagy akár javulással — a harmadikban, mivel a kisebb alkalmazásméret magasabb telepítési arányokhoz és jobb felhasználói megtartáshoz vezet.