Każdy reklamowy SDK, który integrujesz ze swoją aplikacją, niesie ze sobą ukryte koszty. Każdy z nich zwiększa binary size, wydłuża czas cold start, wprowadza potencjalne konflikty kompatybilności i tworzy kolejną zależność wymagającą aktualizacji przy wydaniu nowych wersji systemu operacyjnego. Dla wydawców korzystających z pięciu, ośmiu, a nawet dwunastu SDK skumulowany wpływ na wydajność aplikacji i doświadczenie użytkownika może być znaczący — i często jest niewidoczny, ponieważ zachodzi stopniowo.
Rzeczywisty koszt przerostu SDK
Każdy megabajt dodany do binary aplikacji ma znaczenie. Badania konsekwentnie pokazują, że współczynniki konwersji instalacji aplikacji mierzalnie spadają z każdym dodatkowym megabajtem rozmiaru pobierania. Na rynkach rozwijających się, gdzie użytkownicy mają ograniczoną pamięć i wolniejsze połączenia, wpływ jest jeszcze bardziej wyraźny. Wydawca dodający trzy reklamowe SDK o łącznym rozmiarze 15 megabajtów może tracić więcej przychodów z powodu zmniejszonej liczby instalacji, niż zyskuje z dodatkowego popytu zapewnianego przez te SDK.
Poza rozmiarem pobierania SDK zużywają zasoby w czasie wykonywania. Każdy SDK inicjalizowany przy uruchomieniu aplikacji wydłuża czas startu. Użytkownicy czekający dłużej niż trzy sekundy na załadowanie aplikacji są znacząco bardziej skłonni ją porzucić. A każdy SDK działający w tle zużywa pamięć i baterię — zasoby, które użytkownicy zauważają i za które sklepy z aplikacjami coraz częściej nakładają kary.
Audyt SDK
Zacznij od audytu obecnego stosu SDK. Dla każdego reklamowego SDK w aplikacji zmierz trzy rzeczy: binary size, który dodaje, przychody, które generuje, oraz fill rate. Niemal na pewno odkryjesz, że jeden lub dwa SDK odpowiadają za większość Twoich przychodów, podczas gdy kilka innych wnosi marginalny wkład, ale dodaje znaczące obciążenie.
Zasada 80/20 ma zastosowanie
W większości aplikacji wydawców dwa do trzech reklamowych SDK generuje 80 procent lub więcej całkowitych przychodów z reklam. Pozostałe SDK wypełniają luki, ale często kosztem przewyższającym ich wkład, gdy uwzględni się wpływ na wydajność. Celem nie jest eliminacja wszystkich SDK — celem jest znalezienie minimalnego zestawu, który zapewnia maksymalne przychody.
Rozwiązania po stronie serwera
Najskuteczniejszym sposobem zmniejszenia liczby SDK bez utraty różnorodności popytu jest przeniesienie agregacji popytu ze strony klienta na stronę serwera. Na przykład Google Open Bidding pozwala wielu partnerom popytowym konkurować o Twój inwentarz bez wymagania ich indywidualnych SDK w aplikacji. Zyskujesz presję konkurencyjną wielu oferentów przy prostocie integracji jednego SDK.
Podejście zarządzanego popytu
Partner zarządzanego popytu rozwija tę koncepcję dalej. Zamiast samodzielnie integrować wiele SDK, integrujesz jeden punkt połączenia — poprzez istniejącą platformę mediation lub lekką integrację po stronie serwera. Zarządzany partner agreguje popyt z dziesiątek źródeł na swojej infrastrukturze, a Twoja aplikacja widzi tylko jedno źródło popytu. Rezultatem jest większa różnorodność popytu przy mniejszym obciążeniu SDK.
Najsprytniejsi wydawcy nie pytają „ile SDK mogę dodać?” Pytają „jaka jest minimalna liczba SDK potrzebna do uzyskania maksymalnych przychodów?” Odpowiedź prawie zawsze jest mniejsza niż to, co obecnie posiadają.
Praktyczne kroki w celu zmniejszenia przerostu SDK
1. Usuń słabo działające SDK
Jeśli SDK generuje mniej niż 5 procent całkowitych przychodów z reklam, poważnie rozważ jego usunięcie. Koszt wydajnościowy prawdopodobnie przewyższa wkład w przychody.
2. Konsoliduj przez mediation
Używaj wbudowanych adapterów platformy mediation zamiast samodzielnych integracji SDK, gdzie to możliwe. Adaptery mediation są zazwyczaj lżejsze niż pełne integracje SDK.
3. Wykorzystaj bidding po stronie serwera
Przenieś partnerów popytowych obsługujących bidding po stronie serwera na ten model. To usuwa ich SDK z Twojej aplikacji, zachowując jednocześnie ich popyt w strukturze waterfall.
4. Użyj zarządzanego partnera dla popytu długiego ogona
Zamiast integrować pięć niszowych SDK dla regionalnego lub specjalistycznego popytu, użyj jednego zarządzanego partnera, który agreguje ten popyt po stronie serwera.
Pomiar wpływu
Po zmniejszeniu liczby SDK monitoruj trzy wskaźniki: zmniejszenie rozmiaru aplikacji, poprawę czasu uruchomienia i całkowite przychody z reklam. Dobrze przeprowadzone zmniejszenie SDK powinno wykazać mierzalne poprawy w pierwszych dwóch bez istotnych zmian w trzecim — lub nawet z poprawą — ponieważ zmniejszony rozmiar aplikacji prowadzi do wyższych wskaźników instalacji i lepszej retencji użytkowników.