Katram reklāmas SDK, ko integrējat savā lietotnē, ir slēptas izmaksas. Katrs no tiem palielina binary size, pagarina cold start laiku, rada iespējamus saderības konfliktus un veido vēl vienu atkarību, kas jāatjaunina, kad tiek izlaistas jaunas OS versijas. Izdevējiem, kas izmanto piecus, astoņus vai pat divpadsmit SDK, kumulatīvā ietekme uz lietotnes veiktspēju un lietotāja pieredzi var būt ievērojama — un tā bieži ir neredzama, jo notiek pakāpeniski.
SDK uzpūšanās patiesā cena
Katrs megabaits, kas tiek pievienots jūsu lietotnes binary, ir svarīgs. Pētījumi konsekventi rāda, ka lietotņu instalēšanas konversijas rādītāji manāmi samazinās ar katru papildu lejupielādes apjoma megabaitu. Attīstības tirgos, kur lietotājiem ir ierobežota krātuve un lēnāks savienojums, ietekme ir vēl izteiktāka. Izdevējs, kas pievieno trīs reklāmas SDK ar kopējo apjomu 15 megabaiti, var zaudēt vairāk ieņēmumu no samazinātām instalācijām nekā iegūst no papildu pieprasījuma, ko šie SDK nodrošina.
Papildus lejupielādes apjomam SDK patērē izpildes laika resursus. Katrs SDK, kas inicializējas lietotnes palaišanas laikā, palielina startēšanas laiku. Lietotāji, kas gaida ilgāk par trim sekundēm, līdz lietotne ielādējas, ir ievērojami biežāk gatavi to pamest. Un katrs fonā darbojošais SDK patērē atmiņu un akumulatoru — resursus, ko lietotāji pamana un par ko platformu lietotņu veikali arvien biežāk soda.
SDK audits
Sāciet ar pašreizējā SDK steka auditu. Katram reklāmas SDK jūsu lietotnē izmēriet trīs lietas: binary size, ko tas pievieno, ieņēmumus, ko tas ģenerē, un tā fill rate. Jūs gandrīz noteikti atklāsiet, ka viens vai divi SDK ir atbildīgi par lielāko daļu jūsu ieņēmumu, kamēr vairāki citi sniedz minimālu ieguldījumu, bet rada ievērojamu slodzi.
80/20 likums darbojas
Vairumā izdevēju lietotņu divi līdz trīs reklāmas SDK ģenerē 80 procentus vai vairāk no kopējiem reklāmas ieņēmumiem. Pārējie SDK aizpilda robus, bet bieži par cenu, kas pārsniedz to ieguldījumu, ņemot vērā ietekmi uz veiktspēju. Mērķis nav likvidēt visus SDK — mērķis ir atrast minimālo kopu, kas nodrošina maksimālos ieņēmumus.
Servera puses risinājumi
Visefektīvākais veids, kā samazināt SDK skaitu, nezaudējot pieprasījuma daudzveidību, ir pārcelt pieprasījuma agregāciju no klienta puses uz servera pusi. Piemēram, Google Open Bidding ļauj vairākiem pieprasījuma partneriem sacensties par jūsu inventāru, neprasot to individuālos SDK jūsu lietotnē. Jūs iegūstat vairāku piedāvātāju konkurences spiedienu ar viena SDK integrācijas vienkāršību.
Pārvaldītā pieprasījuma pieeja
Pārvaldītā pieprasījuma partneris šo konceptu attīsta vēl tālāk. Tā vietā, lai paši integrētu vairākus SDK, jūs integrējat vienu savienojuma punktu — caur esošo mediation platformu vai caur vieglu servera puses integrāciju. Pārvaldītais partneris agregē pieprasījumu no desmitiem avotu savā infrastruktūrā, un jūsu lietotne redz tikai vienu pieprasījuma avotu. Rezultāts ir lielāka pieprasījuma daudzveidība ar mazāku SDK slodzi.
Gudrākie izdevēji nejautā „cik SDK es varu pievienot?” Viņi jautā „kāds ir minimālais SDK skaits, kas man nepieciešams, lai nodrošinātu maksimālos ieņēmumus?” Atbilde gandrīz vienmēr ir mazāka nekā viņiem pašlaik ir.
Praktiski soļi SDK uzpūšanās mazināšanai
1. Noņemiet vāji strādājošos SDK
Ja SDK ģenerē mazāk nekā 5 procentus no jūsu kopējiem reklāmas ieņēmumiem, nopietni apsveriet tā noņemšanu. Veiktspējas izmaksas visticamāk pārsniedz ieņēmumu ieguldījumu.
2. Konsolidējiet caur mediation
Izmantojiet savas mediation platformas iebūvētos adapterus atsevišķu SDK integrāciju vietā, kur iespējams. Mediation adapteri parasti ir vieglāki nekā pilnas SDK integrācijas.
3. Izmantojiet servera puses bidding
Pārceliet pieprasījuma partnerus, kas atbalsta servera puses bidding, uz šo modeli. Tas noņem to SDK no jūsu lietotnes, vienlaikus saglabājot to pieprasījumu jūsu waterfall struktūrā.
4. Izmantojiet pārvaldītu partneri garā aste pieprasījumam
Tā vietā, lai integrētu piecus nišas SDK reģionālajam vai specializētajam pieprasījumam, izmantojiet vienu pārvaldītu partneri, kas šo pieprasījumu agregē servera pusē.
Ietekmes mērīšana
Pēc SDK skaita samazināšanas uzraugiet trīs rādītājus: lietotnes apjoma samazinājumu, startēšanas laika uzlabojumu un kopējos reklāmas ieņēmumus. Labi izpildīta SDK samazināšana pirmajos divos rādītājos uzrādīs manāmus uzlabojumus bez būtiskām izmaiņām trešajā — vai pat ar uzlabojumu — jo samazināts lietotnes apjoms nodrošina augstākus instalēšanas rādītājus un labāku lietotāju noturēšanu.