De analytics.js a GA4: cómo ha cambiado la medición web en Google Analytics

¿Qué era analytics.js?

analytics.js era la librería JavaScript utilizada por Universal Analytics para recopilar información de un sitio web y enviarla a Google Analytics. Su implementación clásica se veía de esta forma:

<script>

(function(i,s,o,g,r,a,m){i\['GoogleAnalyticsObject'\]=r;i\[r\]=i\[r\]||function(){

(i\[r\].q=i\[r\].q||\[\]).push(arguments)},i\[r\].l=1\*new Date();

a=s.createElement(o),m=s.getElementsByTagName(o)\[0\];

a.async=1;

a.src=g;

m.parentNode.insertBefore(a,m)

})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

ga('create', 'UA-XXXXX-Y', 'auto');

ga('send', 'pageview');

</script>

En lenguaje más sencillo, este código hacía tres cosas principales:

1. Cargaba la librería analytics.js de forma asíncrona.
2. Creaba un rastreador asociado a una propiedad de Universal Analytics.
3. Enviaba una vista de página cuando el usuario cargaba el sitio.

La línea más representativa era esta:

ga('create', 'UA-XXXXX-Y', 'auto');

Con ella se creaba un rastreador usando un identificador de propiedad tipo UA-XXXXX-Y. El parámetro auto indicaba que Google Analytics debía configurar automáticamente el dominio de la cookie, algo útil cuando se quería medir el sitio principal y sus subdominios bajo una misma lógica de sesión.

Después aparecía esta instrucción:

ga('send', 'pageview');

Esta línea enviaba un hit de vista de página. En Universal Analytics, un hit era una unidad de información enviada a Google Analytics. Podía tratarse de una vista de página, un evento, una transacción, una interacción social, entre otros tipos.

Por qué analytics.js ya no debe ser la base de una implementación nueva

El problema actual no es que analytics.js haya sido una mala tecnología. Al contrario, fue una pieza muy importante para la analítica web durante años. El problema es que pertenece a Universal Analytics, un modelo que ya fue reemplazado por Google Analytics 4.

Por eso, si hoy estás construyendo un sitio web, una tienda en línea, un blog, una landing page o una estrategia de medición digital, no deberías iniciar con analytics.js ni con propiedades tipo UA-XXXXX-Y.

La implementación actual debe partir de una propiedad GA4, cuyo identificador suele tener un formato como este:

G-XXXXXXXXXX

Y la instalación directa con la etiqueta de Google se ve de esta manera:

<!-- Google tag (gtag.js) -->

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>

<script>

window.dataLayer = window.dataLayer || \[\];

function gtag(){dataLayer.push(arguments);}

gtag('js', new Date());

gtag('config', 'G-XXXXXXXXXX');

</script>

Este fragmento ya no utiliza ga(), sino gtag(). Esa diferencia es clave porque refleja el cambio de Universal Analytics a la nueva plataforma de etiquetado de Google.

¿Qué es gtag.js?

gtag.js es el framework JavaScript que permite agregar etiquetas de Google directamente en un sitio web. Su función es enviar datos hacia productos como Google Analytics 4 y Google Ads.

Una de sus ventajas es que permite instalar una sola etiqueta de Google y enviar información a distintos destinos dentro del ecosistema de Google. Por ejemplo, puedes usarla para medir visitas, eventos, conversiones y rendimiento publicitario.

Sin embargo, gtag.js exige mayor intervención técnica. Si necesitas personalizar eventos, parámetros, conversiones o configuraciones avanzadas, debes modificar código directamente en el sitio. Por eso, aunque gtag.js es válido, en muchos proyectos resulta más práctico usar Google Tag Manager.

Google Tag Manager: una opción más flexible para marketing y medición

Google Tag Manager es un sistema de administración de etiquetas que permite instalar, modificar y controlar scripts de medición desde una interfaz web, sin tener que editar el código del sitio cada vez.

Esto es especialmente útil para equipos de marketing, agencias, analistas digitales y negocios que manejan varias plataformas al mismo tiempo: Google Analytics, Google Ads, Meta Pixel, TikTok Pixel, LinkedIn Insight Tag, herramientas de heatmaps, formularios, conversiones personalizadas y scripts de terceros.

Con Tag Manager puedes administrar:

1. Etiquetas.
2. Activadores.
3. Variables.
4. Eventos personalizados.
5. Conversiones.
6. Píxeles publicitarios.
7. Implementaciones de consentimiento.
8. Etiquetado client-side y server-side.

En términos prácticos, si un sitio web solamente necesita medir visitas básicas, puede funcionar con la etiqueta de Google instalada directamente. Pero si el proyecto necesita una estrategia seria de medición, remarketing, conversiones, ecommerce o campañas pagadas, Google Tag Manager suele ser una mejor opción.

El cambio más importante: de hits a eventos

Una de las diferencias más importantes entre Universal Analytics y GA4 es el modelo de datos.

Universal Analytics se basaba en tipos de hit. Por ejemplo:

pageview

event

transaction

social

timing

GA4, en cambio, organiza la medición alrededor de eventos. Prácticamente todo puede ser un evento:

page\_view

scroll

click

file\_download

view\_item

add\_to\_cart

begin\_checkout

purchase

sign\_up

generate\_lead

login

Esto permite una medición más flexible, pero también exige mayor orden. En GA4 no basta con “medir todo”. Lo correcto es definir una arquitectura de eventos alineada con los objetivos del negocio.

Por ejemplo, para un blog podrías medir:

gtag('event', 'newsletter\_signup', {

method: 'footer\_form'

});

Para una tienda en línea podrías medir:

gtag('event', 'add\_to\_cart', {

currency: 'MXN',

value: 599.00,

items: \[

{

item\_name: 'Florero de vidrio reciclado',

item\_id: 'FLR-001',

price: 599.00,

quantity: 1

}

\]

});

Y para una landing page podrías medir:

gtag('event', 'generate\_lead', {

form\_name: 'cotizacion\_evento',

lead\_type: 'whatsapp'

});

La clave está en que cada evento tenga intención analítica. Un evento debe ayudarte a responder preguntas de negocio, no solamente llenar reportes.

Eventos automáticos, recomendados y personalizados

En GA4 existen distintos niveles de eventos.

Los eventos automáticos se recopilan cuando instalas correctamente la etiqueta. Por ejemplo, first_visit, session_start o user_engagement.

La medición mejorada permite capturar interacciones comunes como scroll, clics salientes, búsquedas internas, descargas de archivos o reproducciones de video, dependiendo de la configuración del flujo de datos.

Los eventos recomendados son nombres sugeridos por Google para casos comunes de negocio. Por ejemplo, purchase, login, sign_up, generate_lead, view_item o add_to_cart.

Los eventos personalizados son aquellos que defines cuando no existe un evento automático o recomendado que represente correctamente la acción que quieres medir.

Esta estructura obliga a pensar mejor la analítica. Antes de implementar eventos personalizados, conviene revisar si ya existe un evento recomendado. Esto ayuda a mantener una medición más limpia y compatible con los reportes de GA4.

¿Qué pasó con las cookies?

Las cookies siguen siendo parte importante de la medición digital, pero el panorama cambió. Hoy la medición no puede depender únicamente de cookies, porque los navegadores, las regulaciones de privacidad, los bloqueadores y las preferencias de consentimiento del usuario afectan la recopilación de datos.

GA4, la etiqueta de Google y Google Tag Manager trabajan dentro de un ecosistema donde el consentimiento tiene más peso. Por eso, una implementación moderna no debería limitarse a “pegar el código de Analytics”. También debe considerar:

1. Banner de consentimiento.
2. Consent Mode.
3. Configuración de cookies.
4. Reglas de privacidad.
5. Calidad de eventos.
6. Exclusión de tráfico interno.
7. Validación con DebugView.
8. Pruebas con Tag Assistant.
9. Documentación del plan de medición.

La analítica moderna no consiste solamente en recopilar datos. Consiste en recopilar datos útiles, permitidos, consistentes y accionables.

¿Qué es Measurement Protocol en GA4?

Measurement Protocol permite enviar eventos directamente a los servidores de Google Analytics mediante solicitudes HTTP. Esto es útil cuando necesitas complementar la medición del navegador con eventos del servidor o interacciones offline.

Por ejemplo, podrías usar Measurement Protocol para enviar eventos relacionados con:

1. Confirmaciones de pago desde backend.
2. Leads validados en CRM.
3. Reservas confirmadas fuera del sitio.
4. Interacciones offline.
5. Procesos server-to-server.
6. Eventos que no dependen directamente del navegador.

Sin embargo, Measurement Protocol no debe entenderse como un reemplazo de la etiqueta de Google, gtag.js o Google Tag Manager. Su mejor uso es complementar la medición existente, no sustituirla.

Client-side tagging vs server-side tagging

Tradicionalmente, la mayoría de las etiquetas se ejecutaban en el navegador del usuario. Esto se conoce como client-side tagging. En este modelo, cuando una persona visita una página, el navegador carga los scripts de medición y envía solicitudes a Google Analytics, plataformas publicitarias u otras herramientas.

El server-side tagging agrega una capa intermedia. En vez de que todos los datos salgan directamente del navegador hacia múltiples proveedores, pasan primero por un servidor controlado por la empresa o el equipo técnico. Desde ahí se procesan, filtran y distribuyen a las plataformas correspondientes.

Esto puede ayudar a mejorar control, gobernanza, rendimiento y calidad de datos. Aun así, no es una solución mágica. Requiere configuración, mantenimiento, infraestructura, costos y criterio técnico.

Para muchos sitios pequeños, una buena implementación con Google Tag Manager del lado del cliente es suficiente. Para ecommerce, medios, SaaS o negocios con alta inversión publicitaria, server-side tagging puede convertirse en una evolución natural.

¿Google Analytics afecta la velocidad del sitio?

Sí, cualquier script externo puede influir en el rendimiento de una página. Esto aplica para Google Analytics, Tag Manager, píxeles publicitarios, widgets de chat, mapas, videos embebidos, librerías externas y herramientas de terceros.

El punto correcto no es decir que “Google Analytics vuelve lento un sitio” de forma absoluta, sino entender que cada etiqueta genera solicitudes, procesamiento y carga adicional. Por eso conviene auditar regularmente qué scripts se cargan, cuándo se cargan y si realmente son necesarios.

Buenas prácticas:

1. Evitar etiquetas duplicadas.
2. No instalar GA4 directo y también por GTM si ambos envían los mismos eventos.
3. Revisar que no existan eventos duplicados.
4. Usar Tag Assistant y DebugView.
5. Cargar solo etiquetas necesarias.
6. Documentar cambios.
7. Mantener un plan de medición.
8. Revisar Core Web Vitals cuando se agregan scripts externos.

Una implementación limpia mide mejor y afecta menos el rendimiento.

Ejemplo de implementación moderna básica en GA4

Si el proyecto es sencillo, puedes instalar la etiqueta de Google directamente:

<!-- Google tag (gtag.js) -->

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>

<script>

window.dataLayer = window.dataLayer || \[\];

function gtag(){dataLayer.push(arguments);}

gtag('js', new Date());

gtag('config', 'G-XXXXXXXXXX');

</script>

Después puedes agregar eventos cuando una acción importante ocurre:

gtag('event', 'generate\_lead', {

method: 'whatsapp\_button',

page\_location: window.location.href

});

Pero si el sitio necesita medir campañas, formularios, botones, conversiones, ecommerce o múltiples plataformas, lo más recomendable es utilizar Google Tag Manager y centralizar ahí la administración de etiquetas.

Conclusión

analytics.js fue una pieza fundamental en la historia de Google Analytics, pero ya no representa el presente de la medición digital. Su lugar pertenece a Universal Analytics, mientras que el entorno actual gira alrededor de GA4, la etiqueta de Google, gtag.js, Google Tag Manager, eventos, consentimiento y medición más orientada a privacidad.

La analítica web moderna ya no debe verse como un script pegado en el sitio. Debe entenderse como una infraestructura de medición, negocio y mejora continua.