Checkout-uitval onderzoeken met taken, data en fouten
Een uitgewerkt voorbeeld verbindt een mobiele taaktest, funneldata en betaalgebeurtenissen voordat een checkoutwijziging wordt gepland.
Een verschil tussen gestarte en afgeronde checkouts laat zien waar een onderzoek kan beginnen. Voor een concrete wijziging zijn ook het geobserveerde verloop en passende technische gebeurtenissen nodig. Begin met een kleine vraag: waar loopt een bepaalde aankooptaak op de smartphone vast?
Eerst bepalen wat wordt geteld
Definieer periode, apparaattype en funnelstappen. Vergelijk sessies die volgens dezelfde regels worden geteld; bestellingen en sessies zijn verschillende eenheden. Shopify’s documentatie onderscheidt ook open en gesloten funnels. Een vergelijking past alleen als instroom en stapvolgorde gelijk worden behandeld. Controleer bij een ander meetsysteem ook de definities voordat u een gedragsverandering veronderstelt.
Een uitgewerkt onderzoeksvoorbeeld
Een fictieve webshop voor tekenmateriaal wil deze taak onderzoeken: een tekenmap kiezen, als gast een bezorgadres invoeren, de verzendwijze kiezen en doorgaan naar betaling. Alle cijfers en observaties in de tabel zijn verzonnen; ze tonen hoe verschillende bevindingen kunnen worden samengebracht.
Bron | Fictieve bevinding | Grens van de gevolgtrekking |
|---|---|---|
Gesloten mobiele funnel | 100 sessies bereiken de checkout; 60 ronden die binnen dezelfde observatieperiode af. | Het verschil is zichtbaar, de oorzaak blijft onbekend. |
Na een ongeldige postcode staat de fouttekst buiten het zichtbare schermgedeelte. | Dit is een concreet obstakel in dit proces. | |
Betalingscontrole | Voor deze taak is geen gekoppeld betaalverzoek beschikbaar. | Dit bewijst geen weigering door de bank. |
Controleer eerst of de betaalregistratie de onderzochte transactie volledig weergeeft. Ontbrekende registraties kunnen ook door een onvolledige koppeling komen. Als blijkt dat het formulier stopt voordat een betaalverzoek wordt verstuurd, verhelpt een extra betaalmethode dat formulierprobleem niet.
De taak op het echte apparaat observeren
Laat de taak in een geschikte testomgeving uitvoeren. Noteer apparaat, browser, toetsenbordstatus en de laatste begrijpelijke stap. Kan de persoon herkennen welk veld fout is? Blijven eerder ingevoerde gegevens behouden? Kan het adres worden gecorrigeerd en met de gekozen verzendwijze worden doorgegaan?
De betalingscontrole vult deze observatie aan. Shopify beschrijft bijvoorbeeld fouten door bankbeslissingen, de betaaldienst of webshopinstellingen. Een algemene melding in de interface maakt nog niet duidelijk welk geval speelt. Koppel beschikbare gebeurtenissen aan de betreffende testtransactie in plaats van alle onvoltooide aankopen als betaalfouten te tellen.
Van bevinding naar controleerbare wijziging
Voor het voorbeeld is het volgende ontwerp: het betreffende adresveld is bereikbaar, de fout wordt daar begrijpelijk in tekst beschreven en de overige invoer blijft behouden. W3C legt uit dat een automatisch ontdekte invoerfout moet worden aangeduid en in tekst beschreven. De voorgestelde wijziging is nog geen volledige toegankelijkheidsbeoordeling.
Herhaal na uitvoering dezelfde taak en bekijk vervolgens de ontwikkeling in de gelijk gedefinieerde funnel. Leg ook andere wijzigingen vast, zoals in het aanbod of de verkeersbronnen. Een geslaagde taaktest toont de usability van dit proces; een algemeen omzeteffect is daarmee nog niet aangetoond.
Bronnen
Verder lezen
Alle artikelen
E-commerce met ASES
Webshops, marktplaatsen en B2B-portalen