De eerste drie regels van je App Store-beschrijving
Niemand leest je hele beschrijving. Mensen lezen de eerste paar regels en tikken dan op meer, of ze haken af. Dat bovenste stukje is het enige deel waarvan je zeker weet dat het gezien wordt — dat maakt het de tekst met de meeste impact op je hele pagina. De meeste beschrijvingen verspillen het aan een bedrijfsnaam en een begroeting.
Dit is een sjabloon voor het deel dat boven de vouw verschijnt, plus het ene verschil tussen App Store en Google Play dat bepaalt hoe je het moet schrijven.
4.000 tekens, en bijna niemand scrolt
Het veld voor de volledige beschrijving is op beide — App Store en Google Play — gelimiteerd tot 4.000 tekens. Dat klinkt als veel ruimte, en dat is het ook — maar het is een valkuil als je het als een essay behandelt. Op beide store-pagina's is de beschrijving standaard ingeklapt. Alleen de openingsregels zijn zichtbaar; de rest zit achter een tik op …meer (App Store) of Meer lezen (Google Play).
Precies hoeveel er boven de vouw zichtbaar is verschilt per toestel, lettergrootte en waar de regeleinden vallen — maar in de praktijk zijn dat de eerste twee of drie regels, ergens binnen de eerste paar honderd tekens. Behandel die opening als de echte advertentietekst en de resterende zo'n 3.800 tekens als de bijlage die de meeste mensen nooit openen. (Op iOS is er ook een apart veld voor promotietekst, tot 170 tekens, dat boven de beschrijving staat en zonder nieuwe build kan worden bijgewerkt — dezelfde regel geldt: maak er een haakje van, geen inleiding.)
De ene asymmetrie die bepaalt hoe je schrijft
Dit is het stuk dat de meeste sjablonen overslaan. App Store en Google Play lezen je beschrijving compleet anders:
- Google Play indexeert de volledige beschrijving. De woorden erin zijn een direct zoekranking-signaal. Keywords die je gebruikt — vooral vroeg, en een paar keer natuurlijk herhaald — bepalen mede bij welke zoekopdrachten je app naar boven komt.
- Apple indexeert de beschrijving helemaal niet. Het zoekalgoritme leest de app-naam, subtitel en het keyword-veld van 100 tekens, niet de beschrijving. Op iOS bestaat de beschrijving voor maar één doel: iemand overtuigen die je pagina al aan het bekijken is om te installeren.
Datzelfde tekstblok heeft dus twee taken, afhankelijk van de store. Op Google Play werkt de eerste regel tegelijk voor een crawler en een shopper. Op de App Store hoeft de eerste regel alleen voor de shopper te werken — dat scheelt, want je kunt de neiging tot keyword-stuffing laten varen en gewoon de meest overtuigende zin schrijven die je kunt bedenken.
Open met het voordeel, niet met de intro
De meest gemaakte fout boven de vouw is openen met wie je bent in plaats van wat de lezer eraan heeft. "Welkom bij Acme. Opgericht in 2019, wij bouwen tools voor…" verspilt de enige regels die iemand leest aan keelschrapen.
Draai het om. De eerste regel noemt het ene resultaat dat je app oplevert, in de woorden van de lezer. De tweede regel onderbouwt dat met bewijs of specifieke details. De derde vertelt concreet wat de app doet. Alles onder de vouw — featurelijsten, onderscheidingen, changelog — kan wachten, want de beslissing wordt meestal al vóór de tik genomen.
Het sjabloon voor boven de vouw
Vul eerst deze drie regels in, schrijf daarna de rest van de 4.000 tekens. Dit werkt voor beide stores; de notities geven aan waar ze verschillen.
Regel 1 — het voordeel.
[Het ene resultaat dat je app iemand oplevert, in gewone taal.] Zet op Google Play je belangrijkste keyword in deze regel. Op de App Store negeer je keywords hier en laat je hem gewoon landen.
Regel 2 — het bewijs.
[Waarom jou geloven — een getal, een beoordeling, een use case, een genoemde doelgroep.] Houd het concreet, geen slogan.
Regel 3 — wat het echt doet.
[De kernactie in één zin, zodat er geen twijfel is over wat ze installeren.] Werk op Google Play hier natuurlijk nog een relevant keyword in.
Een uitgewerkt voorbeeld voor een gewoonte-tracker:
Merk op: geen "Welkom", geen oprichtingsjaar, geen featuredump. Drie regels, allemaal voordeel en bewijs, en de lezer weet precies wat hij krijgt nog vóór de vouw ter sprake komt.
Onder de vouw splitsen de stores weer
Zodra je voorbij de zichtbare regels bent, schrijf je voor de store waar je op zit. Voor Google Play werkt de hoofdtekst nog steeds voor zoekopdrachten — herhaal je belangrijkste termen natuurlijk, dek de zinnen die mensen daadwerkelijk intypen, en houd het leesbaar (keyword-stuffing leest slecht, zowel voor het algoritme als voor de mens). Voor de App Store wordt de hoofdtekst niet geïndexeerd, dus besteed hem volledig aan conversie: een strakke featurelijst, sociaal bewijs, en een reden om je te vertrouwen. Twee versies van hetzelfde verhaal, afgestemd op wie er leest.
Lokaliseer dan zonder het haakje te verliezen
Het addertje bij de aanpak voor boven de vouw is dat een haakje alleen werkt als het de vertaling overleeft. Een letterlijke, machinaal vertaalde eerste regel verliest vaak de kracht die de Engelse versie liet converteren — het voordeel raakt begraven, het bewijs leest onhandig, en je hebt weer een muur van tekst in twaalf markten.
Hier komt Mokbi om de hoek kijken. Het stelt je beschrijving op basis van je echte app op en lokaliseert die naar 50 talen, waarbij de structuur boven de vouw per taal intact blijft — eerst het voordeel, dan het bewijs, dan de actie — zodat het bovenste stukje in elke markt nog steeds leest als advertentietekst en niet als een vertaling van één versie. Je controleert en past de versie per store zelf aan, en neemt de tekst daarna mee naar App Store Connect en Play Console.