Analizando Formularios (Parte II)
En el anterior capítulo sobre nuestro análisis de formularios pudimos ver algunas de las características de los formularios que Sitecatalyst FormAnalisys ™ nos permitía analizar, hoy, vamos a entrar en materia y me gustaría mostraros la parte técnica y analítica de la herramienta (que no cunda el pánico, es apto para todos los públicos) .
¿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.
Comentarios
[...] This post was mentioned on Twitter by mv consultoria, feedwebanalytic. feedwebanalytic said: MVConsultoria – Analizando Formularios (Parte II): En el anterior capítulo sobre nuestro análisis de formularios p… http://bit.ly/7qDXZ5 [...]
Hola Daniel, me parece muy acertada tu opinión.
Por supuesto que no podemos caer en la tentación de hacer que el formulario se rellene sólo, la calidad de los datos va en detrimento de eso, pero si podemos ayudar en el proceso de cubrir todos los campos usando “Select Box” o indicando cual sería la información a incluir en el resto de campos en función a lo que ha puesto anteriormente.
Está claro que para encontrar el punto idóneo de optimización hay que analizar cada caso por separado según los objetivos de cada formulario y trabajar duro sobre los mismos para conseguir mejores resultados.
No estoy de acuerdo con el planteamiento de facilitarle al usuario los datos que son calculables mediante algoritmo. Tano la letra del DNI como el digito de control se usan precisamente para evitar que se introduzcan número erróneos o falsos. Si dejamos que el cliente se salte esa verificación es posible que más usuarios pasen el formulario pero a costa de un descenso de la calidad en los datos muy preocupante: DNI’s falsos, cuentas mal escritas…
Si bien es cierto que hay que ayudar al cliente a serlo, hay ciertos límites que no es recomendable superar, pues poner las cosas demasiado fáciles suponen agujeros de seguridad importantes.