A/B-testen van screenshots met Product Page Experiments

Product Page Experiments (PPE) is geïntroduceerd in iOS 15 en is sindsdien de facto de standaardmanier om App Store-metadata te A/B-testen. Je stelt een controlegroep in plus maximaal drie behandelingsvarianten, verdeelt verkeer, kiest een betrouwbaarheidsniveau, en Apple vertelt je wie gewonnen heeft. De infrastructuur is solide; de discipline in het gebruik ervan niet altijd.

Wat PPE daadwerkelijk meet

PPE meet impressies en conversies op de productpagina zelf. Concreet:

• Impressies: gebruikers die op je productpagina zijn terechtgekomen.
• Conversies: gebruikers die na het bezoek op Koop/Gratis hebben getikt.

PPE meet NIET de doorklikratio vanuit zoekresultaten (of gebruikers je zoekresultaat aantikken om überhaupt op de pagina te komen). Daarvoor zou je de zoekresultaat-preview moeten testen, die de eerste 3 panelen van je standaard-locale gebruikt. PPE kan de volledige carrousel testen, maar meet alleen wat er gebeurt nadat de gebruiker al op de pagina is.

Dit is relevant omdat wijzigingen in panelen 4-10 alleen de conversie op de productpagina beïnvloeden, terwijl wijzigingen in panelen 1-3 zowel de zoekresultaat-doorklikratio als de conversie op de productpagina beïnvloeden. PPE meet het tweede, niet het eerste.

De regel van 'één variabele per keer'

De verleiding is om de hele carrousel te wisselen tussen varianten. Doe dat niet. Als variant A nieuwe bijschriften heeft, een nieuwe devicekanteling én een nieuw kleurpalet, en variant A wint — dan weet je niet welke wijziging de verbetering veroorzaakte. Je kunt de inzichten ook niet goed meenemen naar je volgende test.

Discipline: verander één ding per test. Nieuw bijschrift op paneel 1, al het andere gelijk. Nieuwe achtergrondkleur, bijschriften identiek. Nieuwe paneel-volgorde, inhoud identiek. Langzaam, maar elke test levert een inzicht op waar je op kunt voortbouwen. Snel itereren op ruis is geen vooruitgang.

Steekproefgrootte: het deel dat de meeste teams onderschatten

PPE gebruikt standaard frequentistische hypothesetoetsing. De steekproefgrootte die je nodig hebt, hangt af van:

• Je basisconversieratio (doorgaans 1-5% voor gratis apps, lager voor betaalde).
• Het minimale effect dat je wilt kunnen detecteren (5% relatieve verbetering, 10%, 20%?).
• Je verkeer naar de productpagina.

Als orde van grootte: een verbetering van 10% detecteren op een basisconversieratio van 3% vraagt ~20.000 impressies per variant voor 95% betrouwbaarheid. Als je app 2.000 productpagina-impressies per week krijgt, duurt dat 10 weken per test. De meeste indie-apps hebben niet genoeg verkeer om statistisch zuivere tests te draaien bij kleine effectgroottes. Eerlijke opties:

• Test alleen grote wijzigingen — kleurpalet-wissels, paneel-volgorde, fundamenteel andere bijschrift-toon. Die tests bereiken significantie snel omdat het effect groter is.
• Beperk de verkeerstoewijzing tot één of twee varianten in plaats van drie.
• Accepteer een richtinggevend resultaat in plaats van een significant resultaat. Als een variant consequent wint over 4 weken bij 70% betrouwbaarheid, zet hem dan live en draai een andere test.

Het testontwerp dat werkt

1. Kies één hypothese. "Grotere bijschriften op paneel 1 verbeteren de conversie, omdat miniaturen kleine bijschriften onleesbaar comprimeren." Een specifieke aanname, niet 'laten we kijken wat werkt'.
2. Ontwerp variant A: één wijziging. Dezelfde carrousel, alleen het bijschrift van paneel 1 is aangepast. Al het andere identiek.
3. Wijs 50% toe aan de controle, 50% aan de variant. Tests met twee varianten bereiken significantie sneller dan tests met drie of vier varianten.
4. Stel de testduur van tevoren vast. "We draaien dit 4 weken of totdat we 95% significantie bereiken, wat het eerst komt." Kijk niet tussentijds en stop niet eerder.
5. Documenteer het resultaat. Of het nu gewonnen heeft, verloren, of niet-conclusief was — schrijf het op. Je latere zelf draait dezelfde test zes maanden later als je dat niet doet.

Wat je kunt testen, in volgorde van prioriteit

1. Bijschrift van paneel 1. De grootste impact, omdat paneel 1 zowel zoekminiaturen als de eerste indruk op de productpagina domineert.
2. Paneel-volgorde. Concreet: met welke feature open je?
3. Carrousel-kleurpalet / donker versus licht. Groot effect, snel te testen.
4. Device-kanteling / -oriëntatie. Kleiner effect, maar goedkoop op te zetten.
5. Bijschrift-toon (gebiedend versus beschrijvend). 'Track your runs' versus 'Your runs, tracked'. Kleiner effect, moeilijker om een helder signaal uit te lezen.

Stop met het testen van lettertypes, kleine kleurverschuivingen of de inhoud van panelen 8-10. Die tests bereiken bijna nooit significantie en de onderliggende effecten zijn zo klein dat de winst het testbudget niet waard is.

Lokalisatie in PPE

PPE ondersteunt per-locale varianten. Als je een test draait in je standaard-locale en de winnaar live zet, moet je de wijziging daarna handmatig doorvoeren in elke gelokaliseerde variant van het paneel. Kies een locale met genoeg verkeer om significantie te bereiken (doorgaans en-US) en behandel het resultaat als de globale leidraad voor andere locales. Draai geen 39 losse experimenten.

Veelgemaakte fouten

• Te vroeg stoppen op basis van tussenstanden. Significantie fluctueert willekeurig tijdens een test. Stoppen zodra een variant er goed uitziet, leidt tot verkeerde conclusies. Stel een minimale testduur in en houd je eraan.
• Te veel variabelen testen. Complete herontwerpingen laten zich niet zuiver A/B-testen. Je hebt een aparte test nodig voor het nieuwe ontwerp als geheel (meerdere variabelen, accepteer verstorende factoren) gevolgd door iteratietests met één variabele op de winnaar.
• Testen tijdens seizoensgebonden ruis. Black Friday, App Store featuring en marketingcampagnes voegen alle verkeer én ruis toe. Vermijd testen tijdens deze periodes, tenzij je de piek kunt corrigeren.
• Locale negeren. Een testresultaat uit de VS generaliseert niet altijd naar JP. Gebruik het als startpunt voor een hypothese, niet als vaststaand antwoord.

Wat je deze maand kunt doen

1. Schat je benodigde steekproefgrootte in. Vul je verkeer en basisconversieratio in een calculator voor steekproefgrootte in voordat je de test opzet.
2. Kies één hypothese. Schrijf hem op in één zin.
3. Ontwerp A versus B met één gewijzigde variabele. Zet hem op in App Store Connect.
4. Stel de testduur in en zet de einddatum in je agenda.
5. Documenteer het resultaat, ongeacht de uitkomst.

Verder lezen

• Bijschriften die converteren
• Analyseer een top-100-screenshot

Editor openen →