Testy Store Listing Experiments w Google Play: testy A/B zrzutów ekranu (2026)
W Google Play nie musisz zgadywać, czy nowy pierwszy zrzut ekranu konwertuje lepiej niż stary — możesz to sprawdzić na prawdziwym ruchu w Play Store. Store Listing Experiments są wbudowane w Play Console w sekcji Testowanie i wydawanie → Store listing experiments (Google przenosił tę pozycję menu więcej niż raz — starsze poradniki nazywają ją „Grow → Store listing experiments”). Są bezpłatne, działają na twoim żywym listingu, a podział ruchu i statystykę obliczają za ciebie.
Jeśli publikujesz w obu sklepach, to odpowiednik konfiguracji Apple. Stronę iOS omówiliśmy w artykule Testy A/B zrzutów ekranu App Store za pomocą Product Page Experiments — ta sama idea, inna mechanika. Ten artykuł jest uzupełnieniem po stronie Play.
Jak działają Store Listing Experiments
Tworzysz eksperyment, wybierasz zasób do testowania (ikona aplikacji, zrzuty ekranu, grafika wyróżniająca, wideo z podglądem, krótki opis lub długi opis) i przesyłasz do 3 wariantów obok aktualnego, żywego listingu — który pełni rolę kontroli. Google serwuje warianty części użytkowników trafiających na stronę twojej aplikacji i mierzy, który generuje więcej instalacji.
W wynikach liczą się dwa wskaźniki:
- Pozyskanie (konwersja listingu sklepu). Odsetek odwiedzających, którzy instalują aplikację po zobaczeniu danego wariantu. To główna liczba dla testów zrzutów ekranu.
- Utrzymani nowi instalujący (retencja 1-dniowa). Czy osoby przyciągnięte przez wariant faktycznie zostały dzień później. Wariant, który przyciąga więcej instalacji, ale ma gorszą retencję, mógł obiecać za dużo.
Google oblicza przedział ufności dla każdego wariantu i, gdy wariant przekroczy wybrany przez ciebie próg ufności, ogłasza go zwycięzcą. Możesz włączyć powiadomienie e-mail, żeby nie musieć doglądać panelu na bieżąco. Zastosowanie zwycięzcy to jedno kliknięcie — ale zwykle nadal warto przeprowadzić zwycięski zasób przez normalny proces wydania/weryfikacji, żeby reszta listingu pozostała spójna.
Grafiki domyślne vs eksperymenty zlokalizowane
To część, o którą ludzie się potykają, i która zmienia liczbę testów, jakie możesz prowadzić równolegle.
- Eksperyment na grafikach domyślnych. Testuje zasoby na twoim domyślnym listingu sklepu — czyli tym pokazywanym każdemu, kto nie otrzymuje wersji zlokalizowanej. Użytkownicy, którym serwowane są zasoby zlokalizowane, są wykluczeni z odbiorców tego eksperymentu. Możesz prowadzić tylko jeden eksperyment na grafikach domyślnych naraz.
- Zlokalizowany eksperyment listingu sklepu. Testuje zasoby (i/lub tekst) dla konkretnego języka. Możesz prowadzić do 5 zlokalizowanych eksperymentów jednocześnie — na przykład jeden dla niemieckiego, jeden dla japońskiego, jeden dla brazylijskiego portugalskiego i tak dalej, wszystkie naraz.
W praktyce: jeśli twoja baza instalacji koncentruje się w kilku rynkach, eksperymenty zlokalizowane pozwalają testować te rynki równolegle zamiast ustawiać je w kolejce za jednym testem globalnym. I nie zakładaj, że język to to samo co kraj — wybranie „angielski (Stany Zjednoczone)” nie ogranicza odbiorców do USA; celuje we wszystkich, którym serwowany jest ten zlokalizowany listing, niezależnie od tego, gdzie się znajdują.
Konfiguracja testu A/B zrzutów ekranu
- Otwórz Store listing experiments i utwórz eksperyment. Wybierz listing domyślny albo konkretny listing zlokalizowany i nadaj mu nazwę, którą zrozumiesz jeszcze za trzy tygodnie („Główny zrzut ekranu — podpis oparty na korzyściach v2”).
- Wybierz zasób. Zaznacz zrzuty ekranu. Testuj jeden element na eksperyment — nie zmieniaj ikony i zrzutów ekranu w tym samym teście, bo nie dowiesz się, co przechyliło wynik.
- Prześlij do 3 wariantów. Twój żywy listing pełni rolę kontroli. Każdy wariant to pełny zestaw zrzutów ekranu, w prawidłowych wymiarach Play — dokładne specyfikacje znajdziesz w przewodniku po rozmiarach zrzutów ekranu Google Play.
- Ustaw odbiorców, ufność i MDE. Przydziel ruch między wariantami (zwykle po równo — 50/50 dla jednego wariantu wobec kontroli, albo mniej więcej po jednej trzeciej dla trzech). Wybierz poziom ufności (90%, 95%, 98% lub 99%) oraz minimalny wykrywalny efekt — najmniejszą poprawę wartą wykrycia, konfigurowalną w zakresie mniej więcej 0,5%–6%. Play Console pokazuje warunki zakończenia, więc widzisz, na co się piszesz, zanim zaczniesz.
- Uruchom go i zostaw w spokoju. Opieraj się pokusie podglądania i wcześniejszego zatrzymania, gdy tylko jakiś wariant wygląda na prowadzący. Pozwól mu dojść do ustalonych przez ciebie warunków.
Wielkość próby, czas trwania i osiąganie istotności
Uczciwa odpowiedź na pytanie „jak długo powinienem to prowadzić?” brzmi: aż osiągnie ustalone przez ciebie warunki istotności — nie przez stałą liczbę dni. Ale istnieją realne dolne i górne granice.
- Prowadź co najmniej 7 dni. Zachowania instalacyjne wahają się między dniami roboczymi a weekendami. Wszystko krótsze niż pełny tydzień wbudowuje w wynik obciążenie zależne od dnia tygodnia. Dwa tygodnie (14 dni) to popularny, bezpieczniejszy domyślny wybór, a aplikacje o niskim ruchu często potrzebują 28 dni.
- Wystarczająca liczba instalacji na wariant, żeby to miało znaczenie. Istotność jest funkcją twojego wolumenu instalacji, liczby wariantów, poziomu ufności i MDE. Jako przybliżony cel roboczy dąż do rzędu 1000+ instalacji na wariant, zanim zaufasz wynikowi — więcej, jeśli ustawisz wysoki poziom ufności lub mały MDE.
- Ostrzejsze ustawienia kosztują ruch. Poziom ufności 99% albo MDE 0,5% potrzebuje znacznie więcej instalujących niż 90% / 3%. Jeśli twoja aplikacja ma niski wolumen, wymagająca konfiguracja może nigdy nie osiągnąć istotności — poluzuj MDE albo zaakceptuj 90%.
Test, który kończy się „bez rozstrzygnięcia”, to prawdziwy wynik, nie porażka. Zwykle oznacza to, że warianty były zbyt podobne, by je rozdzielić przy twoim poziomie ruchu, albo że test trwał za krótko. Oba da się naprawić — spraw, by warianty były bardziej odrębne, albo daj testowi więcej czasu.
Limit wariantów i co z niego wynika
Trzy warianty wobec kontroli to sztywny limit na eksperyment. To zaleta, nie ograniczenie, z którym trzeba walczyć: każdy dodatkowy wariant dzieli twój ruch cieniej i przesuwa istotność dalej w czasie. Przy trzech pretendentach dzielisz już ruch sklepu na cztery części (kontrola + 3). Dla większości aplikacji przetestowanie jednego odważnego, wyraźnie innego pretendenta wobec kontroli prowadzi do wniosku szybciej niż cztery mało wyraziste warianty kiedykolwiek to zrobią.
Wykorzystaj dostępne miejsca na naprawdę różne hipotezy — inną główną korzyść, inny styl wizualny, portret vs szeroki układ wielopanelowy — a nie na odcienie tego samego pomysłu.
Pułapki, których należy unikać
- Zmiana więcej niż jednej zmiennej. Nowe zrzuty ekranu i nowy krótki opis w jednym teście = wynik niemożliwy do zinterpretowania. Wyizoluj zmienną.
- Wczesne zatrzymanie przy „zwycięzcy”. Wczesne prowadzenie się cofa. Ogłoszenie wyniku trzeciego dnia, bo wariant jest w górze o 8%, to sposób na wdrożenie gorszego listingu z pełnym przekonaniem.
- Prowadzenie testu krócej niż 7 dni. Złapiesz jedną część tygodniowego cyklu i przegapisz resztę.
- Zbyt ostre statystyki na aplikacji o niskim ruchu. Wymaganie 99% / MDE 0,5% przy skromnej liczbie instalacji gwarantuje test bez rozstrzygnięcia, kosztowny czasowo.
- Ignorowanie retencji 1-dniowej. Zrzut ekranu, który obiecuje za dużo, może podnieść liczbę instalacji i zaniżyć retencję. Obserwuj obie liczby.
- Zapominanie o podziale na domyślne/zlokalizowane. Eksperyment na grafikach domyślnych nie dotyka użytkowników na listingach zlokalizowanych — jeśli twoi odbiorcy są głównie zlokalizowani, testuj tam.
- Testowanie wyłącznie ostatniego zrzutu ekranu. Pierwsze 2–3 klatki wykonują większość pracy przekonującej w Play Store. Testuj je w pierwszej kolejności. (Więcej o tym, czym Play różni się od Apple, znajdziesz tutaj: Play Store vs App Store — różnice w zrzutach ekranu.)
Gdzie pasuje Mokbi
Mokbi nie prowadzi testu A/B — robi to Play Console, i to bezpłatnie. Większość zespołów spowalnia samo tworzenie wariantów: wiarygodny pretendent to pełny zestaw zrzutów ekranu, w prawidłowych wymiarach Play, z rzeczywiście zmienionym podpisem i układem. W Mokbi projektujesz jeden zestaw w przeglądarce, a potem duplikujesz go i zamieniasz główny podpis, układ lub tło, żeby zrobić wariant B — a jednym kliknięciem tłumaczysz podpisy, jeśli prowadzisz zlokalizowane eksperymenty na wielu rynkach. Projektowanie jest bezpłatne z podglądem ze znakiem wodnym; nieograniczony eksport bez znaku wodnego i publikowanie w sklepie są dostępne w ramach subskrypcji — Solo za €29.99/mo (1 aplikacja) lub Studio za €49.99/mo (do 5 aplikacji), bez zakupu jednorazowego. To narzędzie szybko buduje pretendentów; o tym, który wygra, decyduje Play Console.