Eventos recomendados GA4 - ¿Mides bien tus leads?

Cuando una web necesita medir resultados de negocio, no basta con contar visitas: hace falta saber qué hace la gente antes de dejar un contacto, registrarse o comprar. En esta guía voy a centrarme en cómo elegir y configurar los eventos recomendados en GA4 para que la medición sea útil de verdad, especialmente en proyectos de empresa, marketing y captación de leads como los de formación, educación superior y empleabilidad.

Qué son y por qué conviene usarlos

En GA4, los eventos recomendados son acciones que Google ya ha definido con un nombre y unos parámetros estándar. No se envían solos: hay que implementarlos, pero a cambio encajan mejor con la lógica de los informes y reducen el riesgo de tener una medición caótica con nombres distintos para la misma acción.

La diferencia con otros tipos de evento es simple. Los automáticos llegan sin tocar código o con muy poca configuración; los recomendados requieren implementación, pero están pensados para comportamientos muy comunes; y los personalizados solo deberían entrar en juego cuando no existe una opción mejor. Yo suelo resumirlo así: si Google ya tiene un evento útil para tu caso, aprovecha ese camino antes de construir otro desde cero.

La ventaja real no está solo en “tener más datos”, sino en que esos datos sean comparables entre equipos, campañas y periodos. Y precisamente por eso conviene decidir primero qué medir, no solo cómo medirlo. Con esa base, el siguiente paso es priorizar los eventos que de verdad mueven el negocio.

Qué eventos priorizaría según el objetivo del negocio

Si yo tuviera que empezar desde cero en una web de empresa, formación o marketing, no intentaría activar todos los eventos posibles a la vez. Empezaría por los que explican mejor el recorrido del usuario: búsqueda interna, consumo de contenido, registro y generación de oportunidad comercial. En una parte importante de los casos, eso ya da una fotografía bastante buena del embudo.

Si el sitio no vende directamente, mi foco se desplaza casi siempre a search, select_content, sign_up y generate_lead. Son los eventos que mejor explican el paso de lector interesado a contacto real. Y una vez tienes claro qué medir, toca implementarlo sin duplicar señales ni ensuciar el embudo.

Cómo los configuraría sin duplicar datos

1. Defino la acción exacta que quiero medir. No mido “interés”, mido “envío de formulario”, “registro completado” o “búsqueda interna ejecutada”.
2. Elijo el evento recomendado correcto. Si existe uno estándar, lo uso antes de crear algo nuevo.
3. Reviso la medición mejorada para no duplicar acciones que ya se están registrando automáticamente, como ciertas interacciones básicas del sitio.
4. Asigno parámetros solo cuando aportan contexto. No se trata de llenar todo de campos, sino de añadir lo que luego voy a usar en informes o exploraciones.
5. Pruebo en tiempo real antes de publicar. Si el evento aparece mal enviado o duplicado, el error se arrastra a todos los informes.
6. Marco como evento clave solo lo importante. No todo evento merece esa etiqueta; si todo es conversión, nada destaca.

La documentación oficial de Google deja bastante claro un principio que yo también sigo: si existe un evento recomendado, suele ser mejor reutilizarlo que inventar un evento personalizado parecido. Eso ahorra tiempo y, sobre todo, evita que los informes queden fragmentados por nombres distintos para la misma acción. El siguiente paso es entender qué parámetros hacen que ese evento sirva de verdad para tomar decisiones.

Qué parámetros hacen útil el dato

Un evento sin contexto sirve poco. Por eso los parámetros importan tanto: convierten una interacción genérica en una señal accionable. En GA4, algunos eventos ya traen parámetros sugeridos muy claros; otros admiten datos opcionales que conviene usar solo si ayudan a leer mejor el comportamiento.

Hay dos detalles que yo vigilaría con especial cuidado. El primero es la coherencia del valor: si asignas value, debe responder a una regla de negocio, no a una cifra improvisada. El segundo es el volumen de parámetros: no conviene disparar campos sin sentido; en eventos personalizados, además, hay límites técnicos que pueden complicarte el informe si te excedes. Mi criterio es simple: mejor pocos parámetros, pero bien elegidos, que una ficha de evento llena de ruido.

En captación, por ejemplo, tiene sentido dar valor a un lead cuando el equipo comercial ya conoce un valor medio por oportunidad o una estimación razonable de matrícula. Si todavía no existe esa referencia, yo prefiero empezar sin forzar una monetización artificial y revisar la lógica más adelante. Con esa base, ya se puede aterrizar todo en un portal educativo como Campusnet y ver qué mediría primero.

Cómo lo aplico en un portal educativo y de empleabilidad

En una web como Campusnet, el embudo no suele empezar en la compra, sino en la lectura y la orientación. El usuario llega para informarse, compara opciones, consulta guías y, cuando encuentra una propuesta que le encaja, deja un contacto o solicita más información. Por eso yo no intentaría medir solo conversiones finales: me interesa también la parte previa, porque ahí se ve dónde se pierde el interés.

Mi orden de prioridad sería este:

• search para conocer qué busca de verdad el usuario: becas, másteres, cursos, prácticas, salidas laborales o formación online.
• select_content para identificar qué recursos atraen más, por ejemplo una guía de orientación, un análisis de empleabilidad o una ficha de programa.
• sign_up para medir altas a newsletter, áreas privadas o recursos descargables.
• generate_lead para formularios de admisión, solicitudes de información, pruebas de acceso o contacto comercial.
• tutorial_begin y tutorial_complete si hay un test vocacional, un recorrido de bienvenida o un asistente guiado que ayude al usuario a decidir.

Errores que más distorsionan la lectura del embudo

En GA4 he visto una y otra vez los mismos problemas, y casi siempre nacen de un impulso comprensible: querer medir demasiado pronto o medirlo dos veces. El resultado es un dashboard que parece preciso, pero no ayuda a decidir nada.

• Duplicar el mismo evento con un custom event y un evento recomendado para la misma acción.
• Usar una página de gracias como único indicador cuando el formulario ya dispara un evento específico.
• Marcar demasiados eventos como clave, lo que diluye la prioridad de las conversiones reales.
• Dar un valor económico sin una regla estable, algo que luego rompe cualquier análisis comparativo.
• Nombrar parámetros de forma distinta entre equipos, países o plantillas, creando informes imposibles de comparar.
• No probar el evento en DebugView o tiempo real antes de publicarlo.
• Ignorar la privacidad y el consentimiento, especialmente en formularios y tracking de interacción sensible.

Mi experiencia es bastante clara aquí: el problema rara vez es que falten eventos; el problema suele ser que sobran señales mal conectadas. Si el equipo ya dispone de medición mejorada, conviene revisar qué está entrando solo y qué se está añadiendo a mano para no contar la misma interacción dos veces. Una implementación limpia casi siempre vale más que una implementación ambiciosa pero desordenada.

La regla práctica que me deja una implementación útil de verdad

Yo me quedo con una idea muy sencilla: empieza por pocos eventos, pero que expliquen el negocio. En un portal de empresa, educación o marketing, eso suele significar búsqueda, contenido relevante, registro y lead. Si después necesitas más detalle, amplías el mapa con parámetros o con eventos secundarios, no al revés.

Si al cabo de unas semanas puedes responder con claridad a preguntas como “qué busca más la audiencia”, “qué contenido convierte mejor” y “en qué punto se cae el formulario”, la medición ya está haciendo su trabajo. Si no puedes responderlas, el problema no es GA4: normalmente es que faltan eventos bien elegidos o sobran eventos sin una intención clara. Yo, por eso, siempre prefiero una configuración sobria y coherente antes que una larga lista que nadie usa para decidir nada.