De un problema de conversión a un POC: formularios que recuerdan al usuario
Imagina que entras en la secretaría de una universidad para pedir información sobre una carrera.
Te preguntan tu nombre, email y teléfono. Se los das.
Pero además quieres saber información de otra carrera, y les preguntas por esta segunda.
Y la persona que tienes delante vuelve a mirarte y te pregunta:
—¿Nombre? ¿Email? ¿Teléfono?
Sería absurdo. Ya sabe quién eres. Acabas de darle tus datos.
Sin embargo, eso es exactamente lo que hacemos muchas veces en una web.
Un usuario solicita información sobre una titulación, continúa navegando y, cuando muestra interés por otra, le presentamos de nuevo el mismo formulario vacío.
El problema
En webs de formación, un usuario puede consultar varias titulaciones y encontrarse el mismo formulario varias veces. Pedir nombre, teléfono y email repetidamente añade fricción, además de demostrar poco «cariño» por el usuario, por su experiencia en nuestra web.
Quien dice formación, dice la mayoría de las webs en las que se recoge el lead, es decir, las no transaccionales como en ecommerce, que ahí parece que algo hemos medio aprendido … imagina que si quieres comprar varios productos un ecommerce te hiciese terminar el proceso de compra por cada uno de ellos, no cabría en cabeza humana.
La hipótesis
Si el usuario ya nos ha dado esos datos durante esa navegación, ¿por qué volver a pedírselos?
Ya sabemos quien es, o al menos los datos que necesitamos saber de él, pues usémoslos.
Restricciones
Ya Antonio, ¿pero y la RGPD y todas esas cosas de cookies y demás? Don’t worry, se trata de que el usuario se trate mimado, a nosotros esa data nos da igual, ya nos la ha mandado, así que los datos en su navegador, nosotros no necesitamos nada más.
La solución
Al enviar el primer formulario, guardar temporalmente ciertos datos en sessionStorage. En formularios posteriores, recuperar esos valores y presentar el formulario prácticamente preparado para confirmar.
Prerellenar el segundo formulario mola, pero dejarle un simple: «También quiero información de este» mola más aún.
Y ya puesto, mola más aún, un «Hola Antonio», un pseudologin temporal (palabrejo que me he sacado de la manga)
¿Porqué sessionStorage?
Motivo principal, porque se queda en el navegador del usuario, así que nos quitamos a priori problemas de privacidad.
A nivel de sesión, si el usuario cierra el navegador, los datos se borran, así que si usa un ordenador compartido, por ejemplo en un cibercafé (tan populares en 2026 🙃), su privacidad está asegurada, así que mejor sessionStorage que localStorage.
El POC
Implementarlo no es magia negra, es sencillo, ¿lo quieres ver en funcionamiento? 👇🏻 👇🏻 👇🏻
Y el repo del plugin free para WordPress:
https://github.com/ablancodev/persistent-forms
Qué mediría antes de convertirlo en producto:
- tasa de finalización;
- leads por sesión;
- tiempo hasta conversión;
- abandono del formulario;
- porcentaje de usuarios que utilizan el formulario prerrellenado.
Esto nos dirá si nuestra prueba de concepto tiene sentido para nuestro negocio, nuestros clientes y nuestra plataforma.