Analyser les abandons au paiement : tâches, données et erreurs

Un écart entre les passages en caisse commencés et terminés indique où lancer une étude. Pour définir une modification concrète, il faut aussi observer le parcours et les événements techniques pertinents. Partez d’une question précise : où une tâche d’achat donnée bloque-t-elle sur smartphone ?

Définir d’abord ce qui est compté

Définissez la période, le type d’appareil et les étapes du tunnel. Comparez des sessions comptées selon les mêmes règles ; commandes et sessions sont des unités différentes. La documentation Shopify distingue aussi tunnels ouverts et fermés. Une comparaison n’est pertinente que si entrées et séquences d’étapes sont traitées de la même manière. Lors d’un changement de mesure, vérifiez les définitions avant de supposer un changement de comportement.

Un exemple d’étude détaillé

Une boutique fictive de fournitures de dessin souhaite examiner cette tâche : choisir un carton à dessins, saisir une adresse de livraison en tant qu’invité, sélectionner l’expédition et poursuivre vers le paiement. Tous les chiffres et observations du tableau sont fictifs ; ils montrent comment rapprocher plusieurs types de constats.

Vérifiez d’abord si les enregistrements de paiement représentent intégralement l’opération examinée. Une entrée manquante peut aussi venir d’un défaut de rapprochement. Si l’on établit que le formulaire bloque avant l’envoi de la requête de paiement, ajouter un moyen de paiement ne corrige pas ce problème de formulaire.

Observer la tâche sur l’appareil réel

Faites réaliser la tâche dans un environnement de test adapté. Notez l’appareil, le navigateur, l’état du clavier et la dernière étape comprise. La personne peut-elle identifier le champ erroné ? Les données déjà saisies sont-elles conservées ? Peut-elle corriger l’adresse puis continuer avec le mode d’expédition choisi ?

L’examen du paiement complète cette observation. Shopify décrit par exemple des erreurs liées à la décision bancaire, au service de paiement ou à la configuration de la boutique. Un message générique à l’écran ne suffit pas à distinguer ces cas. Reliez les événements disponibles à l’opération de test concernée au lieu de compter tous les achats inachevés comme des erreurs de paiement.

Transformer le constat en modification vérifiable

Pour cet exemple, la prochaine conception prévoit un champ d’adresse accessible, une erreur décrite clairement à cet endroit et la conservation des autres saisies. W3C explique qu’une erreur de saisie détectée automatiquement doit être identifiée et décrite par du texte. Cette modification ne constitue pas encore une évaluation complète de l’accessibilité.

Après mise en œuvre, répétez la même tâche puis examinez l’évolution dans le tunnel défini de façon constante. Documentez aussi les autres changements, notamment de l’offre ou des sources de trafic. Un essai réussi démontre l’utilisabilité de ce parcours ; il ne prouve pas encore un effet général sur le chiffre d’affaires.

Sources

• Shopify — Behavior reports

• Shopify — Troubleshooting checkout payment issues

• W3C — Error Identification