Visitas, pero ningún pedido: qué revisar en una tienda de ropa antes de rediseñarla

1. Separa primero tres problemas distintos

Antes de hablar de conversión, concilia la tienda, el proveedor de pagos y la analítica. ¿Se crean pedidos? ¿Cuáles están realmente pagados? ¿Cuáles se cancelaron o reembolsaron? ¿Qué recoge el informe? Anota el periodo, la zona horaria, la moneda y el estado de pedido utilizado.

Crear un pedido, confirmar un pago y registrar una compra en analítica son comprobaciones distintas. La diferencia es especialmente importante cuando se paga contra reembolso. No cambies la definición de éxito de un periodo a otro.

Guarda algunos ejemplos concretos con fecha e identificador del pedido. Una captura del gráfico agregado no permite localizar por sí sola el punto de ruptura. Elimina los datos personales de cualquier informe público.

2. Comprueba que la analítica registra compras de verdad

GA4 dispone de eventos separados para vistas de productos, carrito, inicio de compra, compras y reembolsos. Hay que implementarlos correctamente: medir páginas vistas no basta. 1

Proponemos acordar con el desarrollador un mapa breve de medición. Los nombres siguientes pertenecen a GA4; no son código listo para pegar ni obligan a utilizar esta herramienta.

Google define los eventos; la última columna es nuestra propuesta de verificación. 1 En una compra, revisa transaction_id , productos, importe y moneda según la especificación. 2 Mantén estable el identificador de cada pedido y comprueba que volver a abrir la confirmación no duplica el resultado.

No fuerces una coincidencia total entre sistemas. Shopify, por ejemplo, documenta cómo el consentimiento de cookies y los bloqueadores afectan a la recogida de ciertos datos por sesión. 4 Explica las diferencias antes de modificar la medición; no eludas la privacidad para mejorar un gráfico.

No envíes nombres, correos, teléfonos ni otros datos identificativos a GA4, tampoco en URL o parámetros de eventos. 12 Utiliza datos de prueba seguros y las herramientas de depuración previstas por el sistema.

3. Localiza la transición que necesita una investigación

Es fácil mezclar visitantes, sesiones, eventos y pedidos. Elige la unidad antes de analizar el recorrido. Shopify diferencia los pedidos de las sesiones con compra completada: una misma sesión puede contener varios pedidos. 3

En este ejemplo utilizamos 2 000 sesiones comparables de la tienda . El embudo es cerrado y secuencial: una fase cuenta solo después de la anterior, dentro de la misma sesión, y cada sesión se cuenta una vez por fase. No sumamos eventos repetidos. Las compras realizadas por un recorrido abreviado se estudian aparte.

Calcula cada transición como sesiones de la fase siguiente / sesiones de la fase anterior × 100% . Para el porcentaje global, utiliza las 2 000 iniciales. Dividir eventos entre personas no produce la misma métrica.

Aquí, 120 de las 1 200 sesiones con vista de producto llegaron al carrito. Conviene revisar talla, disponibilidad, propuesta y medición. De 80 inicios de compra terminaron 20: hay que investigar envío y pago. La tabla no demuestra ninguna de esas causas.

No llames «clientes perdidos» a las otras 1 980 sesiones. No sabemos cuántas personas pretendían comprar inmediatamente. Si tu informe cuenta usuarios, respeta sus definiciones y ajusta los denominadores en lugar de copiar estos números.

4. Contrasta el tráfico con lo que promete la tienda

Revisa varias páginas de entrada principales siguiendo un anuncio o una publicación concretos. ¿Coinciden producto, precio, fotografía, talla disponible y condiciones? ¿Un anuncio de una chaqueta lleva a esa chaqueta y no a una colección que ya no la contiene?

Separa la revisión por dispositivo, origen, país de entrega, idioma y página de entrada. Son perspectivas de trabajo, no una obligación de crear decenas de informes. Empieza por el segmento que cambió y compáralo con un periodo realmente comparable.

Ejemplo didáctico: un artículo de estilo atrae más visitas a la revista, mientras los pedidos de la tienda no cambian. Que disminuya el porcentaje de compras del conjunto no demuestra que haya empeorado el proceso de pago. Analiza por separado las visitas a las páginas comerciales.

Antes de aumentar la publicidad, comprueba que la variante anunciada sigue disponible y que la tienda atiende ese destino. Cambiar un botón no resuelve una oferta que la persona que llega no puede comprar.

5. Revisa la ficha de ropa: talla, ajuste y disponibilidad

En los estudios de Baymard, los participantes utilizan información de tallas para elegir prendas; las fotografías sobre personas aportan contexto de ajuste y escala. 7 8 Es una razón para revisar esos elementos, no una garantía de incremento de ventas.

Nuestra propuesta es responder a preguntas reales, no imponer el mismo número de fotos en todos los productos. Utiliza estos criterios para una revisión interna.

Prueba por separado el cambio de color. ¿Se conserva una talla disponible? ¿Cambian las imágenes adecuadas? ¿Aparece stock inexistente? Pide a otra persona del equipo que complete el recorrido sin indicaciones del diseñador.

Si faltan medidas, solicítalas al equipo de producto. No inventes centímetros para rellenar una tabla. La escasez artificial y las reseñas sin respaldo no sustituyen una propuesta clara y exacta.

6. Recorre la compra y el pago hasta el final

No pruebes únicamente un pedido exitoso. Empieza por el entorno de pruebas autorizado del proveedor. Stripe documenta, por ejemplo, pagos simulados, rechazos y autenticación sin mover dinero real. 6

Elige un producto, un envío y un método de pago. Tras el recorrido básico, añade incidencias. La matriz siguiente es un plan propuesto, no una afirmación de que las pruebas ya se hayan realizado.

W3C recomienda avisos claros de éxito y error, con indicaciones para corregir el problema. 9 Por eso, un borde rojo sin explicación no basta para nuestra comprobación de aceptación.

Determina cuándo se muestran el importe final y las opciones de entrega. Revisa también los cupones, la compra como invitado cuando exista y el regreso desde una ventana de pago externa. Una prueba correcta no valida todos los métodos ni todos los países.

7. Comprueba el recorrido móvil, no solo una puntuación de velocidad

Abre el producto, elige talla, activa el teclado del formulario y regresa del pago. ¿Un aviso, un chat o una barra fija tapa una acción importante? ¿Se encuentra el error sin recorrer toda la página? ¿Se puede ampliar el texto y continuar comprando?

Para la revisión técnica, los objetivos de Core Web Vitals son LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1 , evaluados en el percentil 75 y separando móvil y ordenador. 10 No son objetivos de conversión ni promesas de ventas.

Los datos de campo de CrUX no están disponibles para todas las páginas: se aplican requisitos de inclusión y suficiencia de datos. 11 Su ausencia no significa mala velocidad. Una prueba de laboratorio es una observación bajo condiciones concretas, no la experiencia de toda la audiencia.

Prioriza la ficha y el proceso de compra afectados, no solo la portada. Registra dispositivo, navegador, conexión y acción. «La interfaz se bloquea al elegir talla» es una tarea más útil que «acelerar la web».

8. ¿El pedido llegó al equipo?

Shopify describe casos de pagos externos completados cuya confirmación no se comunica correctamente a la tienda. 5 Que el pedido falte en la lista esperada no siempre significa que el comprador haya abandonado.

Proponemos seguir la cadena: registro del pedido → confirmación del pago → estado acordado → tarea para el empleado → mensaje al cliente. Un aviso por email no debería ser la única prueba de existencia del pedido.

Asigna un responsable de las discrepancias. Comprueba cómo detectará el equipo un registro sin aviso, una confirmación tardía o un fallo de envío al CRM. No cambies manualmente un estado financiero sin verificar los registros originales y seguir el proceso acordado.

Si la tienda funciona mediante solicitudes, aplica la misma lógica al formulario. Google contempla generate_lead para un contacto generado. 13 Un clic en mensajería no confirma la recepción del mensaje. Sigue una solicitud de prueba hasta el empleado y mide la venta posterior por separado.

9. Separa corregir un fallo de probar una hipótesis

Un fallo reproducible no necesita esperar a un test A/B para reconocerse como tal. Sí necesita repetirse la prueba después de corregirlo. «Otro texto aumentará las ventas» es una hipótesis distinta y exige evaluar resultados.

Cada tarea debe indicar observación, evidencia, comportamiento esperado, responsable y comprobación. «Mejorar la experiencia» no define el trabajo ni cómo aceptarlo.

10. Evalúa los cambios sin inventar crecimiento

Supongamos que el porcentaje de sesiones con compra pasa del 1% al 1,5%. Son 0,5 puntos porcentuales más y un aumento relativo del 50% , no 50 puntos porcentuales. Una cuenta correcta tampoco demuestra que el cambio de la web sea la causa.

Registra cambios simultáneos de publicidad, precio, catálogo, existencias y entrega. Compara periodos y segmentos equivalentes. Para un test A/B, define de antemano la métrica principal, la asignación, la suficiencia de observaciones y la condición de cierre. No lo detengas con el primer resultado favorable.

Cuando hay pocas compras, prioriza los fallos reproducibles y la observación antes de declarar un ganador por unos pocos pedidos. No existe una regla universal de «siete días bastan». Si no puedes aislar la causa, explica que se observó una diferencia tras el cambio, con otras influencias sin resolver.

Mira también cancelaciones, devoluciones y carga de trabajo. Un descuento o una promesa de entrega rápida pueden modificar los pedidos sin convertir el resultado en rentable o realizable.

11. Cuándo sí tiene sentido rediseñar

Proponemos considerar un rediseño global cuando la revisión muestra obstáculos relacionados entre navegación, ficha y compra que no se pueden corregir razonablemente de forma local. Sustenta la decisión con observaciones, un nuevo recorrido y una forma de evaluarlo antes del lanzamiento completo.

El rediseño no arregla por sí solo stock incorrecto, tráfico inadecuado o confirmaciones de pago perdidas. Si existe una limitación de plataforma, vuelve a «Cómo crear una tienda de ropa online: Tilda, Shopify o desarrollo a medida». Para el presupuesto, utiliza «Cuánto cuesta crear una tienda online de ropa: lanzamiento y primer año».

Aquí el objetivo es distinto: identificar el problema antes de elegir una solución costosa. A veces bastan un formulario corregido e información precisa. Otras veces hay que reconstruir varios recorridos. La revisión debe determinar el alcance.

13. Por dónde debe empezar el responsable de la tienda

Reúne la página afectada, el periodo, el origen del tráfico, la definición de compra exitosa y algunos ejemplos anonimizados. Recorre el pedido y registra el primer punto de ruptura confirmado. Asigna después una corrección o una prueba de hipótesis según la evidencia.

El resultado útil no es una lista de cien consejos genéricos. Es saber qué falla, qué sigue siendo desconocido y qué se comprobará después.

Consulta con VITON13 la revisión del recorrido de compra, desde la ficha de ropa hasta un pedido confirmado que recibe el equipo. Comparte accesos únicamente mediante un proceso seguro acordado, nunca en comentarios públicos ni en el texto del artículo.