¿Cómo recoge el dato?

Nuestros formularios pueden enviar 3 mensajes: Éxito, Abandono o Error, para medir cada caso activaremos en nuestra consola de Sytecatalist estos tres eventos:

• Éxito (el formulario es enviado sin errores)– event1
• Abandono (el usuario rellena el formulario pero desiste en enviarlo o tras varios intentos se va) – event2
• Error (el formulario es enviado, pero algún campo ha sido mal completado) – event3

Cada uno de nuestros formularios debe ser configurado para que cuando ocurra alguno de esos tres casos se invoque el evento correspondiente.

Ya tenemos él “Cuándo” ocurre el evento…. vamos a por el “Qué”.

El “Qué” ocurre, es importante tenerlo en cuenta, almacenaremos el  error que se produce, esto nos permitirá corregir nuestro formulario y mejorar su rendimiento, para ello activaremos una variable de conversión (también es posible hacerlo con una variable de tráfico), donde guardaremos la descripción del fallo:

• Descripción del error – eVar1

Esta variable podrá ser alimentada con el nombre de la página web, el nombre del  formulario, la descripción del error y el elemento/campo que ha generado el error.

Con nuestro formulario configurado y en funcionamiento, podremos visualizar métricas como la que se ve en la imagen, con suficiente información para detectar donde fallan nuestros visitantes y poder facilitarles, en este caso, el proceso de compra.

El “por que”: Análisis de datos.

Vamos a trabajar sobre el ejemplo anterior, donde se ven algunos de los fallos más comunes en los formularios de ecomerce y más fáciles de corregir.

El objetivo de nuestra optimización en este caso es evitar el mayor numero de errores, de tal manera que una vez se envíe, el resultado sea un envío satisfactorio y sin mensajes de error, el visitante no tiene que volver a rellenar datos y evitamos el abandono.

El fallo en el documento:

Normalmente se trata de un número acompañado de una letra. En este caso se solicita el Dni o Nif, podemos ayudarle informándole de la letra del documento, esto le indicará si lo ha escrito bien y por otra parte le asistirá en el formulario.

Se puede configurar el formulario para que no permita insertar más caracteres que los máximos y concretos de este tipo de documentos, pudiendo separar los campos de cada tipo de carácter e indicando que debe poner en cada uno.

El fallo en el la cuenta corriente:

Para disminuir el número de errores haremos uso de la idea de separar los campos en los grupos de dígitos de las cuentas corrientes y autocompletarlos para facilitarle la tarea al visitante, pero antes, un poco de teoría.

Una cuenta corriente está formada por 4 grupos de números

• Entidad  (4 dígitos)
• Oficina (4 dígitos)
• Control (2 dígitos)
• Cuenta (10 dígitos)

De estos 4 grupos, la entidad y oficina son conocidas y públicas, pueden ofrecérsele al visitante si los tenemos guardados en nuestra base de datos, el código de control es un valor generado a partir de un algoritmo del resto de grupos numéricos y de esta manera nuestro visitante sólo tendría que completar el número de cuenta.

El fallo en el código postal y la provincia:

Cuando el visitante rellena estos dos campos pero el número no corresponde con la provincia o municipio. Este caso, es quizás el más sencillo de completar de los tres y a la vez el que nos permitirá reducir el número de campos a rellenar de nuestro formulario, reduciendo el tiempo para completarlo y ganando en satisfacción del visitante (creo que a ninguno nos gusta rellenar formularios y a menor número de campos, menos tiempo invertido).

Podemos retirar de nuestro formulario el campo de la provincia y el municipio dejando únicamente el código postal. Cuando nuestro visitante lo completa nosotros le informaremos (si lo consideramos necesario) de cuál es la provincia y el municipio del código que ha puesto.

Como se puede ver, el análisis de formularios no requiere de un gran conocimiento técnico, un poco de tiempo y  algo de investigación con eso obtendremos una mejora para nuestra conversión en la red.

En resumen, pónselo fácil a tus visitantes.