Si un informe muestra veinte conversiones de formulario, la primera pregunta es qué ocurrió veinte veces. Puede tratarse de clics en el botón, intentos de envío o solicitudes aceptadas. Para tomar decisiones comerciales, esa diferencia debe estar resuelta y documentada.
Esta guía propone cinco pruebas para revisar un formulario con el equipo técnico. El resultado debe permitir explicar qué cuenta GA4, cuándo lo cuenta y qué evidencia confirma que la solicitud llegó al destino previsto.
Define qué vas a contar como solicitud
Escribe una definición operativa antes de revisar etiquetas:
- Clic: alguien pulsa el botón. Puede hacerlo con campos vacíos.
- Intento de envío: el formulario inicia el proceso, que todavía puede fallar.
- Envío confirmado: la aplicación confirma que ha aceptado correctamente la solicitud.
- Recepción verificada: la solicitud consta en el buzón o CRM previsto.
- Lead cualificado: el equipo comprueba que la consulta cumple sus criterios comerciales.
Google incluye generate_lead para registrar la generación de un contacto y qualify_lead para su cualificación posterior en sus eventos recomendados. El nombre elegido no garantiza que la implementación represente esa acción.
Acota el formulario: contacto comercial, presupuesto o demostración. Un buscador interno y una suscripción pueden necesitar mediciones diferentes. Si todavía necesitas localizar dónde se frena la captación, empieza por diagnosticar impresiones, clics y contactos.
Lo esencial del esquema
- Un clic puede producirse con campos vacíos.
- Un intento de envío todavía puede fallar.
- La aplicación debe confirmar la aceptación.
Después se comprueban por separado el evento en GA4 y el registro real en el buzón o CRM. Hay que evitar duplicados y datos personales en los eventos. La observación depende también de la configuración y el consentimiento. La cualificación comercial es posterior.
Identifica una sola vía para generar el evento
Pide un esquema sencillo: formulario, señal de éxito, regla que activa la medición y evento de destino. Averigua si intervienen un complemento, Google Tag Manager, código propio o una regla creada en Analytics.
La medición mejorada de GA4 puede recoger form_start y form_submit. Antes de usar este último como solicitud comercial, comprueba cómo se comporta con ese formulario concreto. Su aparición, por sí sola, no acredita que se haya recibido un correo o creado un registro en el CRM.
Para el mismo envío confirmado, debe existir una única vía de generación del evento comercial. Si un complemento lo envía y una regla adicional lo vuelve a crear, el informe puede duplicarlo. Un evento de interacción puede convivir con otro de éxito; evita sumar ambos como solicitudes.
Prepara una prueba que se pueda repetir
Utiliza un entorno autorizado, preferiblemente de pruebas, y datos sintéticos. Acordad un buzón o CRM de prueba y evitad activar seguimientos comerciales reales. Los fallos de servidor deben simularse de forma controlada en ese entorno por el responsable técnico, sin provocar errores en producción.
Anota versión del formulario, URL, dispositivo, hora con zona horaria y estado del consentimiento. Inicia cada caso desde el mismo estado y registra su ventana de observación. Comprueba un envío correcto al principio y al final para distinguir un fallo de medición de una prueba negativa válida. Separa las pruebas de los informes comerciales mediante el entorno y las exclusiones acordadas y verificadas.
Para observar los eventos recibidos, Google documenta DebugView y la activación de depuración con Tag Assistant. Limita la depuración al dispositivo de prueba. Comprueba la propiedad correcta, el nombre del evento, sus parámetros y cuántas veces aparece.
Cinco pruebas que debería superar el formulario
Los recuentos siguientes presuponen un entorno de medición habilitado conforme al consentimiento elegido. Registra también los resultados reales; una expectativa no equivale a una prueba superada.
1. Envío correcto
- Acción: completa los campos válidos y envía una vez.
- Resultado esperado: la aplicación acepta una solicitud y muestra su confirmación.
- Evento esperado: un único evento comercial después de la aceptación.
- Evidencia: confirmación de la aplicación, evento recibido en GA4 y comprobación separada en buzón o CRM de prueba.
2. Validación fallida
- Acción: deja vacío un campo obligatorio o utiliza un formato inválido.
- Resultado esperado: un mensaje permite corregirlo y no se acepta la solicitud.
- Evento esperado: cero eventos comerciales de envío confirmado.
- Evidencia: error visible, ausencia del evento comercial durante la prueba y ausencia de una nueva solicitud recibida.
3. Error del servidor
- Acción: el técnico simula un rechazo sin aceptación, exclusivamente en el entorno preparado.
- Resultado esperado: se informa del fallo sin mostrar éxito.
- Evento esperado: cero eventos comerciales.
- Evidencia: respuesta de error, registro del sistema y observación de eventos. Si el resultado es incierto, se investiga antes de repetir.
4. Doble clic en enviar
- Acción: pulsa dos veces seguidas con datos válidos.
- Resultado esperado: el sistema evita duplicar una misma solicitud.
- Evento esperado: uno para la solicitud aceptada.
- Evidencia: una sola recepción y un solo evento. Si aparecen dos registros, revisa también el formulario; ocultar un evento no corrige la duplicación del contacto.
5. Recarga y vuelta a la confirmación
- Acción: tras un envío correcto, recarga o vuelve a la pantalla de confirmación sin iniciar otra solicitud.
- Resultado esperado: no se registra una solicitud adicional.
- Evento esperado: cero eventos comerciales nuevos por revisitar esa pantalla.
- Evidencia: la solicitud de esta prueba conserva un único evento; la recarga no añade otro. Una página de agradecimiento accesible directamente tampoco debería acreditar un envío nuevo.
Comprueba la recepción y el consentimiento por separado
Una etiqueta activada confirma un paso de la instrumentación. Para cerrar la prueba, comprueba qué recibió Analytics y qué recibió la empresa. Si el formulario acepta datos pero la integración con el CRM falla, documenta ese estado y quién recupera la solicitud.
Repite las comprobaciones de consentimiento con las opciones que ofrece la web, incluida la denegación. El comportamiento esperado debe corresponder a la configuración aprobada. Google distingue modos de consentimiento básico y avanzado: no tienen el mismo comportamiento de transmisión cuando se deniega. No fuerces la recogida para igualar un contador.
Además, DebugView puede no mostrar eventos bajo ciertas restricciones de privacidad o consentimiento. Esa ausencia requiere revisar el contexto de la prueba; por sí sola no demuestra que el formulario haya fallado.
Parámetros útiles, sin datos personales
Para distinguir formularios, suele bastar un identificador técnico fijo, como contacto_comercial. No envíes nombres, correos, teléfonos ni el texto libre de la consulta en los parámetros del evento. Revisa también las direcciones de agradecimiento, los títulos y los parámetros de URL, que pueden filtrar información. La política de Google sobre información identificativa explica este requisito.
Qué debe entregar quien revisa la medición
Solicita el mapa de eventos, las cinco pruebas con resultado y evidencia, las limitaciones detectadas y las exclusiones de pruebas internas. Tras validarlo, decide si el evento representa una acción importante y debe marcarse como evento clave.
Ese marcado no cualifica automáticamente el contacto. Ventas necesita registrar su encaje. Compara después un periodo común de solicitudes recibidas y eventos, considerando consentimiento, bloqueadores y duplicados; utiliza las diferencias para investigar, no para asumir una equivalencia exacta.
La captación y medición de la web se revisan juntas para entender qué ocurre desde la visita hasta la solicitud.
¿Qué está contando tu formulario?
Cuéntanos qué formulario utilizas y qué estás contando como solicitud para valorar una revisión.