Hay proyectos que parecen relativamente sencillos cuando llegan y que, al empezar a revisar lo que existe realmente detrás, terminan convirtiéndose en trabajos bastante más amplios de lo previsto. Este ha sido uno de ellos.
El encargo inicial era claro: crear un dashboard de analítica en Looker Studio que permitiera centralizar en un único entorno los datos de varias páginas web pertenecientes a un mismo grupo empresarial. La empresa necesitaba consultar sus principales métricas sin entrar constantemente en diferentes propiedades de Google Analytics, Search Console y otras plataformas.
Sobre el papel, el proyecto parecía consistir fundamentalmente en conectar fuentes, diseñar una plantilla, replicarla para cada web y ordenar los principales KPI. Sin embargo, en cuanto empecé a revisar la arquitectura de medición comprobé que no tenía sentido construir ningún dashboard antes de saber si las fuentes disponibles eran realmente fiables.
Encontré varias propiedades de Google Analytics 4 midiendo un mismo dominio, implementaciones paralelas, diferencias enormes entre propiedades que supuestamente representaban el mismo proyecto, varios contenedores de Google Tag Manager, configuraciones a las que no existía acceso y, en el caso más grave, una web enviando tráfico y eventos a la propiedad GA4 de otra web diferente.
El trabajo dejó entonces de ser simplemente un proyecto de Looker Studio. Primero tuve que realizar una auditoría de Google Analytics 4 y Google Tag Manager, reconstruir la arquitectura de medición, comprobar qué estaba sucediendo y decidir qué fuentes podían utilizarse sin convertir el dashboard en una representación visual de datos incorrectos.
He anonimizado los nombres de la empresa, proyectos, dominios e identificadores. Lo relevante en este artículo es el proceso: qué encontré, cómo lo comprobé, qué significaba cada incidencia y qué decisiones tomé para construir finalmente un sistema de reporting fiable y mantenible.
Tampoco quiero convertir este artículo en otra explicación general de la herramienta. Para eso ya existe mi guía de Looker Studio y Google Data Studio. Además, para quien tenga curiosidad por la evolución de la plataforma, conservo también un artículo anterior sobre Google Data Studio y sus funcionalidades en 2019.
Aquí voy a centrarme en un caso práctico completo de auditoría GA4, arquitectura de medición digital y construcción de un dashboard para varias webs: inventario de propiedades, revisión de Google Tag Manager, validación con Tag Assistant, propiedades duplicadas, tráfico Unassigned, contaminación entre dominios, análisis mediante hostname, selección de fuentes, documentación técnica, construcción del dashboard, integración de Search Console, preparación para Google Ads y Metricool y creación de manuales para que el sistema pudiera mantenerse posteriormente.
Porque un dashboard profesional tiene bastante menos que ver con crear gráficos bonitos y mucho más con saber qué estamos midiendo, cómo se está midiendo y si realmente podemos confiar en los datos.
La organización gestionaba distintos proyectos digitales y necesitaba un único punto desde el que consultar su rendimiento. La idea era razonable: abrir un dashboard, seleccionar el proyecto y disponer inmediatamente de la información relevante sin navegar por diferentes cuentas y herramientas.
La primera definición incluía los indicadores habituales de analítica web: usuarios, sesiones, vistas, adquisición, páginas de destino, dispositivos, localización, eventos, conversiones e interacción. A esto se añadirían los datos SEO disponibles en Google Search Console y, posteriormente, otras fuentes si resultaban necesarias.
La estructura no parecía especialmente complicada. El problema era que todavía no sabía qué propiedad de Analytics debía alimentar cada bloque ni si todas las propiedades disponibles representaban realmente a la web que indicaban sus nombres.
La forma más directa de ejecutar el encargo habría consistido en crear el informe, conectar todas las propiedades disponibles, diseñar una página por proyecto, añadir los KPI y entregar el dashboard. Habría sido rápido, pero habría introducido un riesgo importante: dar por buena toda la arquitectura de medición previa.
Antes de utilizar una cifra como dato de negocio necesitaba comprobar de dónde procedía, qué implementación la generaba y si existía otra medición paralela capaz de alterar su interpretación.
Visualizar datos y disponer de datos fiables son dos problemas distintos. Looker Studio resuelve muy bien el primero, pero no valida automáticamente el segundo.
La plataforma no sabe si una etiqueta está duplicada, si dos propiedades están registrando prácticamente a los mismos usuarios o si una web está enviando eventos a un GA4 que pertenece a otro dominio. Tampoco decide por sí sola qué propiedad histórica debe utilizarse o si una implementación antigua continúa activa por error.
Si conectamos una fuente defectuosa, el dashboard mostrará esos datos defectuosos mediante gráficos perfectamente correctos desde el punto de vista visual.
Este riesgo suele pasar desapercibido. Una cifra extraña dentro de Google Analytics puede generar dudas; la misma cifra presentada dentro de un dashboard corporativo, con tarjetas, porcentajes y gráficas, puede parecer mucho más precisa de lo que es.
Por ese motivo, la primera pregunta dejó de ser qué gráficos debía crear. Pasó a ser otra: ¿qué propiedades representan realmente cada proyecto y cuáles puedo utilizar con suficiente confianza?
Antes de comparar métricas necesitaba saber qué existía. En una web reciente la estructura puede ser sencilla: una propiedad GA4, un Google Tag Manager y una propiedad de Search Console. En organizaciones con varios años de trayectoria digital, la realidad suele ser bastante más compleja.
Por la misma infraestructura pueden haber pasado diferentes desarrolladores, agencias, especialistas en campañas, equipos internos y proveedores. Además, pueden haberse producido rediseños, migraciones desde Universal Analytics, cambios de dominio, nuevas promociones o configuraciones temporales que terminaron permaneciendo activas.
Creé un inventario en el que fui asociando cada proyecto con los recursos disponibles. Para cada web registré el dominio, la cuenta de Analytics, el nombre de la propiedad, su ID de medición, el estado, los contenedores GTM relacionados, los accesos disponibles y cualquier incidencia inicial que pudiera afectar al reporting.
Esta primera fase ya reveló que la relación entre web y propiedad no era siempre uno a uno. Algunos proyectos tenían una arquitectura bastante clara, mientras que otros tenían dos propiedades de Analytics activas para el mismo dominio. En otro caso aparecían dos mediciones y varios contenedores de Google Tag Manager.
Uno de los errores más fáciles de cometer consiste en seleccionar una propiedad únicamente porque su nombre parece corresponder al proyecto. Sin embargo, un nombre creado hace años puede no reflejar correctamente la implementación actual.
Por eso el inventario debía relacionar cada propiedad con su dominio real, su ID y el mecanismo de medición que la estaba alimentando.
Con varias webs y diferentes fuentes necesitaba trabajar con un orden claro. Revisar elementos de forma aislada habría dificultado tanto el diagnóstico como la posterior documentación.
| Fase | Qué revisé | Objetivo |
|---|---|---|
| Inventario | Dominios, cuentas, GA4 y GTM | Conocer la arquitectura existente |
| Comparación | Sesiones, canales y periodos equivalentes | Detectar duplicidades y discrepancias |
| Implementación | gtag, GTM, etiquetas y activadores | Entender cómo se genera la medición |
| Validación | Tag Assistant | Comprobar qué se ejecuta |
| Impacto | Hostname, eventos y sesiones | Cuantificar las incidencias |
| Selección | Fuente principal por proyecto | Definir qué utilizar en Looker Studio |
| Documentación | Hallazgos, impacto y acciones | Dejar trazabilidad |
Esta secuencia terminó siendo también la base del informe técnico. Primero debía demostrar qué estaba ocurriendo; posteriormente podía decidir qué hacer con esa información dentro del dashboard.
El primer hallazgo importante apareció en uno de los dominios principales. Había dos propiedades de Google Analytics 4 activas y ambas parecían relacionadas con la misma web.
La existencia de dos IDs no demostraba por sí sola un problema. Podía tratarse de una propiedad histórica, una configuración de pruebas, una migración o incluso una arquitectura paralela deliberada. Necesitaba comparar los datos.
Durante aproximadamente un año, una propiedad registraba alrededor de 3.800 sesiones, mientras que la segunda se situaba aproximadamente en 3.696 sesiones. La diferencia era pequeña, pero todavía necesitaba comprobar si la distribución del tráfico coincidía.
Organic Search mostraba aproximadamente 697 sesiones en una propiedad y 698 en la otra. Referral registraba unas 871 frente a 876. La similitud no estaba únicamente en el total, sino en el reparto interno del tráfico.
Con ese nivel de coincidencia podía concluir que las dos propiedades estaban midiendo prácticamente la misma actividad del mismo dominio.
Tras confirmar la duplicidad pasé a la implementación. Quería saber por qué podían coexistir dos propiedades recibiendo datos tan similares.
La revisión mostró que una medición procedía de una configuración directa de la etiqueta de Google, mientras que la otra se ejecutaba mediante Google Tag Manager.
Este tipo de situación aparece con facilidad después de varios años. Una web puede tener Analytics instalado directamente, incorporar posteriormente GTM y añadir una nueva propiedad sin retirar la implementación anterior. Si nadie revisa el conjunto, ambas continúan midiendo indefinidamente.
Las propiedades paralelas pueden presentar diferencias en eventos, conversiones, retención, histórico o configuración. Por tanto, aunque las sesiones sean muy parecidas, no tiene sentido utilizar una para adquisición y otra para conversiones, ni mucho menos sumar ambas.
La solución de reporting fue seleccionar una única propiedad como fuente del proyecto y excluir completamente la otra.
Si una propiedad registra unas 3.800 sesiones y otra 3.696, el proyecto no tiene 7.496 sesiones. En este caso, prácticamente las mismas visitas han quedado almacenadas en dos sistemas diferentes.
La duplicidad genera además problemas más sutiles. Las propiedades pueden evolucionar de forma distinta con el paso del tiempo, recibir configuraciones diferentes o registrar eventos que no existen en la otra.
El criterio que apliqué fue deliberadamente sencillo: una página del dashboard utiliza una propiedad concreta y todos sus gráficos dependen de esa misma fuente. La medición paralela queda fuera, aunque continúe existiendo mientras el equipo técnico decide qué hacer con ella.
Este matiz fue importante al redactar los avisos. En este caso el problema era la duplicidad, no una contaminación demostrada de la propiedad seleccionada. Por tanto, no tenía sentido marcar sus cifras como “datos no fiables”.
La explicación correcta consistía en indicar que el dashboard utiliza una única fuente y que la propiedad paralela se ha excluido para evitar duplicidades.
En otra web apareció nuevamente una doble medición, pero los resultados eran completamente distintos. Aquí no estábamos ante dos copias casi idénticas.
| Métrica o canal | Propiedad A | Propiedad B |
|---|---|---|
| Sesiones totales | 5.527 | 9.634 |
| Organic Search | 2.098 | 4.506 |
| Direct | 844 | 3.419 |
| Referral | 627 | 864 |
| Unassigned | 1.905 | 184 |
| Organic Social | 13 | 243 |
La diferencia era demasiado grande para considerar las dos propiedades intercambiables. Tampoco podía decidir que la que recogía más tráfico era automáticamente la correcta. Necesitaba entender qué estaba ocurriendo detrás.
Las causas posibles incluían una cobertura distinta de páginas, históricos que empiezan en momentos diferentes, diferencias de atribución, eventos configurados de forma desigual o implementaciones heredadas que seguían activas.
Además, el reparto por canales aportaba otra pista relevante.
Una de las propiedades clasificaba aproximadamente un 34,47 % de las sesiones como Unassigned. En la otra, el mismo grupo representaba alrededor de un 1,91 %.
Unassigned agrupa sesiones que GA4 no consigue encajar correctamente en sus canales predeterminados. Puede aparecer por UTM incorrectas, fuentes o medios no reconocidos, campañas antiguas, diferencias de implementación o problemas de atribución.
No podía afirmar que ese porcentaje explicara toda la diferencia entre propiedades. Sin embargo, sí mostraba que la clasificación del tráfico no estaba funcionando de la misma forma.
La combinación entre sesiones totales, adquisición y Unassigned reforzaba la conclusión de que las dos propiedades representaban implementaciones distintas y no podían combinarse en el dashboard.
Tras comparar datos volví a la implementación. Tag Assistant permitió comprobar que las dos propiedades continuaban cargándose realmente en la web; no eran únicamente cuentas históricas abandonadas.
Una de las propiedades procedía de una etiqueta de sitio conectada a una configuración anterior, mientras que la segunda se cargaba mediante otra implementación. Además, aparecieron varios contenedores de Google Tag Manager instalados.
Dos de esos GTM no estaban disponibles con los permisos de la cuenta utilizada para la auditoría.
Podía comprobar que determinados scripts estaban presentes y se ejecutaban, pero no describir su configuración interna sin acceso al GTM que los controlaba.
Por ese motivo diferencié claramente cuatro estados: detectado, confirmado, auditado y no accesible. Esta distinción terminó siendo muy útil tanto para el informe como para las instrucciones posteriores al equipo técnico.
La diferencia de tráfico y atribución impedía tratar las dos propiedades como equivalentes. Una debía convertirse en la fuente seleccionada para el reporting y la otra quedar fuera.
No mezclé sesiones de una con eventos de la otra ni intenté construir una especie de promedio entre propiedades. Cada proyecto debía depender de una única fuente coherente.
El hecho de no utilizarla en Looker Studio no significaba ignorar su existencia. El informe técnico explica que continúa activa, que sus cifras presentan diferencias relevantes y que la empresa deberá revisar posteriormente cuál debe mantenerse como medición oficial.
Hasta este punto había encontrado duplicidades e implementaciones no equivalentes. La incidencia más importante apareció al revisar Google Tag Manager.
Dentro del contenedor de una de las webs encontré una etiqueta cuyo destino era la propiedad GA4 correspondiente a otro proyecto del mismo grupo.
El activador estaba configurado como Initialization – All Pages. No se trataba de una etiqueta reservada para una página específica o una situación excepcional: podía ejecutarse desde el inicio en todas las páginas del dominio.
En términos prácticos, un usuario navegaba por la web A y parte de esa actividad podía terminar almacenada también dentro del Analytics de la web B.
Los dos problemas implican varias implementaciones, pero su impacto es muy diferente.
En el segundo escenario, seleccionar una única propiedad no soluciona el histórico, porque esa propiedad ya almacena información que pertenece a otro proyecto.
Esta diferencia determinó cómo debía tratar posteriormente cada página del dashboard.
Encontrar la configuración dentro de GTM era una evidencia importante, pero no quería basar el diagnóstico únicamente en lo que estaba configurado. Necesitaba comprobar si los eventos estaban llegando al destino incorrecto.
Tag Assistant confirmó que el dominio equivocado estaba enviando información a la propiedad del segundo proyecto. Entre los eventos observados aparecían page_view, scroll y otras interacciones asociadas a la navegación.
No era una etiqueta antigua que simplemente permaneciera dentro del contenedor. La contaminación estaba ocurriendo.
Una vez confirmado el problema quería saber cuánto estaba afectando realmente al reporting. Para ello utilicé la dimensión hostname.
El hostname permite identificar desde qué dominio se originan los hits y resulta especialmente útil cuando una propiedad recibe datos de varios dominios, existen subdominios o se sospecha de un etiquetado cruzado.
En el periodo que conservaba suficiente nivel de detalle, la exploración mostraba aproximadamente:
| Origen | Sesiones | Peso aproximado |
|---|---|---|
| Dominio incorrecto | 557 | 60 % |
| Dominio correcto | 371 | 40 % |
La propiedad estaba recibiendo más sesiones de la web equivocada que de su propio dominio.
Este dato convirtió una configuración sospechosa en un problema claramente cuantificado. Ya no estábamos hablando de unos pocos eventos residuales: el tráfico ajeno tenía suficiente peso para distorsionar seriamente cualquier análisis agregado de aquella propiedad.
Si alguien hubiera consultado únicamente la cifra global habría visto cerca de 900 sesiones durante el periodo analizado. Sin conocer el problema, podría haber interpretado ese volumen como una mejora del proyecto.
Dependiendo del reparto del tráfico, podía parecer un crecimiento SEO, un aumento de demanda, una mejora de determinadas páginas o incluso el efecto positivo de alguna acción de marketing.
Sin embargo, una parte mayoritaria de aquellas sesiones pertenecía realmente a otra web.
El problema serio aparece cuando esa cifra se utiliza para tomar decisiones. Una empresa puede aumentar inversión, mantener una campaña, valorar positivamente una estrategia o priorizar determinados contenidos basándose en un crecimiento que nunca ocurrió en ese proyecto.
Este fue uno de los ejemplos más claros de por qué la auditoría debía preceder al dashboard.
Una vez confirmado el problema tuve que decidir cómo tratar aquella propiedad dentro del reporting.
Podía eliminar la página, esperar a que el equipo técnico corrigiera GTM o mantener los datos visibles acompañados de una advertencia muy clara. Elegí esta última opción.
La página del proyecto indica expresamente que la medición está comprometida. Además, explica cuál es la fuente utilizada, de dónde procede la contaminación y por qué el histórico reciente debe interpretarse únicamente como referencia.
Esto permitía continuar con la entrega del dashboard sin esconder una incidencia que afectaba directamente a la interpretación.
Cuando el equipo técnico corrija la implementación podrá establecerse una fecha a partir de la cual la nueva medición ya no reciba tráfico del dominio incorrecto.
Si posteriormente aparece una caída aparente de sesiones, la documentación evitará interpretarla como un empeoramiento comercial: parte del tráfico anterior nunca perteneció realmente a aquel proyecto.
El mismo proyecto todavía tenía otra capa de complejidad. Existían dos contenedores de Google Tag Manager y una segunda medición GA4 que estaba enviando hits reales.
Sin embargo, no disponía de permisos para entrar en ese segundo contenedor.
Podía confirmar que la medición existía y estaba activa, pero no revisar qué etiquetas contenía, qué triggers utilizaba ni por qué se había instalado.
El informe dejó constancia de esa limitación y recomendó identificar al propietario de la configuración antes de decidir si debía mantenerse o retirarse.
Este tipo de precisión me parece básica en una auditoría: lo que no se ha podido comprobar debe quedar indicado como tal.
Durante la revisión apareció además una configuración que podía pasar desapercibida: la retención de datos de eventos estaba establecida en solo dos meses.
Esto afectaba a determinadas exploraciones y explicaba por qué parte del histórico detallado ya no estaba disponible.
La modificación evita que la misma limitación continúe afectando a los análisis futuros. Sin embargo, cambiar la configuración no recupera información que GA4 ya ha dejado de conservar.
Por ese motivo, algunas comprobaciones de hostname solo pudieron realizarse sobre el periodo reciente disponible.
No todas las incidencias tenían la misma importancia. Dentro del inventario apareció una propiedad que no contenía información útil para la primera versión del dashboard.
No la incorporé simplemente porque existiera. Un dashboard no es un inventario de todas las cuentas disponibles; debe mostrar información que pueda interpretarse y utilizarse.
La propiedad quedó fuera del reporting, aunque su existencia y situación se documentaron para que nadie interpretara posteriormente que había sido olvidada.
Después de completar la auditoría definí una norma que gobernaría toda la construcción:
cada proyecto utilizaría una única fuente GA4 seleccionada y documentada.
Este criterio fue bastante más importante para la calidad final que cualquier decisión de diseño.
Todo el trabajo realizado tenía que quedar documentado de forma que otra persona pudiera entenderlo sin reconstruir mi investigación desde cero.
La primera parte resume las principales incidencias de forma comprensible: propiedades paralelas, diferencias importantes entre mediciones, cross-tagging, configuraciones sin acceso y recursos sin datos útiles.
Posteriormente, cada hallazgo se desarrolla con mayor detalle, incluyendo la evidencia disponible, el impacto y las acciones recomendadas.
Una tabla relaciona proyecto, dominio, propiedad, ID, estado y observaciones. Este mapa resulta especialmente útil para el mantenimiento futuro porque evita tener que deducir de nuevo qué propiedad corresponde a cada web.
Intenté mantener una estructura constante para que el informe fuera operativo y no una simple colección de observaciones.
En el caso de las propiedades duplicadas quedaron registrados los IDs, las implementaciones, el periodo comparado, las sesiones y la similitud de los principales canales.
En el caso del cross-tagging incluí además el contenedor afectado, la etiqueta, el activador global, la validación mediante Tag Assistant y la cuantificación obtenida mediante hostname.
No tenía sentido tratar todos los problemas con la misma urgencia. El etiquetado cruzado era claramente la incidencia más crítica porque estaba contaminando activamente otra propiedad.
Antes de retirar una medición redundante conviene comprobar qué información contiene. Puede guardar eventos, conversiones, históricos o integraciones que todavía necesitemos.
El procedimiento recomendado consiste en decidir primero cuál será la propiedad oficial, validar qué debe conservarse y retirar posteriormente la implementación redundante de forma controlada.
La auditoría no terminaba cuando yo entendía qué estaba pasando. El cliente y el equipo responsable de las webs tenían que saber qué se había encontrado y qué actuaciones correspondían a cada parte.
El correo no repetía todo el informe técnico. Explicaba que la revisión había permitido identificar las principales incidencias, que el dashboard podía continuar utilizando fuentes seleccionadas y que determinadas correcciones quedaban documentadas para el equipo técnico.
Separar diagnóstico, implementación y reporting evitó convertir el proyecto en una reimplementación completa de todas las webs.
En lugar de entregar una recomendación genérica del tipo “revisar Analytics”, el informe indicaba, según cada incidencia, el proyecto afectado, la propiedad, el ID, el contenedor, la etiqueta, el comportamiento comprobado y la corrección propuesta.
También indiqué qué debía validarse una vez realizado el cambio. En el caso del cross-tagging, por ejemplo, no bastaba con eliminar una etiqueta: había que comprobar posteriormente con Tag Assistant y DebugView que el dominio incorrecto había dejado de enviar hits a aquella propiedad.
Con las fuentes identificadas podía pasar finalmente al dashboard. En ese momento mi objetivo cambió: toda la complejidad técnica debía quedarse detrás y el usuario final debía encontrarse una interfaz sencilla.
En lugar de construir cada proyecto desde cero, preparé una estructura base con los indicadores que tenían sentido para prácticamente todas las webs.
Una vez validada la plantilla, la dupliqué para los demás proyectos y sustituí la fuente de datos correspondiente. Esto mantuvo una estructura visual coherente y redujo el riesgo de crear configuraciones diferentes por error.
La primera página permite acceder a cada proyecto mediante botones. El usuario no necesita conocer los menús internos de Looker Studio ni buscar páginas dentro del informe.
El texto explica que algunos proyectos tienen mediciones paralelas, que el dashboard utiliza una única fuente seleccionada y que existe un caso donde la propia propiedad contiene tráfico contaminado.
Añadí además acceso directo a la carpeta documental para que auditoría, manuales y dashboard formen parte del mismo sistema y no terminen dispersos.
No me parecía suficiente dejar las incidencias únicamente en el informe técnico. Una persona puede abrir directamente Looker Studio meses más tarde sin haber leído la auditoría.
Por eso cada proyecto afectado tiene una explicación específica. En las propiedades con duplicidad, el aviso indica qué fuente se utiliza y qué medición se ha excluido. En la propiedad contaminada, la página advierte expresamente de que los datos no son fiables.
Intenté mantener una estructura suficientemente completa para entender cada proyecto sin convertir el informe en un catálogo interminable de métricas.
Estas métricas ofrecen una primera fotografía del volumen y comportamiento, pero ninguna debe interpretarse de forma aislada. El valor aparece cuando se relacionan con adquisición, páginas y eventos.
El gráfico de canales permite ver el peso de Organic Search, Direct, Referral, Organic Social, Email y otras categorías. La tabla de fuentes baja posteriormente al origen concreto: Google, tráfico directo, redes sociales, webs de referencia, campañas o incluso asistentes de inteligencia artificial cuando aparecen identificados.
Esta combinación ayuda a entender no solo cuánto tráfico existe, sino de qué depende cada proyecto.
La tabla muestra las URLs donde comienzan las sesiones, acompañadas por sesiones, usuarios y vistas. Es una información especialmente útil para detectar qué contenidos están captando usuarios, aunque no fueran considerados inicialmente las páginas más importantes del proyecto.
El reparto entre móvil, ordenador y tablet aporta contexto sobre la forma en que se consume cada web. Añadí además las principales ciudades, aunque estos datos deben interpretarse como una aproximación y no como una localización exacta.
Cuando el componente geográfico forma parte de una estrategia más amplia, esta información puede complementarse con acciones específicas de SEO local y Google Business.
Una gráfica de sesiones por día completa el bloque de adquisición. Dos periodos pueden tener prácticamente el mismo volumen y, sin embargo, presentar distribuciones completamente diferentes.
La serie temporal facilita detectar picos, caídas, efectos de campañas, cambios repentinos o posibles problemas de medición. No necesitaba una visualización sofisticada; necesitaba que el usuario pudiera identificar rápidamente cuándo había ocurrido algo fuera de lo normal.
El siguiente bloque abandona el volumen de tráfico y se centra en comportamiento.
Entre los eventos aparecían page_view, user_engagement, session_start, first_visit, scroll, clics, descargas, inicio de formularios y otras acciones específicas de determinados proyectos.
No quería limitarme a una lista de nombres. También necesitaba saber cuánto se producía cada acción y cuántas personas estaban participando en ella.
Los eventos clave se muestran igualmente aunque algunos proyectos tengan valor cero. Ese cero no significa necesariamente ausencia de acciones comerciales; puede indicar que todavía no existe una configuración adecuada de eventos clave.
Después de toda la auditoría, los proyectos podían agruparse en tres situaciones claramente distintas.
| Situación | Tratamiento en el dashboard |
|---|---|
| Fuente sin incidencia relevante | Datos mostrados normalmente |
| Existen propiedades paralelas | Una fuente seleccionada y las demás excluidas |
| La propia fuente está contaminada | Datos visibles, pero identificados como no fiables |
Esta clasificación evitó tratar cualquier duplicidad como si todo el histórico estuviera mal y, al mismo tiempo, impidió presentar como fiable una propiedad que había recibido una cantidad material de tráfico procedente de otro dominio.
Después de completar la parte de Analytics pasé al bloque SEO. La intención era incorporar datos de Search Console cuando existiera acceso correcto a la propiedad correspondiente.
Con la cuenta utilizada para construir el dashboard únicamente estaba disponible una de las propiedades necesarias. No intenté mantener una falsa simetría utilizando otra web o una propiedad que no correspondiera al proyecto.
Cuando se concedan nuevos permisos, las páginas restantes podrán ampliarse sin necesidad de modificar la arquitectura principal.
Para construir el bloque SEO utilicé dos conexiones diferentes de Search Console.
Esta separación permite responder a dos preguntas distintas: qué están buscando los usuarios y qué páginas de la web están consiguiendo esa visibilidad.
En la parte superior añadí clics, impresiones, CTR y posición media. Posteriormente incorporé una tabla de consultas y otra de páginas, ambas ordenadas de forma que los elementos con mayor peso aparecieran primero.
La tabla de consultas permite detectar búsquedas de marca, términos genéricos, keywords con muchas impresiones, CTR mejorables y oportunidades próximas a mejores posiciones. Esta lectura forma parte también de mi trabajo como consultor SEO, aunque aquí su función es explicar cómo integré la capa orgánica dentro de un sistema de reporting más amplio.
Una de las confusiones más habituales consiste en comparar los clics de Search Console con las sesiones Organic Search de Analytics y esperar cifras idénticas.
No representan exactamente lo mismo. Además, intervienen diferencias de consentimiento, sesiones, atribución, procesamiento, zonas horarias y metodología.
Su valor no está en obligarlas a coincidir, sino en utilizarlas conjuntamente: Search Console explica cómo aparece y recibe clics la web en Google, mientras que GA4 ayuda a analizar lo que ocurre después de la visita.
Google Ads no terminó formando parte de esta primera versión, pero dejé documentado cómo incorporarlo posteriormente.
La cuenta de Google utilizada para editar el dashboard debe tener permisos sobre Google Ads. Una vez concedidos, Looker Studio puede conectarse directamente a la cuenta correspondiente.
Para una primera versión añadiría coste, impresiones, clics, CTR, CPC medio, conversiones y coste por conversión. Después incorporaría una tabla por campañas y, si aporta valor, una serie temporal de inversión o conversiones.
Las dos plataformas pueden utilizar modelos de atribución, ventanas y criterios diferentes. Antes de comparar las cifras hay que comprobar qué representa exactamente cada conversión y evitar presentar como discrepancia un comportamiento que deriva de metodologías distintas.
Otra ampliación estudiada fue la conexión con Metricool. En este caso la empresa necesitaría disponer de los accesos y del plan compatible, pero el procedimiento quedó explicado en el manual de mantenimiento.
La conexión requiere obtener el token correspondiente, añadir el conector en Looker Studio, autorizarlo y seleccionar la marca adecuada.
No mezclaría todas las métricas de social media dentro de las páginas de Analytics. Crearía una sección propia con audiencia, crecimiento, alcance, impresiones, engagement, interacciones y rendimiento de contenidos.
De esta forma la arquitectura continuaría siendo comprensible: analítica web, SEO, publicidad y redes sociales quedarían relacionadas, pero no mezcladas sin criterio.
No quería entregar una estructura cerrada que tuviera que reconstruirse ante cualquier nueva necesidad. La plantilla permite añadir nuevos proyectos, nuevas propiedades de Search Console, cuentas de Ads o fuentes externas manteniendo una lógica común.
El siguiente nivel incluso podría incorporar CRM, leads y ventas. En ese momento el sistema dejaría de responder únicamente a preguntas de tráfico y empezaría a relacionar adquisición con resultados comerciales.
Durante la revisión de fuentes aparecía además un detalle interesante: algunas sesiones ya podían identificarse como procedentes de asistentes de inteligencia artificial.
El volumen puede seguir siendo pequeño frente a Google o Direct, pero forma parte de la evolución de los canales de descubrimiento.
Esto tiene relación directa con el desarrollo de estrategias de GEO y visibilidad en inteligencia artificial. A medida que herramientas como ChatGPT, Gemini, Copilot o Perplexity generen más visitas, tendrá sentido integrarlas progresivamente dentro del análisis de adquisición.
Después de una auditoría con varias cuentas, IDs, GTM, Tag Assistant, hostnames, retención y propiedades paralelas, podría parecer lógico terminar con un dashboard igualmente complejo.
Quise conseguir lo contrario.
El usuario final encuentra una portada, una página por proyecto, un selector de fechas, métricas organizadas de la misma manera y avisos solamente donde son necesarios. No necesita saber cómo funciona un trigger de GTM para interpretar si los datos son fiables.
GA4, Search Console y Google Ads ofrecen centenares de dimensiones y métricas. Un dashboard no necesita utilizarlas todas. Debe responder rápidamente a las preguntas que importan.
El resto puede añadirse cuando exista una necesidad concreta.
El proyecto no terminó con el enlace de Looker Studio. Preparé un manual que explica la portada, cada página, las principales métricas, Search Console y los avisos de calidad.
La idea era que una persona nueva pudiera comprender el informe sin necesitar una explicación individual cada vez.
Si el usuario quiere saber qué significa una métrica, puede consultarlo. Si una nueva persona se incorpora al equipo, dispone del contexto. Y si aparece un aviso de calidad, puede saber exactamente qué implica sin depender de que alguien recuerde verbalmente la auditoría.
El manual de usuario está pensado para consultar el informe. El segundo documento está pensado para modificarlo.
Antes de explicar cómo crear un gráfico, incluye el mapa simplificado de fuentes: qué propiedad utiliza cada proyecto, cuáles están excluidas y dónde existen datos comprometidos.
El documento explica cómo cambiar métricas y dimensiones, duplicar gráficos, añadir una nueva fuente GA4, incorporar Search Console, conectar Google Ads, utilizar Metricool o crear una nueva página a partir de la plantilla existente.
Una recomendación sencilla consiste en duplicar siempre que sea posible un componente ya configurado y modificar únicamente lo necesario. Esto conserva el diseño y reduce errores.
La estructura permite ampliar el informe siguiendo un proceso sencillo:
La parte verdaderamente importante no es la duplicación visual. Es comprobar que cada componente ha dejado de utilizar la fuente de la página original.
Antes de publicar cambios dejé preparada una serie de comprobaciones:
Muchas incidencias de analítica no aparecen porque la herramienta sea particularmente complicada, sino porque nadie realiza estas comprobaciones básicas cuando modifica una configuración existente.
Al terminar el proyecto reuní todos los recursos en una carpeta compartida. La entrega incluía el dashboard, la auditoría técnica, el manual de usuario y el manual de mantenimiento y ampliación.
Preparé además una comunicación final explicando qué era cada documento y para qué debía utilizarse. Puede parecer una parte menor después de toda la investigación técnica, pero una mala entrega puede hacer que un trabajo bien ejecutado resulte difícil de utilizar.
Visto únicamente desde el resultado final, puede parecer que el proyecto consistió fundamentalmente en diseñar algunas páginas en Looker Studio. La secuencia real fue bastante diferente.
Por eso considero que este trabajo fue realmente un proyecto de auditoría de Google Analytics, arquitectura de medición y reporting, no simplemente la creación de un dashboard.
Probablemente habría terminado antes, pero el resultado habría sido mucho peor.
Este es el motivo por el que considero que la auditoría previa aportó mucho más valor que cualquier gráfico concreto del dashboard.
No todos los problemas producen una caída evidente a cero. Muchas veces aparecen como pequeñas incoherencias que se normalizan con el tiempo.
| Señal | Qué podría indicar |
|---|---|
| Dos propiedades con cifras casi idénticas | Medición paralela o duplicada |
| Dos propiedades con diferencias enormes | Implementaciones o históricos distintos |
| Mucho tráfico Unassigned | Problemas de atribución o etiquetado |
| Dominios inesperados | Cross-tagging o medición compartida |
| Eventos duplicados | Varias etiquetas midiendo la misma acción |
| Picos sin explicación | Campaña, error técnico o contaminación |
| GTM que nadie reconoce | Arquitectura heredada sin documentación |
Después de este proyecto, estas son algunas de las comprobaciones que realizaría antes de conectar cualquier fuente a un sistema de reporting.
El caso de contaminación demuestra el valor de una dimensión que muchas veces no aparece en los informes habituales.
Revisaría hostname cuando una propiedad recibe datos de varios dominios, aparecen URLs inesperadas, existen subdominios o entornos de pruebas, se comparten configuraciones o sospechamos que una etiqueta está instalada en una web equivocada.
Podemos utilizarlo para separar datos y cuantificar el problema. Sin embargo, la solución real sigue siendo impedir que el evento llegue a una propiedad que no debe recibirlo.
Filtrar no convierte una implementación incorrecta en una implementación correcta.
Una vez el equipo técnico aplique las correcciones, el trabajo no debería darse por terminado inmediatamente.
Esta última fecha será especialmente importante para futuros análisis. El histórico contaminado continuará existiendo y no debe compararse con el periodo posterior como si toda la serie tuviera la misma calidad.
Otro aprendizaje del proyecto fue que tener una herramienta instalada no significa necesariamente que la empresa tenga control completo sobre ella.
Puede existir una propiedad de Analytics sin permisos administrativos, un GTM activo cuyo propietario no está claro, Search Console inaccesible para la cuenta de reporting o una cuenta publicitaria gestionada por un proveedor anterior.
Los proveedores necesitan acceso para trabajar, pero considero recomendable que los activos principales permanezcan bajo control de la empresa. Esto simplifica cualquier auditoría futura y evita que un cambio de proveedor implique perder conocimiento o acceso a la infraestructura.
La arquitectura se vuelve mucho más fácil de mantener cuando las fuentes tienen nombres comprensibles.
Elementos llamados “Analytics 2”, “Web nueva”, “Prueba final” o “GA4 nuevo 2” pueden resultar claros para quien los creó y completamente inútiles dos años después.
Prefiero nombres que relacionen plataforma y proyecto:
Es una decisión pequeña, pero ayuda muchísimo cuando la arquitectura crece.
Esta fue la principal razón para crear los manuales y documentar las fuentes. Si mañana otra persona se hace cargo del reporting, debería poder saber qué propiedad utiliza cada proyecto, cuáles están excluidas, dónde existen problemas y cómo incorporar nuevas fuentes.
No debería necesitar reconstruir toda mi investigación ni depender de que yo recuerde verbalmente cada decisión.
La primera versión se centra fundamentalmente en Google Analytics 4 y Search Console, pero la arquitectura permite evolucionar hacia un sistema mucho más amplio.
Google Ads puede incorporar inversión y conversiones; Metricool puede añadir redes sociales; Google Business Profile puede aportar información local; y un CRM podría conectar finalmente los canales de adquisición con leads, oportunidades y ventas.
En ese momento el dashboard dejaría de responder únicamente a preguntas como “¿cuántas sesiones hemos tenido?” para empezar a responder otras mucho más cercanas al negocio: qué canal genera oportunidades, qué campaña obtiene mejores resultados o qué contenido termina contribuyendo a captar clientes.
Aunque este artículo no pretende competir con las páginas comerciales dedicadas al posicionamiento, mi experiencia en SEO influye inevitablemente en la forma de interpretar la analítica.
No me interesa únicamente el número total de sesiones. Quiero saber qué URL las capta, qué búsqueda está detrás, qué canal ha generado la visita y qué ocurre posteriormente.
El caso del cross-tagging demuestra además por qué esta visión necesita una medición sólida. Un supuesto crecimiento orgánico carece de valor si una parte importante del tráfico pertenece realmente a otra web.
Después de todo el proyecto, la secuencia puede resumirse de una forma bastante sencilla:
Empezar directamente por el punto ocho habría sido más rápido. También habría producido un resultado mucho menos fiable.
Este proyecto confirma algo que considero cada vez más importante: tener muchos datos no significa necesariamente disponer de buena información.
Una empresa puede tener varias propiedades de Google Analytics, cientos de eventos, Search Console, campañas, redes sociales y un dashboard espectacular. Si nadie sabe de dónde procede cada cifra, toda esa infraestructura puede generar más confusión que conocimiento.
En este caso, antes de construir el reporting encontré dos propiedades midiendo prácticamente el mismo tráfico, otras dos con diferencias enormes, un 34,47 % de Unassigned en una de ellas, varios contenedores de GTM, configuraciones sin acceso, una retención limitada y una web enviando datos al Analytics de otra hasta el punto de que aproximadamente el 60 % de las sesiones analizadas procedía del dominio incorrecto.
Si hubiera empezado directamente por Looker Studio, todos esos problemas habrían quedado escondidos detrás de gráficos aparentemente correctos.
Una vez entendida la medición, el dashboard sí aporta muchísimo valor. Permite reunir adquisición, comportamiento, SEO y futuras capas de publicidad o social media dentro de una herramienta común. Pero la visualización debe ser la consecuencia de una arquitectura suficientemente entendida, no un sustituto de esa arquitectura.
El objetivo final tampoco debería ser saber simplemente cuántas sesiones tiene una web. Lo interesante es relacionar esas visitas con consultas, páginas, campañas, eventos y, finalmente, resultados comerciales.
Cuando una empresa tiene varias webs, propiedades creadas en momentos diferentes, Google Tag Manager gestionados históricamente por distintos proveedores o métricas que cambian dependiendo de dónde se consulten, merece la pena revisar primero la arquitectura de medición.
Dentro de mis servicios de marketing digital, SEO y SEM puedo abordar proyectos relacionados con:
Porque antes de decidir qué KPI colocar en la parte superior, qué gráfica utilizar o qué diseño queda mejor, existe una pregunta bastante más importante:
¿podemos confiar realmente en los datos que vamos a poner dentro del dashboard?
Mi experiencia con ChatGPT Work local y Work Cloud: diferencias de archivos, navegador, autonomía y contexto en proyectos de SEO,… Leer más
Leave a Comment