El informe muestra 40 conversiones, pero el equipo dice haber recibido solo 25 solicitudes. Antes de decidir quién se equivoca, establece qué cuenta cada uno. Un clic en un botón, un intento de envío y una solicitud registrada son eventos distintos.
Esta distinción influye en las decisiones de presupuesto. Si el informe cuenta una acción que nunca se completa, la campaña puede juzgarse por resultados que la empresa no recibe. Si la solicitud se registra pero nunca llega a su responsable, el problema está más adelante en el proceso.
Definimos la conversión como la acción real que queremos y después comprobamos si la implementación mide de verdad esa acción.
Este artículo sigue dos preguntas relacionadas: ¿llegó la solicitud a la empresa?, y ¿en qué condiciones puede medirse? Por eso la comprobación del formulario lleva al seguimiento, a los navegadores y al consentimiento.
¿Qué significa «formulario enviado»?
En un formulario de contacto sencillo, define primero el éxito: los datos pasan la validación, el sistema acepta el envío y el equipo puede encontrar el registro. La confirmación que ve el visitante tiene que reflejar lo que pasó de verdad.
Un proyecto puede conectar una web, un servicio de email y un CRM, el sistema que se usa para gestionar las conversaciones con los clientes. Que la web acepte el envío no demuestra que el email haya llegado ni que el traspaso al CRM haya funcionado. Comprueba cada conexión relevante.
| Paso observado | Lo que sabemos | Lo que aún hay que comprobar |
|---|---|---|
| Clic en el botón | Alguien intentó una acción | La validación y que el envío funcionó |
| Solicitud aceptada y registrada | El sistema registró la solicitud | La notificación y que el equipo se hace cargo |
| Evento en la herramienta de analítica | La medición recibió una señal | Si la señal corresponde a la acción definida |
| Solicitud cualificada | La solicitud cumple los criterios comerciales | El contacto, la propuesta y el avance posterior |
Google Analytics documenta el evento generate_lead para la generación de una solicitud, por ejemplo mediante un formulario. El nombre no comprueba el formulario: el equipo tiene que definir y poner en marcha el desencadenante correcto. Eventos recomendados en GA4 (en inglés)
Una solicitud. Tres lugares que comprobar.
Un evento de analítica y una solicitud que recibe el equipo responden a preguntas distintas.
FORMULARIO
- ¿Qué ve el usuario?
- Validación y resultado real
- Confirmación o error
SOLICITUD
- ¿Qué encuentra el equipo?
- Un registro recuperable
- Notificación y responsable
MEDICIÓN
- ¿Qué llega a la herramienta de analítica?
- Una señal definida
- Sin duplicados injustificados
Comprobar las tres a partir del mismo envío de prueba.
Ejemplos ilustrativos, no resultados de un cliente de NOT MORE.
Una página de agradecimiento confirma una acción que ya ha funcionado
Una página de confirmación puede explicar el siguiente paso, el plazo de respuesta real y lo que la persona puede hacer mientras tanto. También es útil para algunas implementaciones de la medición.
Pero el simple hecho de mostrar esa página no debe crear una nueva solicitud. ¿Qué pasa si el usuario recarga la página, vuelve desde el historial o abre el enlace directamente? El evento elegido para una solicitud correcta tiene que estar ligado al éxito real y protegido frente a duplicados en la implementación que se use.
Redirige solo cuando se haya confirmado el éxito. Si el sistema indica un error, explícalo y permite corregirlo sin que el usuario crea que el mensaje se ha recibido. Un temporizador que abre siempre una página de agradecimiento puede ocultar precisamente el fallo que tenemos que encontrar.
Un ejemplo de diferencia que puede explicarse
Imagina una prueba controlada en la que se puede seguir cada intento. Se hace clic en el botón 40 veces. Diez intentos se detienen en la validación, cinco tienen un error de envío y 25 crean solicitudes aceptadas y registradas. En este ejemplo, las 25 llegan también al equipo.
| Lo que contamos en la prueba | Número |
|---|---|
| Clics en el botón | 40 |
| Fallos de validación | 10 |
| Errores de envío | 5 |
| Solicitudes aceptadas y registradas | 25 |
Si cada clic se declara como una solicitud correcta, el recuento queda 15 por encima, es decir, un 60 % más que las 25 solicitudes recibidas de verdad. Es un problema de definición y de implementación de la medición.
Cuando contamos el paso equivocado.
Prueba controlada ficticia: cada clic tiene un resultado identificado.
CLICS EN EL BOTÓN EN LA PRUEBA
40
Fallos de validación
−10
Errores de envío
−5
Solicitudes aceptadas y registradas
=25
Declarar 40 solicitudes en lugar de 25 sobrestima el total en 15, es decir, un 60 %.
Ejemplos ilustrativos, no resultados de un cliente de NOT MORE.
Los informes reales pueden diferir por otros motivos: periodos de informe, zonas horarias, filtros, atribución o condiciones de recogida de datos. No apliques la explicación de este ejemplo a cada diferencia. Sigue casos identificables a lo largo de todo el recorrido.
Probar qué pasa cuando algo sale mal
Un solo envío correcto no cubre todas las situaciones relevantes. La prueba de aceptación tiene que incluir comportamientos que pueden darse en un uso normal.
| Situación | Resultado esperado en el ejemplo |
|---|---|
| Datos válidos y envío correcto | Una solicitud registrada, una confirmación correcta y la señal definida |
| Campo obligatorio sin rellenar | Una explicación clara; ninguna señal de éxito |
| Error del servicio de envío | Error visible; ninguna confirmación falsa |
| Doble clic o recarga | Comprobar que la misma acción no se duplica |
| Solicitud registrada, notificación fallida | La solicitud sigue siendo recuperable y hay una forma de gestionar el error |
Repite los casos relevantes en móvil y en ordenador. Con formularios externos, sistemas de reserva o pagos, comprueba el paso de un sistema a otro. Una reserva puede exigir la confirmación de un hueco disponible; un pago puede pasar por varios estados. Define la conversión según el proceso real.
Dónde comprobamos la señal y dónde comprobamos la solicitud
Las herramientas de depuración muestran qué eventos se envían y qué contienen. DebugView en GA4, por ejemplo, permite revisar los eventos de un dispositivo con el modo de depuración activado. Documentación de DebugView (en inglés)
En paralelo, comprueba la solicitud donde se registra y donde la gestiona el equipo. Un evento de analítica no confirma la entrega de un email. Un email recibido no confirma que un evento de analítica se haya enviado una sola vez.
Las pruebas tienen que respetar las condiciones de recogida, incluidas las opciones de consentimiento configuradas. No esperes que cada solicitud aparezca igual en cada herramienta. Mantén los datos de contacto fuera de los nombres de eventos y de las URL de las páginas.
El seguimiento conecta la acción con el informe
El seguimiento registra los eventos relevantes y los envía a las herramientas de analítica o de publicidad: visitas, inicios de formulario, solicitudes confirmadas y pedidos. Lo que significa un evento, desde dónde se envía y en qué condiciones puede usarse influyen en los informes.
Una etiqueta es un componente de código que participa en esta medición. Instalarla es solo una parte de la implementación. Tenemos que saber qué acción la activa, qué información envía, a quién y con qué permisos.
El seguimiento en el navegador y el seguimiento en el servidor
Con el seguimiento del lado del cliente, un código se ejecuta en el navegador del visitante y envía eventos. Con el etiquetado del lado del servidor, un servidor que controla la organización recibe y procesa los datos antes de enviarlos a los destinos configurados. El navegador puede seguir siendo la fuente original. Google: introducción al etiquetado del lado del servidor (en inglés)
| Variante | Dónde empieza el evento | Lo que hay que entender |
|---|---|---|
| Lado del cliente | El código del navegador | El envío depende de que el código se ejecute y de las condiciones del navegador |
| Navegador y servidor de etiquetado | El navegador envía al servidor, que procesa y reenvía | El servidor añade control, pero tiene que recibir el evento |
| De servidor a servidor | La aplicación o el CRM confirma una acción y la envía mediante una integración | Puede declarar un resultado confirmado; la conexión con la visita y el anuncio tiene que configurarse aparte |
Si la única fuente es un script que nunca se ejecutó, mover su destino a tu propio subdominio no recrea el evento que falta. En cambio, una integración que se activa con una solicitud registrada puede apoyarse en la confirmación de la aplicación sin esperar a que cargue una página de agradecimiento. Son arquitecturas distintas, aunque a las dos se las llame «seguimiento en servidor».
¿Dónde empieza el evento?
Tres variantes esquemáticas. El camino cambia; el resultado tiene que comprobarse.
LADO DEL CLIENTE
- Navegador
- Envío desde la página
- Plataforma
NAVEGADOR + SERVIDOR
- Navegador
- Servidor de etiquetado
- Plataforma
DE SERVIDOR A SERVIDOR
- Aplicación/CRM
- Integración
- Plataforma
Los permisos se respetan en todo el camino. El servidor no recrea automáticamente un evento que no recibe.
El Measurement Protocol de GA4 (en inglés) permite que los sistemas envíen eventos directamente. Google lo presenta como un complemento de la recogida existente; usarlo solo puede producir informes parciales. Enviar un evento mediante una API no aporta automáticamente información completa sobre la sesión, la fuente y el recorrido.
Por qué recomendamos valorar un componente del lado del servidor
En un proyecto cuyas decisiones de promoción dependen de las solicitudes y las ventas, merece la pena preguntarse si los resultados confirmados en el CRM pueden alimentar la medición. Nuestra recomendación parte del problema concreto: qué falta, dónde se pierde la información y qué decisión estaría mejor fundamentada.
Una implementación bien diseñada puede validar los datos antes de enviarlos, controlar qué sale hacia cada destino y conectar eventos comerciales que se producen después de una visita. Por ejemplo, puede distinguir una solicitud nueva de una solicitud que el equipo cualifica después.
Compara estas ventajas con la configuración, el alojamiento, la seguridad, el seguimiento, el mantenimiento y la responsabilidad ante un incidente. En un formulario sencillo, corregir el evento y probar el consentimiento puede resolver el problema inicial. Una tienda o un proceso de venta con varios sistemas puede sacar más partido de un componente en servidor.
En NOT MORE., justificamos esta elección con un plan de medición y criterios de comprobación. No prometemos que instalar un servicio recupere cada conversión ni que suba automáticamente el ROAS.
Por qué los navegadores pueden mostrar partes distintas del mismo recorrido
Una cookie guarda información en el navegador, por ejemplo para mantener una sesión o reconocer una visita. «Propia» y «de terceros» describen su contexto respecto a la web. Ser propia no hace automáticamente que una cookie sea necesaria ni que esté exenta de consentimiento; cuenta su finalidad.
| Entorno | Ejemplo de protección o de ajuste | Efecto posible en la medición |
|---|---|---|
| Safari / WebKit | Intelligent Tracking Prevention limita el seguimiento entre webs y algunas formas de almacenamiento | La continuidad de los identificadores y la conexión entre visitas pueden quedar limitadas |
| Firefox | La protección total de cookies separa el almacenamiento de cookies de cada web | Un mismo mecanismo de terceros no puede seguir libremente a una persona de una web a otra |
| Chrome | Los usuarios pueden permitir o bloquear las cookies de terceros; en navegación privada están bloqueadas por defecto | El comportamiento depende de los ajustes y del modo de navegación |
Son ejemplos tomados de la documentación de los fabricantes de navegadores, no una lista completa de todas las versiones y dispositivos. WebKit (en inglés), Firefox (en inglés), Chrome (en inglés)
Evita las afirmaciones generales de que todas las cookies han desaparecido o de que la misma persona se reconoce igual en todas partes. Las extensiones de bloqueo, los datos borrados, los cambios de dispositivo, las caídas de conexión o una salida antes de que se envíe un evento pueden influir. Revísalos como posibilidades en lugar de usarlos para explicar cada diferencia.
El consentimiento en una web no obliga a un navegador a permitir un mecanismo que bloquea. Del mismo modo, que un navegador permita un envío no establece el permiso para usar los datos con cualquier finalidad.
Normas europeas, políticas de Google y banner de consentimiento cumplen funciones distintas
En Europa, valora tanto las normas sobre el almacenamiento de información en un dispositivo o el acceso a ella como, cuando corresponda, la protección de los datos personales. Obtén el consentimiento antes de usar las cookies que lo exigen; las funciones estrictamente necesarias tienen excepciones. Explica con claridad las finalidades y haz fácil la retirada. Tu Europa: recomendaciones oficiales sobre las cookies (en inglés)
Las reglas de los navegadores son decisiones técnicas de sus fabricantes. Las políticas de Google son condiciones de uso de sus productos. Los requisitos europeos forman el marco jurídico. En la implementación, los tratamos por separado y comprobamos su aplicación con el delegado de protección de datos o el especialista jurídico del proyecto.
Para los usos de medición y publicidad afectados que implican a personas del Espacio Económico Europeo, Google exige el consentimiento aplicable y las señales correspondientes. Rumanía forma parte del EEE, igual que España. Este requisito afecta a los productos de Google y puede aplicarse aunque el visitante use un navegador distinto de Chrome. Requisitos de Google para el tráfico del EEE (en inglés)
La CMP recoge la elección. El modo de consentimiento la transmite.
Una CMP (plataforma de gestión del consentimiento) gestiona la interfaz y las preferencias del visitante. El modo de consentimiento transmite la elección a las etiquetas de Google y adapta su comportamiento. Instalar un banner no demuestra que la conexión entre ambos funcione.
En una configuración de etiquetado del lado del servidor de Google, las señales de consentimiento también tienen que llegar al componente en servidor. Trasladar el procesamiento no pasa por encima de las preferencias de la persona. Comprueba por separado cómo respetan esas preferencias las integraciones de otros proveedores. El modo de consentimiento en Tag Manager del lado del servidor (en inglés)
El modo de consentimiento v2 incluye señales distintas, que no reducimos a un único «cookies aceptadas»:
| Señal | Lo que cubre |
|---|---|
| analytics_storage | El almacenamiento asociado a la medición estadística |
| ad_storage | El almacenamiento asociado a la publicidad |
| ad_user_data | El envío de datos de usuario a Google con fines publicitarios |
| ad_personalization | El uso para personalizar los anuncios |
Define el estado inicial antes de las operaciones que controlan estas señales y actualízalo después de la elección del visitante. Prueba también qué pasa cuando cambia de opinión. Los nombres de las señales son técnicos; la explicación que ve el visitante tiene que ser comprensible. Configurar el modo de consentimiento (en inglés)
El modo básico y el avanzado producen comportamientos distintos
| Implementación de Google | Sin el consentimiento correspondiente | Después del consentimiento |
|---|---|---|
| Básico | Las etiquetas afectadas se bloquean y no envían datos a Google | Las etiquetas se cargan y funcionan según las preferencias expresadas |
| Avanzado | Las etiquetas se cargan en el estado configurado y pueden enviar señales limitadas, sin cookies, para las finalidades rechazadas | El comportamiento se adapta a los permisos concedidos |
Esta tabla resume el mecanismo de Google; los datos exactos dependen de la etiqueta y de la configuración. «Sin cookies» no significa «no se transmite nada». Valora el modo avanzado frente a los datos, las finalidades y los requisitos del proyecto. Que esté disponible en una plataforma no establece que una implementación sea jurídicamente adecuada. Modo básico y modo avanzado (en inglés)
El banner es solo el comienzo de la comprobación.
La implementación tiene que respetar la elección del visitante.
ELECCIÓN
- ¿Qué permite la persona?
- Aceptar o rechazar por finalidad
- La posibilidad de cambiar sus preferencias
COMPORTAMIENTO
- ¿Qué reglas aplicamos?
- Señales de consentimiento enviadas a las etiquetas
- Preferencias respetadas también en el servidor
COMPROBACIÓN
- ¿Qué datos se envían de verdad?
- Solicitudes de red y datos transmitidos
- Resultado en cada destino
Esquema ilustrativo. El modo de consentimiento adapta el comportamiento; comprueba cada implementación.
Eventos observados, datos modelizados y resultados en el CRM
Algunos informes de Google usan modelización para estimar resultados cuando la observación directa está incompleta. La disponibilidad depende del producto, de la configuración, del volumen de datos y de la elegibilidad. Google Ads documenta la modelización de conversiones, mientras que GA4 documenta por separado la modelización del comportamiento. Activar el modo de consentimiento no garantiza las mismas estimaciones en todas las cuentas. La modelización de conversiones en Google Ads (en inglés) La modelización del comportamiento en GA4 (en inglés)
Mantén separadas las funciones: el CRM confirma las solicitudes que contiene; la herramienta de analítica describe los eventos y los recorridos disponibles; las plataformas publicitarias atribuyen los resultados según sus propias reglas y pueden incluir modelización. Una estimación no es una solicitud identificable adicional que el equipo debería esperar encontrar en su bandeja de entrada.
Por eso, el objetivo de la comprobación es explicar las diferencias y comprobar que cada sistema es correcto para su función. Forzar que todos los totales cuadren puede ocultar precisamente esas diferencias de definición.
Varias fuentes de eventos exigen deduplicación
Si el mismo pedido o la misma solicitud se envía por varios caminos, diseña la deduplicación para que el destino reconozca una sola acción. Acordad los identificadores y las reglas de cada destino, también para los reintentos. Google Ads documenta los identificadores de transacción únicos para las compras; reutilizar un identificador para pedidos distintos puede hacer que se cuente de menos. El ID de transacción en Google Ads (en inglés)
No suponemos que dos integraciones instaladas en paralelo estén coordinadas automáticamente. Comprobamos la extensión de la plataforma, las etiquetas del navegador, el servidor y las importaciones del CRM. Una solicitud cualificada más tarde es un paso distinto: defínela como tal, en lugar de mezclarla con la solicitud inicial.
Las conversiones avanzadas son un mecanismo distinto. Pueden completar la medición de Google con datos que aporta el cliente, transformados mediante una función hash para establecer correspondencias. El hash transforma un valor, como una dirección de email, en una representación calculada; no elimina todo vínculo con la persona. No es lo mismo que alojar un servidor de etiquetado. Acerca de las conversiones avanzadas (en inglés)
Este mecanismo no autoriza a enviar todos los campos del formulario. Comprueba la elegibilidad, la información que se da a las personas, el consentimiento necesario y los campos que permite la integración. Google restringe las categorías sensibles. Los datos de contacto solo tienen cabida en las funciones y los campos previstos para ellos, nunca en nombres de eventos ni en URL arbitrarias. Políticas de Google sobre los datos de clientes (en inglés)
Otro ejemplo: la solicitud existe, pero el informe ve menos
Tomemos una segunda prueba ficticia, distinta del ejemplo de los 40 clics. Hay 100 solicitudes únicas registradas correctamente en el mismo periodo, con una implementación en modo básico. Treinta no tienen el consentimiento necesario para el envío al destino que se valora. De las 70 restantes, diez eventos fallan por un problema técnico identificado.
| Nivel en el ejemplo | Número | Lo que significa |
|---|---|---|
| Solicitudes registradas | 100 | Resultado confirmado en el sistema de la empresa |
| Solicitudes con los permisos necesarios para el destino | 70 | Subconjunto de las 100 |
| Eventos observados en el destino | 60 | Subconjunto de las 70, antes de la corrección técnica |
Los números no se suman: son niveles anidados del mismo conjunto. En este ejemplo, no incluimos ni modelización, ni atribución a los anuncios, ni desfase temporal. Los porcentajes se han inventado para la demostración; no son estimaciones de las tasas de consentimiento del mercado.
Una integración en servidor solo podría ayudar a recuperar los diez eventos que faltan por motivos técnicos si recibe la confirmación, tiene el permiso aplicable y trata de verdad la causa. Mover código a un servidor no hace elegibles las 30 solicitudes sin consentimiento. Y que llegue un evento no demuestra qué anuncio provocó la solicitud.
La solicitud existe. ¿Qué puede ver el informe?
Ejemplo ficticio en modo básico. Son subconjuntos; no los sumes.
Conjunto de partida
100 Solicitudes registradas
De las 100
70 Con los permisos necesarios
De las 70
60 Eventos observados
30 / sin el consentimiento necesario El servidor no cambia los permisos.
10 / problema técnico Comprobamos la causa y la corrección adecuada.
Mismo periodo, solicitudes únicas. Sin modelización ni atribución a los anuncios; no son referencias de mercado.
Lo que también comprobamos en una implementación completa
Tras la prueba del formulario viene la prueba de las condiciones de medición. Elegimos los casos relevantes para la arquitectura y comprobamos el resultado en el destino:
- La primera visita, antes de cualquier elección explícita: qué se carga, qué se almacena y qué se transmite según la variante aprobada.
- El rechazo, la aceptación parcial y la aceptación: si cada finalidad cambia de verdad el comportamiento de las etiquetas afectadas.
- La retirada del consentimiento: si las operaciones posteriores respetan el cambio, también en el servidor.
- Navegadores y dispositivos representativos: si las diferencias pueden explicarse y si el formulario sigue funcionando.
- La confirmación de la aplicación, la recarga de la página y los reintentos técnicos: si se cuenta una sola acción de negocio, como estaba previsto.
- Los formularios externos, los pagos o los sistemas de reserva: si se conserva el contexto necesario y permitido.
- Los eventos de cualificación, venta o cancelación: si la fase, el valor, la moneda y la fecha reflejan el proceso real.
Documenta también lo que no puede observarse. Una buena implementación distingue la falta de permiso, los límites técnicos, los errores de configuración y las reglas de los informes. Cada uno pide una respuesta distinta.
Lo que entregamos después de la comprobación
El equipo tiene que poder ver qué representa cada evento, cuándo se activa, adónde llega la solicitud y cómo reconocer un error. Documentamos los casos probados y los límites que se mantienen.
Después acordamos el resultado que se usa para valorar y optimizar la campaña. Una acción intermedia puede ser útil, pero tiene que identificarse e interpretarse como tal. La conexión con las solicitudes cualificadas y las ventas se establece por separado, según los datos y la implementación disponibles.
En NOT MORE., la medición forma parte de la preparación de la campaña. Volvemos a comprobar el recorrido después de los cambios relevantes en formularios, páginas o integraciones, para que el informe siga describiendo el proceso real.
Lo que puedes preguntar en la próxima comprobación
- ¿Cuál es exactamente la acción a la que llamamos conversión?
- ¿Podemos seguir un envío de prueba hasta que se registra y el equipo se hace cargo?
- ¿Qué pasa en el informe cuando el formulario falla o se recarga la página?
¿El informe y las solicitudes recibidas no cuadran?
Parte de las definiciones y de algunos envíos de prueba. Podemos establecer dónde nace la diferencia y qué hay que corregir antes de que esas cifras orienten la próxima decisión de presupuesto.
Quién pone en marcha la medición y quién la sigue después del lanzamiento
NOT MORE. puede definir el plan de medición, configurar las herramientas, desarrollar las integraciones y probar el recorrido acordado, incluidos componentes del lado del servidor cuando corresponda. La arquitectura se deriva de la necesidad, de los datos disponibles, de los recursos y de las condiciones de uso. Los límites de los navegadores y del consentimiento siguen siendo relevantes, se ejecute donde se ejecute una parte de la implementación.
Tu equipo confirma el significado comercial de cada evento, la fuente de los datos y las responsabilidades de acceso y gestión. Las decisiones jurídicas y de protección de datos se validan con los especialistas competentes; la implementación técnica sigue esas decisiones. Cuando intervienen otros proveedores, establecemos quién repara cada parte de la cadena.
En la entrega, probamos los recorridos normales, el rechazo del consentimiento, los errores y los duplicados relevantes para la configuración. Si también nos encargamos del seguimiento, precisamos las alertas y las comprobaciones, su frecuencia y quién interviene. El informe explica lo que se observa, lo que falta y qué conclusiones permiten los datos. Una implementación correcta sostiene el análisis; no promete una visibilidad completa de cada usuario.
Partir del problema que ves, sin diagnóstico técnico
No tienes que identificar la etiqueta, la integración o el navegador que causa una diferencia. Parte de lo que observas: solicitudes que faltan, totales distintos o una confirmación poco clara. Definimos las comprobaciones y los accesos necesarios, y después explicamos las conclusiones frente a la pregunta de negocio. Si hace falta un análisis o una implementación aparte, acordamos antes su alcance y su coste. La complejidad técnica tiene que convertirse en decisiones que puedas valorar.