Кожны рэкламны SDK, які вы інтэгруеце ў свой дадатак, мае схаваны кошт. Кожны з іх павялічвае binary size, падаўжае час cold start, стварае патэнцыяльныя канфлікты сумяшчальнасці і фарміруе яшчэ адну залежнасць, якую трэба абнаўляць пры выхадзе новых версій АС. Для publisher-аў, якія выкарыстоўваюць пяць, восем ці нават дванаццаць SDK, кумулятыўны ўплыў на прадукцыйнасць дадатка і карыстацкі вопыт можа быць значным — і часта гэта нябачна, бо адбываецца паступова.
Сапраўдны кошт раздзімання SDK
Кожны мегабайт, дададзены да binary вашага дадатка, мае значэнне. Даследаванні стабільна паказваюць, што каэфіцыенты канверсіі ўсталёўкі прыкметна зніжаюцца з кожным дадатковым мегабайтам памеру спампоўкі. На рынках, якія развіваюцца, дзе карыстальнікі маюць абмежаваную памяць і павольнае злучэнне, уплыў яшчэ больш выразны. Publisher, які дадае тры рэкламныя SDK агульным аб'ёмам 15 мегабайт, можа губляць больш revenue з-за скарачэння ўсталёвак, чым атрымлівае ад дадатковага попыту, які забяспечваюць гэтыя пакеты.
Акрамя памеру спампоўкі, SDK спажываюць рэсурсы падчас працы. Кожны SDK, які ініцыялізуецца пры запуску дадатка, дадае да часу старту. Карыстальнікі, якія чакаюць больш за тры секунды на загрузку дадатка, значна часцей яго пакідаюць. А кожны SDK, які працуе ў фонавым рэжыме, спажывае памяць і батарэю — рэсурсы, якія карыстальнікі заўважаюць і за якія платформавыя краммы прыкладанняў усё часцей штрафуюць.
Аўдыт SDK
Пачніце з аўдыту вашага бягучага стэку SDK. Для кожнага рэкламнага SDK у вашым дадатку вымерайце тры рэчы: binary size, які ён дадае, revenue, які ён генеруе, і яго fill rate. Вы амаль напэўна выявіце, што адзін ці два SDK адказваюць за большасць вашага revenue, у той час як некалькі іншых уносяць маргінальны ўклад, але дадаюць значную нагрузку.
Правіла 80/20 дзейнічае
У большасці дадаткаў publisher-аў два-тры рэкламныя SDK генеруюць 80 адсоткаў або больш ад агульнага рэкламнага revenue. Астатнія SDK запаўняюць прабелы, але часта каштуюць больш за іх уклад, калі ўлічыць уплыў на прадукцыйнасць. Мэта — не выдаліць усе SDK, а знайсці мінімальны набор, які забяспечвае максімальны revenue.
Рашэнні на баку сервера
Найбольш эфектыўны спосаб скараціць колькасць SDK без страты разнастайнасці попыту — перанесці агрэгацыю попыту з кліенцкага боку на серверны. Open Bidding ад Google, напрыклад, дазваляе некалькім demand-партнёрам канкурыраваць за ваш інвентар без неабходнасці інтэграцыі іх індывідуальных SDK у ваш дадатак. Вы атрымліваеце канкурэнтны ціск ад некалькіх бідэраў з прастатой інтэграцыі аднаго SDK.
Падыход кіраванага попыту
Кіраваны demand-партнёр ідзе далей. Замест інтэграцыі некалькіх SDK самастойна, вы інтэгруеце адну кропку злучэння — альбо праз існуючую mediation-платформу, альбо праз лёгкую серверную інтэграцыю. Кіраваны партнёр агрэгуе попыт ад дзясяткаў крыніц на сваёй інфраструктуры, і ваш дадатак бачыць толькі адну крыніцу demand. Вынік — большая разнастайнасць попыту пры меншай нагрузцы SDK.
Найразумнейшыя publisher-ы не пытаюцца «колькі SDK я магу дадаць?» Яны пытаюцца: «які мінімальны набор SDK мне патрэбны, каб атрымаць максімальны revenue?» Адказ амаль заўсёды — менш, чым яны маюць цяпер.
Практычныя крокі для скарачэння раздзімання SDK
1. Выдаліце SDK са слабай прадукцыйнасцю
Калі SDK генеруе менш за 5 адсоткаў ад агульнага рэкламнага revenue, сур'ёзна разгледзьце яго выдаленне. Кошт прадукцыйнасці, хутчэй за ўсё, перавышае яго ўклад у revenue.
2. Кансалідуйце праз mediation
Выкарыстоўвайце ўбудаваныя адаптары вашай mediation-платформы замест аўтаномных інтэграцый SDK, дзе гэта магчыма. Адаптары mediation звычайна лягчэйшыя за поўныя інтэграцыі SDK.
3. Скарыстайцеся серверным bidding
Пераводзьце demand-партнёраў, якія падтрымліваюць серверны bidding, на гэтую мадэль. Гэта выдаляе іх SDK з вашага дадатка, захоўваючы іх попыт у вашым waterfall.
4. Выкарыстоўвайце кіраванага партнёра для доўгага хваста попыту
Замест інтэграцыі пяці нішавых SDK для рэгіянальнага або спецыялізаванага попыту, выкарыстоўвайце аднаго кіраванага партнёра, які агрэгуе гэты попыт на серверным баку.
Вымярэнне ўплыву
Пасля скарачэння колькасці SDK адсочвайце тры метрыкі: памяншэнне памеру дадатка, паляпшэнне часу старту і агульны рэкламны revenue. Добра выкананае скарачэнне SDK павінна паказаць вымерныя паляпшэнні ў першых двух без значных змен — ці нават з паляпшэннем — у трэцім, паколькі меншы памер дадатка вядзе да больш высокіх каэфіцыентаў усталёўкі і лепшага ўтрымання карыстальнікаў.