Google Play Store listing experiments: A/B-testen van je screenshots (2026)

Op Google Play hoef je niet te gokken of een nieuwe eerste screenshot beter converteert dan de oude — je kunt het testen op echt Play Store-verkeer. Store Listing Experiments zit ingebouwd in Play Console onder Test and release → Store listing experiments (Google heeft de menulocatie meer dan eens verplaatst; oudere gidsen noemen het "Grow → Store listing experiments"). Het is gratis, draait op je live listing, en regelt de verkeersverdeling en de statistiek voor je.

Als je naar beide winkels uitlevert, is dit het tegenhangende onderdeel van Apple's opzet. We behandelden de iOS-kant in A/B-testen van App Store-screenshots met Product Page Experiments — hetzelfde idee, andere mechanismen. Deze post is het Play-tegenwicht.

Hoe Store Listing Experiments werken

Je maakt een experiment, kiest welk asset je test (app-icoon, screenshots, feature graphic, previewvideo, korte beschrijving of lange beschrijving), en uploadt tot 3 varianten naast je huidige live listing — die als controle fungeert. Google toont de varianten vervolgens aan een deel van de gebruikers die op je store-pagina terechtkomen en meet welke variant meer installaties oplevert.

Twee metrics zijn belangrijk in de resultaten:

• Acquisitie (store listing-conversie). Het aandeel bezoekers dat installeert na het zien van een gegeven variant. Dit is het hoofdcijfer voor screenshot-tests.
• Behouden eerste-keer-installeerders (1-daagse retentie). Of de mensen die een variant heeft aangetrokken, een dag later ook daadwerkelijk zijn gebleven. Een variant die meer installaties trekt maar slechter scoort op retentie, heeft mogelijk te veel beloofd.

Google berekent een betrouwbaarheidsinterval per variant en wijst een variant aan als winnaar zodra die je gekozen betrouwbaarheidsdrempel haalt. Je kunt een e-mailmelding instellen zodat je het dashboard niet in de gaten hoeft te houden. Een winnaar toepassen is één klik — maar meestal wil je het winnende asset alsnog door je normale release-/reviewproces sturen, zodat de rest van je listing consistent blijft.

Standaardgraphics versus gelokaliseerde experimenten

Dit is het onderdeel waar mensen over struikelen, en het bepaalt hoeveel tests je parallel kunt draaien.

• Standaardgraphics-experiment. Test de assets op je standaard store-listing — de listing die wordt getoond aan iedereen die geen gelokaliseerde versie te zien krijgt. Gebruikers die gelokaliseerde assets te zien krijgen, vallen buiten de doelgroep van dit experiment. Je kunt maar één standaardgraphics-experiment tegelijk draaien.
• Gelokaliseerd store listing-experiment. Test assets (en/of tekst) voor een specifieke taal. Je kunt tot 5 gelokaliseerde experimenten tegelijk draaien — bijvoorbeeld één voor Duits, één voor Japans, één voor Braziliaans Portugees, enzovoort, allemaal tegelijk.

In de praktijk: als je installatiebasis geconcentreerd is in een handvol markten, kun je met gelokaliseerde experimenten die markten parallel testen in plaats van te wachten achter één globale test in de wachtrij. En ga er niet vanuit dat een taal gelijkstaat aan een land: "Engels (Verenigde Staten)" selecteren beperkt de doelgroep niet tot de VS — het richt zich op iedereen die die gelokaliseerde listing te zien krijgt, waar dan ook.

Een screenshot-A/B-test opzetten

1. Open Store listing experiments en maak er een aan. Kies de standaardlisting of een specifieke gelokaliseerde listing, en geef het een naam die je over drie weken nog snapt ("Hero-screenshot — benefit-led caption v2").
2. Kies het asset. Selecteer screenshots. Test één element per experiment — verander niet het icoon én de screenshots in dezelfde test, anders weet je niet wat het verschil maakte.
3. Upload tot 3 varianten. Je live listing is de controle. Elke variant is een volledige screenshot-set, in de juiste Play-afmetingen — zie de gids voor Google Play screenshot-afmetingen voor de exacte specs.
4. Stel de doelgroep, betrouwbaarheid en MDE in. Verdeel het verkeer over de varianten (vaak gelijk — 50/50 voor één variant tegenover de controle, of ruwweg een derde per variant bij drie). Kies een betrouwbaarheidsniveau (90%, 95%, 98% of 99%) en een minimaal detecteerbaar effect — de kleinste verbetering die de moeite waard is om te detecteren, instelbaar tussen ongeveer 0,5% en 6%. Play Console toont de voltooiingsvoorwaarden zodat je weet waar je je aan committeert voordat je begint.
5. Start het en laat het met rust. Weersta de neiging om tussentijds te kijken en vroeg te stoppen zodra een variant voorligt. Laat het lopen tot de voorwaarden die je hebt ingesteld.

Steekproefgrootte, duur en significantie bereiken

Het eerlijke antwoord op "hoe lang moet ik het laten draaien?" is: totdat het de significantievoorwaarden bereikt die je hebt ingesteld — niet een vast aantal dagen. Maar er zijn praktische ondergrenzen en bovengrenzen.

• Draai minstens 7 dagen. Installatiegedrag verschilt tussen doordeweekse dagen en weekenden. Alles korter dan een volle week zorgt voor een weekdag-vertekening in je resultaat. Twee weken (14 dagen) is een gangbare, veiligere standaardkeuze, en apps met weinig verkeer hebben vaak 28 dagen nodig.
• Genoeg installaties per variant om ertoe te doen. Significantie is een functie van je installatievolume, het aantal varianten, je betrouwbaarheidsniveau en je MDE. Als ruwe werkdoelstelling: mik op zo'n 1.000+ installaties per variant voordat je de uitkomst vertrouwt — meer als je een hoog betrouwbaarheidsniveau of een klein MDE instelt.
• Strakkere instellingen kosten verkeer. Een betrouwbaarheidsniveau van 99% of een MDE van 0,5% vraagt veel meer installeerders dan 90% / 3%. Als je app weinig volume heeft, bereikt een veeleisende configuratie mogelijk nooit significantie — verruim het MDE of accepteer 90%.

Een test die "niet-conclusief" eindigt is een echte uitkomst, geen mislukking. Het betekent meestal dat de varianten te veel op elkaar leken om ze te onderscheiden bij jouw verkeersniveau, of dat je hem niet lang genoeg hebt laten draaien. Beide zijn op te lossen — maak de varianten duidelijker verschillend, of geef het meer tijd.

De variantenlimiet en wat die betekent

Drie varianten tegenover de controle is het harde maximum per experiment. Dat is een voordeel, geen beperking om tegen te vechten: elke extra variant verdeelt je verkeer dunner en duwt significantie verder weg. Met drie uitdagers verdeel je je store-verkeer al over vier delen (controle + 3). Voor de meeste apps komt één gedurfde, duidelijk-andere uitdager tegenover de controle sneller tot een conclusie dan vier vage variaties ooit zullen doen.

Gebruik de slots voor echt verschillende hypothesen — een ander leidend voordeel, een andere visuele stijl, portret versus een brede multi-paneel-lay-out — niet voor schakeringen van hetzelfde idee.

Valkuilen om te vermijden

• Meer dan één variabele veranderen. Nieuwe screenshots en een nieuwe korte beschrijving in één test = een onbruikbaar resultaat. Isoleer de variabele.
• Vroeg stoppen bij een "winnaar". Vroege voorsprongen zakken vaak weer in. Op dag 3 al beslissen omdat een variant 8% voorstaat, is hoe je vol overtuiging een slechtere listing live zet.
• Draaien onder de 7 dagen. Je vangt dan één deel van de wekelijkse cyclus en mist de rest.
• Te strakke statistiek op een app met weinig verkeer. 99% / MDE van 0,5% eisen bij een bescheiden aantal installaties garandeert een niet-conclusieve, tijdrovende test.
• 1-daagse retentie negeren. Een screenshot die te veel belooft, kan installaties verhogen en de retentie laten kelderen. Houd beide cijfers in de gaten.
• De standaard/gelokaliseerd-splitsing vergeten. Een standaardgraphics-experiment raakt geen gebruikers op gelokaliseerde listings — als je doelgroep grotendeels gelokaliseerd is, test daar dan.
• Alleen ooit de laatste screenshot testen. De eerste 2-3 frames doen het meeste overtuigingswerk op de Play Store. Test die eerst. (Meer over hoe Play verschilt van Apple hier: Play Store vs App Store screenshot-verschillen.)

Waar Mokbi bij past

Mokbi draait de A/B-test niet — dat doet Play Console, en dat is gratis. Wat de meeste teams vertraagt, is om de varianten in de eerste plaats te produceren: een geloofwaardige uitdager betekent een volledige screenshot-set, in de juiste Play-afmetingen, met het bijschrift en de lay-out ook daadwerkelijk aangepast. In Mokbi ontwerp je één set in de browser, dupliceer je die vervolgens en wissel je het openingsbijschrift, de lay-out of de achtergrond om variant B te maken — en vertaal je de bijschriften met één klik als je gelokaliseerde experimenten draait in meerdere markten. Ontwerpen is gratis met een voorbeeld met watermerk; onbeperkt exporteren zonder watermerk en publiceren zit bij een abonnement — Solo voor €29.99/mo (1 app) of Studio voor €49.99/mo (tot 5 apps), geen eenmalige aankoop. Het bouwt de kanshebbers snel; Play Console beslist wie wint.

Verder lezen

• A/B-testen van screenshots met Product Page Experiments — het Apple-tegenwicht
• Play Store vs App Store screenshot-verschillen
• Gids voor Google Play screenshot-afmetingen

Editor openen →