Entendiendo cómo funcionan nuestros formularios y cómo medirlos usando Google Tag Manager
Cómo podemos usar Google Tag Manager para medir el desempeño de los formularios en nuestro sitio web.
Se podría argumentar que para una gran mayoría de sitios web, el formulario es uno de los elementos más importantes. Es, casi siempre, lo que usamos para medir las conversiones y así comprobar que nuestras energías estén en el lugar correcto.
Así que vamos a aprender cómo podemos usar Google Tag Manager para medir nuestros formularios de la manera más eficiente.
Lo primero que debemos determinar es qué tipo de formulario tenemos y dependiendo del que sea tomaremos dos estrategias diferentes.
Para determinar esto vamos a ver la estructura de un formulario y tocaremos un poco de código para explicar mejor todo, si ya sabes esto o no es de tu interés, puedes saltar a la siguiente sección sin problema.
Estructura de un formulario web
A pesar de que todos deberíamos estar familiarizados con un formulario estándar de contacto, un formulario puede llegar a ser complejo y tener más elementos de los que se ven a simple vista. Primero vamos a explicar la estructura básica de un formulario en código. En lo más base el código de un formulario se ve así:
<form action="/enviar" method="post" class="form">
<div class="form-box">
<label for="nombre">Nombre</label>
<input type="text" for="nombre" id="nombre" />
</div>
<div class="form-box">
<button type="submit">Enviar</button>
</div>
</form>Esto es el HTML de un formulario con un solo campo, para colocar un nombre y el botón enviar. Sé que muchos verán esto y pensarán
Pero si se toman el tiempo de “leerlo”, el código se explica solo. Primero abrimos un formulario con el tag <form> e indicamos ciertos atributos, la acción determinará a donde enviaremos los datos. En nuestro caso a una URL llamada /enviar; después vemos method que es el método con el cual se envía el formulario, hay varios pero los dos más comunes es POST y GET y la diferencia más obvia es que cuando colocas method="get" y le damos a enviar vamos a ver nuestros datos en la URL, mientras que con method="post" no se ve nada.
Lo último es una clase para nuestros estilos en CSS.
Después vemos un div, que es un contenedor genérico, si alguna vez has visto HTML has visto div por todos lados.
Dentro del primer div vemos un label que como seguro ya concluyeron es la etiqueta que ayuda a saber para el propósito del campo, este tag no es necesario pero es muy recomendado utilizarlo siempre porque ayudaba a la usabilidad del formulario.
Después vemos un input y este es el tag que más nos interesa de todos los que vemos dentro de un formulario, porque un input es lo que realmente el usuario usará para llenar información, es donde el usuario copia, el input tiene varios atributos, pero el más importante es type porque es el que determina que tipo de input se le mostrará al usuario, type="text" es el más común de todos, pero hay muchos, los más usados son:
type="password"para las claves.type="url"para las direcciones web.type="number"solo acepta números.type="email"solo acepta una dirección de correo.
Un par de bonos extras de usar los input correspondientes es que en los teléfonos móviles, el teclado cambia dependiendo del tipo de input, además de esto, si colocamos que el campo es obligatorio, mediante el atributo required tenemos validación gratis del navegador. Pueden entrar aquí desde sus teléfonos para ver el demo.
Un tipo de campo muy usado pero que no se ve (cómo su nombre lo indica) es el type="hidden" este campo oculto se usa para enviar data con nuestro formulario, pero no necesitamos que el usuario complete, por ejemplo, si tienes un formulario de contacto en el footer de todas tus páginas, podemos usar el campo hidden para “pasar” algún parámetro que nos diga desde cual página se envió el formulario, puede ser el título, la URL, el ID. Esto es una información útil para ti que el usuario no debe llenar.
Y por último vamos a ver otro contenedor div con un botón dentro button con nuestro texto Enviar.
Thank you page
Esta es una página que todos hemos visto también (espero), después de comprar un producto (esto es un formulario o varios formularios) o llenar un formulario de contacto, formulario de algún evento o lo que sea, a veces una página es un formulario sin darnos cuenta que es un formulario, una vez que el usuario complete esa acción llegará a esta página. Una página de agradecimiento.
Estas páginas son muy útiles por varios motivos, el primero es que nos ayudan a medir si un usuario llegó a este destino. Nuestra lógica dice que si llegó aquí es porque completó la acción que procedía ¿cierto? ¿CIERTO?
La verdad es que no siempre es así y no podemos confiarnos solamente en esto. Adicionalmente esta página sirve para mejorar nuestra conversión, si un usuario compró un producto, aquí podríamos pedirles que se suscriba en un newsletter donde le informaremos cuando lleguen nuevos productos.
Esta página ya no es tan común, ahora con el uso masivo de AJAX, una tecnología que usa javaScript para hacer el envío del formulario “silenciosamente” sin necesidad del redireccionamiento, podemos enviar un formulario y mostrar el clásico mensaje de “Tu mensaje fue enviado”.
¿Cómo funcionan nuestros formularios? | Entendiendo tu formulario
Como discutimos un poco más arriba, aunque dos formularios se vean iguales, por “debajo” puede que funcionen de manera muy diferente ya la forma de enviarlo pueden variar.
Así que lo primero que debemos averiguar es si el formulario se envía usando AJAX o no. Hay dos maneras fáciles y una mas “complicada” de saber esta información.
La más fácil aunque no 100% certera es ver el comportamiento del formulario, si enviamos los datos y el mensaje de que el formulario fue enviado con éxito se muestra en la misma página, el formulario se está enviando con AJAX 100% de las veces. ¿Porque entonces digo que no es 100% certera? Porque aunque usemos AJAX, igual podemos simular el redireccionamiento mediante javaScript una vez que recibamos el OK del servidor que nuestro formulario fue procesado.
La seguda más fácil y 100% certera es preguntarle a la persona que programó el formulario.
Si no puedes preguntarle al que hizo el formulario y este redirecciona, nos queda la última manera, que es usando Chrome Developer tools
Debes abrir Chrome Developer Toolspresionando cmd+alt+Jend Mac o ctrl+alt+Jen Windows. Ahí debes ir a la pestaña “Network” y darle click al icono del embudo, lo cual nos abrirá nuevas opciones.
Después le vamos a dar click a XHR y por último darle click al botón de “limpiar” para que no nos muestre nada en la consola y tener una pista clara.
Una vez estemos ahí es que procedemos a llenar nuestro formulario y a darle a enviar, si algo aparece en esa área nuestro formulario usa AJAX.
¿Por qué es importante saber esto?
Porque esto determina si puedes tagear el formulario sin necesidad de tocar el código.
Formulario tradicional.
Ahora que ya estamos seguros cómo funciona nuestro formulario y sabemos que este no usa AJAX para el envío podemos proceder a tagearlo con Tag Manager de la siguiente manera:
Configurando trigger
Lo primero que debemos hacer es configurar nuestro trigger, donde podemos ver en la sección de “User Engagement” el segundo que dice “Form Submission”
Si estamos un poco perdidos recomiendo leer mi post anterior de uso de Tag Manager para principiantes — Fin de la autopublicidad
Una vez que tengamos el trigger, el siguiente paso es configurar un nuevo tag, cuando debemos escoger qué queremos medir seleccionamos Evento y podemos pasar todos los valores, ya sea directo o de manera más recomendada como constantes que hayamos definido antes.
Y eso es todo, ahora cada vez que nuestro formulario se envíe nuestro evento aparecerá dentro de la sección de Eventos en Analytics.
Formulario no tradicional
Lamentablemente si tu formulario es “No tradicional”, es decir, usa AJAX para el envío, el método nativo de Google Tag Manager no funciona, debemos hacer un trigger personalizado y hay que insertar código en el JavaScript.
Me parece importante resaltar que cuando estuve haciendo pruebas, en algunas ocasiones sí me funcionó el disparo del formulario, sin embargo, el problema es que sólo se dispara cuando se envía el mismo, muchas veces es mejor agregar nuestro código personalizado cuando recibimos el OK del servidor de que todo fue procesado correctamente, sino podríamos tener un problema con el código en el servidor y estaríamos registrando eventos de todas maneras.
Si no te sientes a gusto tocando el código te recomiendo solicitarle ayuda a alguien que si sepa. Ten en cuenta que es muy fácil tocar algo que no debes y dañar el envío de los formularios y nadie quiere eso.
Usaremos el dataLayer para enviar nuestros datos, como comenté en mi artículo anterior, lo primero que debemos hacer es definir que datos queremos enviar y con qué estructura.
Supongamos que tenemos un formulario que las personas deben llenar para poder entrar a un concurso. Un formulario como este.
Podemos ver los siguientes campos: Nombre completo, correo, teléfono, razón por la cual debes ganar y botón de enviar y asumamos que el usuario debe llenar todos los campos para que se haga el envío.
Nuestro primer instinto es agregar el código para que se dispare cuando el usuario hace click al botón de enviar pero esto es un error.
Recordemos nuestra como funciona un formulario
Podemos ver el error si colocamos nuestro código de confirmación cuando el usuario le da click a Enviar ¿cierto? Puede que esa persona ya esté inscrita en la base de datos, y en nuestro modelo cada persona puede enviar el formulario sólo una vez, así que validamos que el correo ya exista antes de confirmar la inscripción. Si queremos podemos tener un control más granular, podríamos tener tres eventos. Uno que sí se dispare cuando le dan click a “enviar”, otro que se dispare cuando el formulario fue enviado exitosamente y otro que se dispare si la persona llenando el formulario ya estaba inscrita, esta es la ventaja de hacer el envío con JavaScript ya que podemos controlar mucho más como manejamos nuestra información.
Para enviar el formulario de nuestro concurso tenemos el siguiente código usando Axios para nuestro envío:
form.addEventListener('submit', function(event) {
event.preventDefault();
axios.post('./form.php', {})
.then(function (response) {
if ( !response.data.registrado ) {
form.classList.add('hide-me');
form.insertAdjacentElement('afterend', gracias());
}
})
.catch(function (error) {
console.log(error);
});
});Entonces podemos modificar el código para insertar nuestro código de registro y no registro
form.addEventListener('submit', function(event) {
event.preventDefault();
axios.post('./form.php', {})
.then(function (response) {
if ( !response.data.registrado ) {
form.classList.add('hide-me');
form.insertAdjacentElement('afterend', gracias());
dataLayer.push({
'formEvent': 'form',
'formCategory': 'Envio de Formulario',
'formAction': 'Formulario de concurso',
'formLabel': 'Registro'
});
}
if ( response.data.registrado ) {
form.classList.add('hide-me');
form.insertAdjacentElement('afterend', yaRegistrado());
dataLayer.push({
'formEvent': 'form',
'formCategory': 'Envio de Formulario',
'formAction': 'Formulario de concurso',
'formLabel': 'Ya registrado'
});
}
})
.catch(function (error) {
console.log(error);
});
});Obvio podemos modificar los valores de Event, Category, Action y Label como queramos, esto es sólo un ejemplo, he visto casos en los que pasan dentro del Label algún dato específico de quien envió el formulario para atarlo con otros eventos. Por eso siempre es importante planificar qué eventos debemos medir para poder hacer un marcado efectivo.
Adicionalmente debo decir que esta es una explicación relativamente sencilla pero según mi experiencia limitada funciona bastante bien para casi todos los formularios que se pueden encontrar día a día, sin embargo, inevitablemente encontrarán casos mucho más complejos donde deben hacer una personalización aún más grande.
Muchas gracias por leer. Cualquier duda me pueden comentar por acá o por twitter.
