Uno de los escenarios más frustrantes al medir interacciones en una web es encontrarse con datos inflados por envíos duplicados de formularios. Esto puede ocurrir si un usuario recarga la página de agradecimiento o si, por error, envía el mismo formulario más de una vez. Afortunadamente, Google Tag Manager nos ofrece una solución elegante para controlar este comportamiento y mantener nuestros datos limpios.
¿Por qué suceden los envíos duplicados?
Imagina que has configurado una etiqueta para que dispare un evento en Google Analytics 4 cuando se carga una URL que contiene «/thank-you». El problema aparece cuando el usuario refresca la página después del envío o pulsa atrás y vuelve a enviar el formulario. En ambos casos, GTM volverá a disparar la etiqueta, creando eventos duplicados en tus informes.
Esto distorsiona métricas importantes como el número de conversiones, la tasa de éxito de formularios o incluso el coste por conversión si estás importando estos eventos como objetivos en campañas publicitarias.
Capturando el ID del formulario
Para solucionar esto, el primer paso es capturar un identificador único que nos permita diferenciar los formularios. En muchos casos, el form_id está disponible como parámetro en la URL después del envío. Utilizando GTM, puedes crear una variable de tipo URL que extraiga este parámetro y lo almacene para su posterior validación.
Este identificador será clave para construir una lógica que nos permita saber si ese formulario ya fue enviado por ese usuario durante la sesión o visita.
Guardando el ID en el navegador
Aquí es donde entra en juego la etiqueta de HTML personalizada. Mediante un pequeño script de JavaScript, guardamos el ID del formulario en el almacenamiento local del navegador (localStorage). Así, cada vez que un usuario envíe un formulario, ese ID quedará registrado y podremos consultarlo antes de volver a disparar cualquier evento de conversión.
El truco está en que este almacenamiento no se borra al actualizar la página, por lo que aunque el usuario recargue, GTM sabrá que ese formulario ya fue procesado y evitará duplicar el evento.
Ejecutando la etiqueta en el momento correcto
Una parte fundamental de esta estrategia es asegurarse de que el almacenamiento del form_id se haga después de enviar los datos a Google Analytics. Para lograrlo, no usamos un trigger tradicional, sino que configuramos la etiqueta de almacenamiento para que se dispare como secuencia posterior a la etiqueta principal de GA4.
Esto se configura en la sección de “Ajustes Avanzados” de la etiqueta GA4. Así nos aseguramos de que el evento de conversión se registre primero y solo entonces guardamos el form_id, bloqueando posibles duplicaciones en futuras recargas.
Detectando si el formulario ya fue enviado
El siguiente paso es crear una variable de tipo JavaScript personalizada que revise el almacenamiento local. Esta variable nos dirá si el ID actual del formulario ya se encuentra en el array de formularios enviados. Si el resultado es true, significa que ese formulario ya fue procesado antes. Si es false, estamos ante un envío válido.
Esto nos da el control total sobre cuándo dejar pasar un evento hacia Google Analytics y cuándo bloquearlo.
Modificando el trigger del evento de envío
Con la variable creada, solo queda actualizar el trigger de la etiqueta de envío del formulario. A la condición original, se le añade una comprobación: que la variable «¿es duplicado?» sea igual a false. De este modo, solo se permitirá ejecutar el evento cuando el formulario no haya sido enviado previamente.
Esta lógica simple nos permite filtrar cualquier intento posterior, ya sea por recarga, error del usuario o duplicación intencionada.
Validación y pruebas
Para comprobar que todo funciona correctamente, puedes utilizar el modo de vista previa de GTM y las herramientas de desarrollo del navegador. En el almacenamiento local (Application > Local Storage), deberías ver una clave llamada gtm_submitted_forms que contiene los IDs de formularios enviados.
Además, en el asistente de etiquetas (Tag Assistant), puedes observar cómo la variable de control devuelve false en el primer envío y true en los intentos posteriores.
Qué pasa si el usuario envía un formulario diferente
La solución también contempla este caso. Si el usuario visita otro formulario con un ID diferente, este nuevo ID no estará aún registrado en localStorage. Por tanto, GTM lo tratará como un envío válido, almacenará su ID y activará el evento correspondiente. Así conseguimos que cada formulario sea tratado de forma independiente.
Publicación final y consideraciones
Una vez verificado el funcionamiento, puedes publicar los cambios en el contenedor de GTM, asegurándote de seguir tu convención de nombres. A partir de ese momento, tus datos de eventos serán más fiables y evitarás inflar tus métricas con duplicados.
Eso sí, debes tener en cuenta que localStorage funciona a nivel de subdominio. Si tu sitio opera bajo distintos subdominios, la solución solo funcionará por separado en cada uno. En esos casos, podrías considerar una estrategia basada en cookies, aunque requerirá ajustes adicionales.
También hay que decir que, si tienes desarrolladores disponibles, una solución más robusta es que ellos emitan un evento en el dataLayer al confirmar el envío real del formulario. Esto garantiza aún más control, ya que el evento solo se dispara si la respuesta del servidor lo valida.