Investigar abandonos del checkout con tareas, mediciones y errores
Un caso desarrollado relaciona una prueba de tarea en móvil, datos del embudo y eventos de pago antes de planificar cambios en el checkout.
La diferencia entre procesos de compra iniciados y completados indica dónde comenzar una investigación. Para definir un cambio concreto también hacen falta el recorrido observado y los eventos técnicos pertinentes. Empiece con una pregunta acotada: ¿en qué punto se atasca una tarea de compra determinada en el móvil?
Definir primero qué se cuenta
Defina el periodo, el tipo de dispositivo y los pasos del embudo. Compare sesiones contadas con las mismas reglas; pedidos y sesiones son unidades diferentes. La documentación de Shopify también distingue embudos abiertos y cerrados. La comparación solo encaja si las entradas y secuencias se tratan igual. Si cambia el sistema de medición, compruebe las definiciones antes de suponer que cambió el comportamiento.
Un ejemplo de investigación completo
Una tienda ficticia de material de dibujo quiere examinar esta tarea: elegir una carpeta de dibujo, introducir una dirección de entrega como invitado, seleccionar el envío y continuar al pago. Todas las cifras y observaciones de la tabla son ficticias; muestran cómo reunir distintos hallazgos.
Fuente | Hallazgo ficticio | Límite de la interpretación |
|---|---|---|
Embudo móvil cerrado | 100 sesiones llegan al proceso de compra; 60 lo completan en el mismo periodo de observación. | La diferencia es visible, pero su causa sigue abierta. |
Tras un código postal no válido, el texto de error queda fuera de la zona visible de la pantalla. | Es un obstáculo concreto en este recorrido. | |
Revisión del pago | No hay una solicitud de pago vinculada a esta tarea. | Esto no demuestra un rechazo del banco. |
Compruebe primero si los registros de pago reflejan por completo la operación analizada. La falta de entradas también puede deberse a un fallo de vinculación. Si se confirma que el formulario se detiene antes de enviar una solicitud de pago, añadir otro método de pago no corrige ese problema del formulario.
Observar la tarea en el dispositivo real
Haga que se realice la tarea en un entorno de pruebas adecuado. Registre el dispositivo, el navegador, el estado del teclado y el último paso comprensible. ¿Puede la persona reconocer qué campo es erróneo? ¿Se conservan los datos ya introducidos? ¿Puede corregir la dirección y seguir con el envío elegido?
La revisión del pago complementa la observación. Shopify describe, por ejemplo, errores procedentes de decisiones bancarias, del servicio de pago o de la configuración de la tienda. Un mensaje genérico en pantalla no permite saber cuál de estos casos se da. Vincule los eventos disponibles con la operación de prueba correspondiente en lugar de contar todas las compras incompletas como errores de pago.
Convertir el hallazgo en un cambio comprobable
Para el ejemplo, el siguiente diseño permite acceder al campo de dirección afectado, describe allí el error con texto claro y conserva los demás datos. W3C explica que un error de entrada detectado automáticamente debe identificarse y describirse mediante texto. El cambio propuesto todavía no constituye una evaluación completa de accesibilidad.
Tras implementarlo, repita la misma tarea y revise después la evolución del embudo definido con las mismas reglas. Documente también otros cambios, como los de la oferta o las fuentes de tráfico. Una prueba de tarea satisfactoria demuestra la usabilidad de ese recorrido; todavía no prueba un efecto general sobre los ingresos.
Fuentes
Seguir leyendo
Todos los artículos
E-Commerce con ASES
Tiendas online, marketplaces y portales B2B