Blog
Todos los eventos de GA4 que ve tu contenedor de servidor, y de dónde sale cada uno
Publicado · Actualizado · 6 min de lectura
Enrutar GA4 a través de un contenedor de servidor no cambia qué eventos existen. Lo que cambia es que por fin puedes ver cuáles llegan: la página del contenedor cuenta cada nombre de evento que reenvía. Esa lista sorprende en las dos direcciones: aparecen eventos que nadie configuró y faltan otros que se esperaban. Ambas cosas tienen explicaciones sencillas en cuanto sabes de dónde sale cada evento.
Cuatro eventos que la etiqueta de Google envía en cualquier propiedad
En el momento en que la etiqueta de Google carga con tu ID de medición, fluyen cuatro eventos sin ningún ajuste detrás. Nada en Analytics los desactiva, y nada en tu contenedor tiene que pedirlos.
- page_view: uno por carga de página, o por cambio de ruta en una aplicación de página única cuando la opción «cambios de página» del flujo está activada.
- session_start: el primer hit de una sesión nueva. Una sesión termina tras treinta minutos de inactividad, así que un visitante que vuelve dos horas después inicia otra.
- first_visit: una vez por navegador, en la primera sesión que GA4 ha visto de él. Borrar las cookies produce otro.
- user_engagement: se envía cuando la página ha estado en primer plano diez segundos, o cuando el visitante se va después de interactuar. De aquí sale el tiempo de interacción de GA4.
Si ves page_view y nada más, la etiqueta funciona. No es un fallo; es un sitio en el que todavía nadie ha llegado al final de la página.
Nueve eventos de la medición mejorada, y el interruptor que decide si recibes alguno
La medición mejorada de GA4 recoge nueve eventos más en el navegador, sin etiqueta para ninguno. Se configuran en el flujo de datos, no en Tag Manager, y por eso un contenedor de servidor los reenvía sin saber que existen.
Cada uno tiene una condición más estricta de lo que su nombre sugiere.
- scroll: una vez por página, y solo cuando el 90 % de la altura de la página ha sido visible. No con cualquier desplazamiento: al llegar al final. Una página más corta que la ventana nunca lo dispara.
- click: un clic saliente, a un dominio distinto del actual. Los enlaces internos no cuentan. El evento se llama click, con un parámetro outbound; no existe outbound_click.
- view_search_results: una carga de página cuya URL lleva un parámetro de búsqueda (q, s, search, query o keyword por defecto).
- file_download: un clic en un enlace que termina en una extensión de documento, archivo comprimido, audio, vídeo u hoja de cálculo.
- form_start y form_submit: la primera interacción con un formulario de la página y su envío.
- video_start, video_progress y video_complete: solo para reproductores de YouTube incrustados, y solo cuando la inserción tiene activada la API de JS.
Y aquí está la parte que cuesta semanas. Cada uno de esos nueve depende del interruptor principal de medición mejorada del flujo, y un flujo creado a través de la API de administración de Analytics —en lugar de en la interfaz de Analytics— tiene ese interruptor APAGADO. Lee los ajustes por la API y cada conmutador individual devuelve true; el interruptor principal simplemente no aparece en la respuesta, porque es false y la API omite los booleanos falsos. Así que la configuración parece totalmente activada y entrega solo page_view.
Lo encontramos en nuestra propia propiedad. SignalHost activa el interruptor principal cuando crea una propiedad por ti; si la tuya se creó de otra forma y scroll nunca llega, abre el flujo de datos en Analytics y comprueba «Medición mejorada» en sí, no los conmutadores de debajo.
Dieciséis eventos que solo tu sitio puede enviar
Los eventos que generan dinero —una venta, un lead, un registro— son los únicos de esta página que nada envía automáticamente. GA4 define sus nombres y su forma; tu sitio tiene que enviar cada uno al dataLayer, exactamente con ese nombre, en el momento en que ocurre.
Cada contenedor de SignalHost tiene, para dieciséis de ellos, un activador y una etiqueta de evento de GA4 ya preparados:
- Nueve para el embudo de una tienda: view_item_list, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info y purchase, cada uno con un objeto ecommerce adjunto.
- Cinco para leads: generate_lead, contact, schedule, submit_application y subscribe.
- Dos para registros: sign_up y start_trial.
Un tema estándar de Shopify no envía ninguno, y el núcleo de WooCommerce tampoco: lo hace una aplicación o un plugin de dataLayer, y en Shopify los eventos del checkout necesitan un Custom Pixel, porque el contenedor del tema nunca carga en las páginas de pago. En cuanto tu sitio envía uno, la etiqueta está ahí para reenviarlo; el envío lo tienes que organizar tú, y el artículo sobre Shopify y WooCommerce explica exactamente qué instalar.
El botón «Eventos compatibles» de la tarjeta «Eventos» de tu contenedor los enumera todos, con lo que significa cada uno y qué enviar. Si tu contenedor ya envía uno de ellos a GA4 con una etiqueta tuya, SignalHost deja ese evento a tu etiqueta en lugar de contarlo dos veces.
Qué cuenta la página del contenedor
Cada solicitud de medición que pasa por tu contenedor se cuenta por nombre de evento, por día, durante 400 días. Solo se conserva el nombre —ni la URL, ni el ID de cliente, ni un solo parámetro—, y eso es lo que hace seguro guardarlo tanto tiempo. La lista es lo que llegó a tu nombre de host, así que responde a una pregunta que Analytics no puede responder: ¿lo envió el navegador siquiera?
Espera recuentos desiguales. Cada carga de página es un page_view; solo las cargas que llegan al final son un scroll; solo las sesiones que pasan de diez segundos son un user_engagement. Un sitio con diez páginas vistas y dos scrolls es un sitio normal.
Dos cosas impedirán que las dos listas coincidan exactamente. Un visitante que no ha respondido a tu banner sigue enviando cada evento, como ping sin cookies, y el contenedor lo cuenta mientras Analytics lo descarta: la página muestra ambas cifras para que veas cuál es cuál. Y session_start y first_visit nunca aparecen en la página del contenedor: el navegador no los envía como eventos, sino que marca dos indicadores en el primer page_view, y Analytics fabrica los eventos por su lado.
Encima de la lista, la tarjeta cuenta cuántos de esos dieciséis eventos llegaron en los últimos 30 días, para que destaque el que tu sitio olvidó enviar.
Cuando falta un evento
Dos casos, y la página del contenedor los distingue.
Si el evento no está en la lista del contenedor, tu sitio nunca lo envió. El contenedor no puede reenviar lo que no llegó. Para un evento estándar, revisa el interruptor de medición mejorada del flujo; para uno de los dieciséis, comprueba que el envío al dataLayer ocurre, con el nombre correcto, en la página donde debe.
Si el evento está en la lista del contenedor pero no en Analytics, llegó y se reenvió, y el problema está en el lado de Google de la línea: un ID de medición equivocado, un filtro de datos, una propiedad en una cuenta distinta de la que estás mirando, o simplemente el retraso de los informes: el tiempo real lo muestra en segundos, los informes estándar pueden tardar un día.
¿Empiezas desde cero? Cómo configurar Google Tag Manager del lado del servidor, paso a paso.

