Mobiel maakt 70 % van het verkeer en 45 % van de verkopen: het gat zit volledig in de checkout
Op de mid-market PrestaShop-webshops die wij in 2026 instrumenteren, is mobiel gemiddeld goed voor 71 % van het verkeer en 44 % van de omzet. Het gat van 27 punten is bijna volledig te verklaren door de mobiele conversieratio, die de helft lager ligt dan op desktop (gemiddeld 1,2 % tegen 2,6 %). En dat verschil komt niet door de koopintentie, want de toevoegpercentages aan de winkelwagen zijn gelijkwaardig, maar door de frictie in de checkout.
Drie precieze fricties doden de mobiele conversie:
- Het toevoegen aan de winkelwagen dat een scroll omhoog afdwingt op lange productpagina’s: de gebruiker heeft onderaan de kenmerken uitgelezen, maar de koopknop staat helemaal bovenaan, buiten het viewport.
- De adresinvoer in de checkout: Prinsengracht 263, 1016 GV Amsterdam intikken op een mobiel toetsenbord kost 45 seconden en levert gemiddeld 2 tot 3 fouten op.
- De invoer van het internationale telefoonnummer: bij verkopers met meerdere landen laat de vraag om +31 6 12 34 56 78 in te tikken een Duitse klant twijfelen tussen 0049 en +49, en dat doet 8 tot 12 % van de winkelwagens in afhaken kantelen.
Deze drie fricties staan los van elkaar maar stapelen zich op. Ze tegelijk corrigeren verdubbelt het effect: het is geen optimalisatie van 2 of 3 punten meer, maar typisch een winst van 6 tot 11 punten mobiele conversie. Dit artikel behandelt de mechaniek van elke hefboom en de implementatievalkuilen.
Hefboom 1: de sticky koopknop op mobiel
Waarom de sticky cart werkt
Een goed gemaakte mobiele productpagina meet 2 500 tot 4 000 pixels hoogte (titel, prijs, hoofdafbeelding, variantenkiezer, beschrijving, FAQ, reviews, vergelijkbare producten). De koopknop zit in het bovenste deel, rond 600-800 px. Wanneer de gebruiker scrolt om de details te lezen, verdwijnt de knop uit het viewport. Om te kopen moet hij terugscrollen, een gebaar dat het lezen onderbreekt en fysiek het signaal geeft dat hij daar niet hoort te zijn.
De sticky cart lost dat op door permanent een koopknop (of een expresbetaalknop) te tonen in de onderste zone van het mobiele scherm, binnen duimbereik. Het is de balk die u ziet bij Amazon, ASOS, Sephora en elke serieuze mobile-first webshop.
Anatomie van een goed ontworpen sticky cart
Een effectieve sticky cart bevat:
- Een miniatuur van het product (40×40 px), die eraan herinnert wat men aan het kopen is.
- De stukprijs (en de doorgestreepte prijs bij een actie).
- De aantalkiezer (met plus- en minknoppen die met de duim bedienbaar zijn).
- Een koopknop van minstens 48 px hoog (de aanbevolen aanraakdoelgrootte op Android en iOS).
- Optioneel maar krachtig: een expresbetaalknop (Apple Pay of Google Pay) rechtstreeks in de balk, die de tussenliggende winkelwagen overslaat.
De expresbetaalknop in de sticky is de hefboom die de conversie doet kantelen: hij verandert een traject van 4 schermen (productpagina, winkelwagen, checkout, bevestiging) in 2 schermen (productpagina, bevestiging). Zie ons artikel over expresbetaling in 2026.
De drie valkuilen van de sticky cart
1. Te vroeg verschijnen. Een sticky die al bij het laden van de mobiele pagina verschijnt, bedekt de hoofdfoto en komt opdringerig over. De regel: verschijnen na 200-400 px scroll, wanneer de native koopknop uit het viewport verdwijnt. Een slide-up-animatie van 200 ms voor de visuele zachtheid.
2. Stapeling met het vaste hamburgermenu. Heeft de webshop al een vaste header bovenaan, dan eet de sticky cart onderaan viewport op. Op iPhone SE- en Mini-schermen (effectief 320×568) blijft er 400 px zichtbare inhoud over, te weinig om comfortabel te lezen. De oplossing: geen sticky header op mobiel (de hamburger blijft bereikbaar via een swipegebaar), alleen de sticky cart onderaan.
3. Conflict met het virtuele toetsenbord. Op het moment dat de gebruiker het aantal intikt in een tekstveld van de sticky cart, schuift het iOS- of Android-toetsenbord omhoog en bedekt het de knop. De oplossing: plus- en minknoppen in plaats van tekstvelden, of visualViewport.height detecteren en de sticky aanpassen.
Implementatie op PrestaShop
De sticky add-to-cart-module voor PrestaShop injecteert de balk via de hook displayFooterProduct, met CSS position: fixed; bottom: 0 en een zichtbaarheidstrigger op de scroll. De balk is native responsive (verborgen op desktop vanaf 768 px), compatibel met varianten (prijsupdate bij het wisselen van variant) en per productcategorie uitschakelbaar (nuttig voor configuratiezware producten zoals maatwerkkeukens).
Het gemeten effect: +12 tot +18 % mobiele conversie op lange productpagina’s (mode, elektronica, beauty), neutraal tot licht negatief op korte pagina’s (boeken, eenvoudige accessoires). Per categorie in te stellen naar het productprofiel.
Hefboom 2: adresautocomplete in de checkout
De verborgen kosten van handmatige invoer
Op PrestaShop vraagt het standaardadresformulier 5 tot 7 velden: huisnummer, straat (optioneel 3 regels), postcode, plaats, land, toevoeging. Op mobiel triggert elk veld een toetsenbordanimatie, invoerfouten (autocorrectie die straatnamen herschrijft) en een hoog risico op een typefout in de postcode of de plaatsnaam.
Het meetbare resultaat: 14 tot 22 % afhaken specifiek op het adresformulier, het eerste valpunt van de funnel na de accountcreatie. En 4 tot 8 % van de afgeronde bestellingen draagt een fout adres, wat een mislukte levering, een retour of een creditnota oplevert.
Hoe de autocomplete van Google Places werkt
De gebruiker begint zijn adres te typen. Vanaf 3 tekens gaat er een verzoek naar de Google Places Autocomplete-API, die een lijst gestructureerde voorstellen teruggeeft. De gebruiker kiest het juiste, en de API stuurt het volledige adres terug in genormaliseerde componenten: huisnummer, straat, postcode, plaats, land. Die componenten worden automatisch op de formuliervelden gemapt.
Drie onmiddellijke voordelen:
- Invoer in 5 tot 8 seconden in plaats van 45 tot 60 seconden.
- Geen typefout mogelijk (het adres is door Google gevalideerd).
- Standaardisering: eenzelfde straatnaam wordt altijd hetzelfde geschreven, wat de logistiek (clusters van bezorgrondes) en de BI-rapportage vergemakkelijkt.
De rekenkunde van de Google Places API-kosten
Google Places factureert sinds 2018 per gebruik:
- Autocomplete (per sessie): 0,017 $ per sessie, ongeveer 0,015 €.
- Place Details (per verzoek): 0,017 $ per lookup.
- Gratis quotum: 200 $ per maand aan Google Maps Platform-krediet (sinds 2024, let op, het beweegt).
Op een webshop met 5 000 bestellingen per maand is dat ongeveer 100 € aan API-kosten. Het rendement is onmiddellijk: 1 % conversie terugwinnen op 5 000 bestellingen met een gemiddelde orderwaarde van 80 € is +4 000 € omzet per maand. Verhouding: 1 op 40.
Voor zeer grote webshops bestaan alternatieven: Mapbox Search, HERE Maps, OpenStreetMap Photon (gratis maar met wisselende kwaliteit per gebied). De praktische regel: Google Places in de Benelux en de EU voor de kwaliteit, Mapbox in de VS, Photon voor webshops met een zeer klein budget die een lagere dekking aanvaarden.
De implementatievalkuilen
1. De valkuil van het veld adrestoevoeging. Google Places geeft de toevoeging niet terug (verdieping, gebouw B, intercomcode). Houd een vrij tekstveld na de selectie, maar maak het niet verplicht (de meeste adressen hebben er geen).
2. Slecht geïndexeerde buitengebieden. Google Places dekt stedelijke adressen goed, buitengebieden en recente huisnummertoevoegingen minder. Bied altijd een terugvaloptie handmatig invoeren aan, met een discrete link.
3. De afbakening per land. De autocomplete beperken tot het gekozen land via componentRestrictions: { country: 'nl' } verbetert de relevantie drastisch. Vergeet niet de afbakening te wisselen wanneer de gebruiker het leverland verandert.
4. Het sessiebeheer. Google factureert per sessie, niet per verzoek. Een sessie start bij de eerste Autocomplete-aanroep en eindigt bij een Place Details-aanroep, binnen maximaal enkele minuten. Het session token goed beheren deelt de kosten door 10.
De Address Lookup-module voor PrestaShop behandelt deze vier valkuilen native, met configuratie per land, handmatige terugvaloptie en een correct beheerd session token om de API-kosten te minimaliseren.
Hefboom 3: de internationale landcode (E.164)
Waarom het telefoonnummer internationale bezoekers wegjaagt
Op een Nederlandse webshop aanvaardt het telefoonveld standaard 06 12 34 56 78. Dat is leesbaar voor een Nederlander. Het is onbegrijpelijk voor een Duitse klant die niet weet of hij zijn lokale nummer moet intikken (0151 2345678), met de Duitse landcode (+49 151 2345678), of 0049 moet proberen. De impliciete regel is cultureel: een Nederlandse webshop verwacht Nederlands.
Het gemeten gevolg op PrestaShop-webshops met meerdere landen: 8 tot 14 % afhaken specifiek op het telefoonveld bij buitenlandse bezoekers, en 3 tot 5 % onjuist ingevoerde nummers (zonder landcode, verkeerd voorafgegaan). Die onjuiste nummers laten de leverings-sms’en ontsporen: PostNL, DPD en bpost sturen sms’en naar het ingevoerde nummer, en een Duits nummer met een verkeerde prefix is onbruikbaar.
De oplossing: de E.164-standaard
E.164 is de ITU-T-standaard die het universele formaat van internationale telefoonnummers vastlegt: +{landcode}{lokaal nummer}, zonder spaties, maximaal 15 cijfers. Voor Nederland: +31612345678. Voor België: +32470123456. Voor de Verenigde Staten: +12025550123.
Een internationale landcodekiezer toont een klikbare vlag plus de landcode, en de gebruiker tikt alleen zijn lokale nummer in. Het E.164-formaat wordt automatisch opgebouwd. Het is de ervaring die u kent van WhatsApp, Telegram en de meeste moderne mobiele apps.
De vier eisen aan een professionele E.164-kiezer
1. Automatische voorselectie. De beginvlag wordt afgeleid van het gekozen leverland, of van het gelokaliseerde IP als er nog geen land is gekozen. De gebruiker hoeft niet door een lijst van 240 landen te scrollen.
2. Realtimevalidatie op nationale regels. Een Nederlands mobiel nummer begint met 06, een vast nummer met een netnummer als 010 of 020. Een Belgisch mobiel nummer begint met 4 na de landcode. Strikte validatie per land met regels blokkeert invoerfouten onmiddellijk. De referentiebibliotheek is libphonenumber van Google, die alle landen met hun regels dekt.
3. Genormaliseerde opslag in de database. Het nummer in ps_address.phone of ps_address.phone_mobile staat altijd in E.164-formaat +31612345678. De weergave mag het bij het lezen herformatteren (+31 6 12 34 56 78), maar de opslag is genormaliseerd. Dat vergemakkelijkt CSV-exports, CRM-integraties en sms-verzendingen.
4. AVG-conform. Het telefoonnummer is een persoonsgegeven. De kiezer moet de rechten op inzage, wijziging en verwijdering respecteren, net als de andere velden.
Bijkomend voordeel: de betrouwbaarheid van de sms
Voor webshops die sms’en versturen (leveringsmeldingen, 2FA-codes, actiemeldingen) garandeert E.164 de bezorging. Zonder dat moet het nummer 06 12 34 56 78 bij elke verzending worden genormaliseerd, een bewerking die naargelang het land in 3 tot 8 % van de gevallen mislukt. Met E.164 in de database vertrekt de sms altijd naar het juiste nummer.
Implementatie op PrestaShop
De module Internationale Telefooncode PrestaShop E.164 vervangt de velden phone en phone_mobile van het adresformulier door een component met vlag, landcode en lokaal nummer, gebaseerd op libphonenumber.js. Hij haakt via hooks aan op de adresformulieren in de front-office (aanmaken, wijzigen) en de back-office (orderinvoer). Meertalig, multishop, met validatie aan serverzijde bovenop de clientzijde.
Het gestapelde effect van de drie hefbomen
Op een PrestaShop-webshop met 70 % mobiel verkeer en 12 000 sessies per maand:
| Optimalisatie | Winst mobiele conversie | Omzetwinst per maand (orderwaarde 80 €) |
|---|---|---|
| Nulmeting | 1,2 % | – |
| + Sticky add-to-cart | 1,4 % | + 1 920 € |
| + Adresautocomplete | 1,55 % | + 3 360 € |
| + E.164-landcode (multi-land) | 1,65 % | + 4 320 € |
| Totaal gestapeld | 1,65 % | + 4 320 € per maand |
De winst stapelt maar is niet lineair: elke hefboom corrigeert een ander frictiepunt, en de marginale opbrengst van de derde hangt af van het verkeersprofiel. Op een webshop die alleen in Nederland verkoopt, heeft E.164 weinig effect; op een webshop met 30 % EU-verkeer brengt E.164 evenveel op als de twee andere samen.
Compatibiliteit met de rest van de mobiele stack
Met expresbetaling
Sticky cart plus expresbetaling is de winnende combinatie. De Apple Pay- of Google Pay-knop in de sticky maakt een traject van 2 tikken mogelijk: tik op Apple Pay, Face ID-biometrie, bevestiging. De adresautocomplete komt er niet eens aan te pas, omdat het adres uit de Wallet komt. Zie ons artikel over expresbetaling in 2026.
Met de magic link
Voor geïdentificeerde klanten elimineert de magic link de login. Het bezorgadres staat al in de database, dus de autocomplete is een bonus. De combinatie magic link, expresbetaling en sticky cart is de kortst mogelijke mobiele checkout in 2026.
Met de gratis-verzendbalk
De gratis-verzendbalk kan in de sticky cart worden geïntegreerd: nog 22 € tot gratis verzending. Dubbel voordeel: permanente zichtbaarheid van de drempel plus een prikkel om rechtstreeks vanuit de sticky toe te voegen.
Veelgestelde vragen
Vervuilt de sticky add-to-cart de desktopervaring?
Nee, op voorwaarde dat hij verborgen is op viewports vanaf 768 px (tablet landscape en desktop). Op desktop is de koopknop doorgaans zichtbaar in het initiële viewport zonder scrollen, dus heeft de sticky geen nut.
Is de adresautocomplete compatibel met de one-page checkout van PrestaShop?
Ja. De module haakt aan op de formuliervelden na hun creatie (event DOMContentLoaded of een MutationObserver voor dynamisch geïnjecteerde formulieren). Compatibel met de native checkout van PrestaShop 8 en 9 en met de meeste maatwerkcheckoutmodules.
Wat als Google Places een geldig adres weigert?
Dat gebeurt bij 2 tot 4 % van de adressen (nieuwbouw, recente adressen die nog niet zijn geïndexeerd). Bied altijd een link handmatig invoeren aan die de native PrestaShop-velden vrijgeeft. De standaardervaring: 95 % van de gebruikers gaat via de autocomplete, 5 % handmatig, ruim voldoende om de conversiewinst binnen te halen.
Werkt de E.164-kiezer voor vaste nummers?
Ja. libphonenumber onderscheidt mobiele en vaste nummers per land en valideert beide. Op PrestaShop aanvaardt het veld phone van het adres beide; het veld phone_mobile kan via de configuratie tot mobiele nummers worden beperkt.
Wat is het rendement van de autocomplete op een webshop met één land?
Op een webshop die één land bedient, levert de adresautocomplete typisch +2 tot +4 punten checkoutconversie op (tegen +3 tot +6 bij multi-land). Het rendement is positief vanaf enkele honderden bestellingen per maand, omdat de API-kosten (100 € voor 5 000 bestellingen) ruim onder de winst blijven.
Samengevat
De mobiele conversie win je in 2026 niet met één hefboom, maar door de fricties één voor één weg te nemen, daar waar ze klanten kosten. Sticky add-to-cart, adresautocomplete en de E.164-landcode zijn de drie meest meetbare, met een gestapeld effect van typisch +35 tot +50 % op de mobiele conversie en een terugverdientijd van 30 tot 60 dagen op de module-investering.
De aanbevolen mobiele stack 2026 op PrestaShop combineert drie complementaire modules: de sticky add-to-cart, de adresautocomplete en de E.164-kiezer. Alle drie zijn native responsive, multishop, meertalig en compatibel met PrestaShop 8 en 9.
Wilt u verder gaan, dan blijft de Core Web Vitals-optimalisatie de fundamentele laag van mobiel (LCP, INP, CLS), en maakt server-side tracking voor GA4 het mogelijk het conversieverschil betrouwbaar te meten, daar waar third-party cookies en iOS 17 een deel van de browsersignalen wissen.
