La decisión en una tabla
| Vía | Dónde nace el dato | Cuándo conviene | Control crítico |
|---|---|---|---|
| Google tag / gtag.js | Página o aplicación web | Sitio pequeño o implementación directa | Orden de carga, consentimiento y presencia del dato en el evento |
| Google Tag Manager web | Data layer, variables o formulario | Equipo que ya opera un contenedor y necesita versionar cambios | Permisos, triggers y evitar duplicar gtag.js con GTM |
| Google Tag Manager server-side | Solicitud que llega desde web/app/backend | Necesitas filtrar, enriquecer o distribuir el payload en servidor | El contenedor web o cliente emisor sigue siendo necesario |
| Measurement Protocol | Sistema propio o CRM | Evento posterior a la sesión o interacción offline | Hasheo previo, session ID, timestamp y límites de la API |
Esta tabla no es una jerarquía de madurez. Un sitio con GTM bien gobernado puede ser más confiable que una arquitectura server-side improvisada.
gtag.js: el camino directo
La documentación pública de Google Analytics permite configurar la recolección de datos proporcionados por el usuario desde el Google tag. Es apropiado cuando el sitio ya tiene una capa de eventos clara y no necesita un gestor de etiquetas.
Controles mínimos:
- captura el dato en el momento de una acción definida, no en todas las páginas;
- confirma que el consentimiento relevante ya fue resuelto;
- normaliza según las instrucciones de Google;
- deja que la función aplique SHA-256 o envía el hash correcto;
- verifica que no se envíen campos vacíos, texto de prueba ni PII en claro;
- registra qué evento y destino justifican la recolección.
GTM web: más operación, no necesariamente más señal
GTM ayuda cuando distintos equipos publican cambios, cuando el dato vive en el data layer o cuando necesitas separar variables, triggers y tags. No mejora el match por el solo hecho de usar un contenedor: la calidad sigue dependiendo del dato, del consentimiento y del evento que lo activa.
Antes de publicar, usa una matriz por evento:
| Pregunta | Ejemplo de respuesta que sí sirve |
|---|---|
| ¿Qué evento dispara el envío? | generate_lead después de la confirmación del formulario |
| ¿Qué campo está disponible? | Email normalizado en el data layer |
| ¿Quién puede leerlo? | Solo el tag de destino autorizado |
¿Qué ocurre si se niega ad_user_data? | El dato no se envía para publicidad |
| ¿Cómo se prueba? | Preview, diagnósticos del destino y fixture sin PII real |
No mezcles una implementación directa de gtag.js con un Google tag equivalente en GTM sin comprobar el resultado: el riesgo es duplicar eventos y no ganar cobertura.
sGTM: transporte y control, no captura automática
El contenedor server-side recibe una solicitud y puede validarla, redactarla o enriquecerla antes de reenviarla. sGTM no captura datos proporcionados por el usuario por sí solo. Primero debe existir un emisor —contenedor web, Google tag, app o backend— que envíe el dato de manera permitida.
La opción server-side tiene sentido cuando necesitas:
- aplicar una política central de qué campos salen a cada proveedor;
- agregar información de un backend que el navegador no tiene;
- reducir la exposición directa del navegador a múltiples destinos;
- centralizar auditoría, redacción y controles operativos.
No es una excusa para recolectar más datos. El servidor debe aplicar minimización, retención y consentimiento igual que el cliente. Revisa la guía de server-side tagging para infraestructura y sus límites.
Diseña una recolección de datos que tu equipo pueda sostener
Revisamos dónde nace cada dato y qué ruta —tag, GTM, servidor o backend— mantiene el control sin sumar complejidad innecesaria.
- 1
Diagnóstico gratuito de tu stack GMP
Un especialista revisa tu implementación actual (GA4, GTM, DV360, Ads) y te dice qué priorizar primero.
- 2
Plan de acción a medida
Sales de la llamada con next steps concretos para tu cuenta, no con una plantilla genérica.
- 3
Sin compromiso, sin venta forzada
Hablas con un especialista técnico, no con un vendedor. Si no encajamos, te lo decimos.
Respuesta a la brevedad
Revisar mi recolección de datos
Completa el form y coordinamos una asesoría sobre tu caso.
Cargando el formulario seguro de HubSpot…
No pudimos cargar el formulario. Puedes escribirnos a hola@leadaki.com .
Este formulario lo provee HubSpot y los datos que envíes se procesan allí. Consulta nuestra política de privacidad .
Sin compromiso · Google Marketing Platform Sales Partner
Measurement Protocol: eventos que nacen fuera del navegador
Measurement Protocol permite enviar eventos a un stream Web o App desde un sistema propio. Es útil para una venta cerrada por teléfono o para una interacción CRM que complementa la sesión. Google documenta requisitos técnicos como session_id, timestamp_micros y engagement_time_msec según el caso.
La secuencia segura es:
- almacenar la relación entre lead, sesión y evento en el CRM;
- filtrar el evento según consentimiento y propósito;
- normalizar y hashear UPD en tu sistema;
- enviar solo los campos necesarios, con timestamp válido;
- revisar respuestas y errores de la API;
- validar el evento en GA4 sin intentar usarlo como reemplazo automático de la importación de Ads.
Qué vía no resuelve qué problema
- gtag.js no arregla un consentimiento ausente.
- GTM no convierte un formulario sin dato en una fuente de UPD.
- sGTM no reemplaza el contenedor web ni obtiene PII mágicamente.
- Measurement Protocol no transforma un evento offline en una identidad de reporting.
- Ninguna vía garantiza un match, una atribución completa o una mejora de performance.
Siguiente paso
Dibuja el origen y el destino de cada campo antes de elegir tecnología. Si la duda es de identidad, compara User-ID, UPD, Enhanced Conversions y Customer Match; si el evento nace en un CRM, cruza esta decisión con medición de leads offline.