[GA4] Estructura de cuentas de Google Analytics

Consulte ejemplos de configuraciones de cuentas y propiedades de Google Analytics, y descubra principios de organización de cuentas y propiedades

En Universal Analytics (UA), las vistas se utilizan para crear colecciones de datos independientes, como separaciones geogrÔficas, separaciones entre líneas de negocio, etc. En Google Analytics 4 (GA4), no existen las vistas y este tipo de separación de datos se puede hacer de manera distinta. La granularidad con que separe los datos y cómo controle el acceso a ellos dependen, por un lado, de sus necesidades y, por otro, de si usa la versión estÔndar de Google Analytics (GA) o Google Analytics 360 (GA360).

El objetivo de este artƭculo es explicar la estructura de cuentas de empresas grandes. Si gestiona la cuenta de una empresa pequeƱa o mediana, puede que no necesite tener en cuenta la estructura de su cuenta.

Ejemplo de configuraciones de cuentas de GA

Una empresa con un sitio web

 

Esta empresa tiene un sitio web y una cuenta de Google Ads. La empresa no necesita separar los datos según la región ni la línea de negocio.

Estructura de cuentas estƔndar de GA

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para el sitio web.
  • Un flujo de datos. Si la empresa tambiĆ©n tiene una aplicación, se debe usar un flujo de datos independiente para la aplicación.

Principios aplicados

Estructura Motivo

Una cuenta de Analytics.

Si ya se dispone de una cuenta de Analytics, no es necesario crear otra.

Los datos pertenecen a una sola entidad en una sola ubicación.

Una propiedad de GA4 con un flujo de datos (web).

Tener una única propiedad hace que los datos de todos los aspectos del sitio estén disponibles en un solo lugar.

El equipo de marketing puede crear audiencias a partir de cualquier sección de datos del sitio.

Los analistas pueden conocer el uso en distintos dispositivos y evaluar si es necesario disponer de un sitio web o una aplicación móviles.

Una cuenta de Google Ads vinculada a la propiedad de GA4.

El equipo de marketing puede exportar audiencias a Google Ads con fines de remarketing y prospección.

 

Una institución o empresa educativa

 

Esta organización tiene un sitio web y una cuenta de Google Ads.

Requisitos empresariales

La estructura de la cuenta debe cumplir los siguientes requisitos:

  • Los alumnos revisan las ofertas de cursos, se registran en ellos y hacen y gestionan los trabajos de los cursos.
  • Es necesario que el equipo de marketing pueda crear audiencias para el remarketing y la prospección.
  • Es necesario que los analistas puedan conocer el uso en distintos dispositivos y evaluar si es preciso disponer de un sitio web o una aplicación móviles.

Estructura de cuentas estƔndar de GA

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para cada base de usuarios lógica (el sitio de la institución).
  • Un flujo de datos para el sitio web de la institución.

Principios aplicados

Estructura Motivo

Una cuenta de Analytics.

Si ya se dispone de una cuenta de Analytics, no es necesario crear otra.

Los datos pertenecen a una sola entidad en una sola ubicación.

Una propiedad de GA4 con un flujo de datos (web).

Tener una única propiedad hace que los datos de todos los aspectos del sitio estén disponibles en un solo lugar.

El equipo de marketing puede crear audiencias a partir de cualquier sección de datos del sitio.

Los analistas pueden conocer el uso en distintos dispositivos y evaluar si es necesario disponer de un sitio web o una aplicación móviles.

Una cuenta de Google Ads vinculada a la propiedad de GA4.

El equipo de marketing puede exportar audiencias a Google Ads con fines de remarketing y prospección.

 

Una empresa de comercio electrónico distribuida geogrÔficamente que vende productos en la Web y en aplicaciones

 

La empresa matriz tiene presencia en varias regiones geogrÔficas y dispone de una entidad empresarial en cada una de ellas. Cada región cuenta con un sitio web, un equipo de marketing y una cuenta de Google Ads distintos. La empresa matriz también tiene una aplicación disponible para iOS y Android.

Requisitos empresariales

La estructura de la cuenta debe cumplir los siguientes requisitos:

  • Es necesario que la empresa matriz tenga una visión global de los datos de todas las entidades empresariales.
  • No es necesario que cada entidad empresarial tenga la titularidad legal de sus datos.
  • Cada entidad empresarial debe ser capaz de saber cómo es el recorrido del usuario por el sitio web y la aplicación.
  • Cada entidad empresarial debe compartimentar sus datos.
  • El equipo de marketing de cada entidad empresarial utiliza la vinculación de Google Ads con Analytics para crear y compartir audiencias, y utiliza las audiencias para pujar en Google Ads.

Estructura de cuentas estƔndar de GA

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para una Ćŗnica base de usuarios lógica.
  • Un flujo de datos para el sitio web y uno para cada versión de la aplicación.

Estructura de cuentas de GA360

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para una Ćŗnica base de usuarios lógica.
  • Una subpropiedad por cada entidad empresarial que necesita compartimentar datos.
  • Un flujo de datos para el sitio web y uno para cada versión de la aplicación.

Principios aplicados

Estructura Motivo

Una cuenta de Analytics.

Si ya se dispone de una cuenta de Analytics, no es necesario crear otra.

La empresa matriz tiene la titularidad legal de los datos de todas las entidades empresariales.

Una propiedad de GA4.

Tener una única propiedad con flujos de datos para cada sitio web o implementación de aplicación permite que todos los datos se incluyan en el mismo informe.

Puede combinar los datos de los sitios y las aplicaciones según le resulte mÔs adecuado para ver el recorrido de los clientes entre ambos. La empresa matriz dispone de una vista unificada de todos los datos y puede compararlos entre distintas entidades empresariales.

Una subpropiedad por cada equipo regional (360).

Cada entidad regional tiene su propia subpropiedad con datos compartimentados. La empresa matriz dispone de una vista unificada de todos los datos en la propiedad fuente y puede compararlos entre distintas entidades empresariales.

Un flujo de datos que combina todos los sitios web regionales de la empresa.

Utilizar un flujo de datos web para varios dominios.

Un proyecto de Firebase para las implementaciones de la aplicación en Android y iOS. El proyecto de Firebase estÔ vinculado a la propiedad de GA4.

Dos flujos de datos, uno para cada versión de la aplicación (iOS y Android).

Tener un flujo de datos independiente para cada implementación de aplicación (iOS y Android) permite aislar los datos de cada versión.

 

Cada cuenta de Google Ads estƔ vinculada a la propiedad (estƔndar).

Como todas las cuentas de Google Ads estƔn vinculadas a una propiedad, las audiencias de la propiedad pueden usarse para pujar en todas las cuentas.

Opcional: Cada cuenta de Google Ads estĆ” vinculada a la subpropiedad correspondiente (360).

Como todas las cuentas de Google Ads estƔn vinculadas a su subpropiedad correspondiente, las audiencias de la propiedad pueden usarse para pujar en todas las cuentas.

 

Un desarrollador de juegos global con varios juegos en Play Store y el App Store

 

Esta empresa tiene un sitio web de marca global y otro de marketing para cada juego. Tiene varios juegos a la venta en Play Store y el App Store.

Requisitos empresariales

La estructura de la cuenta debe cumplir los siguientes requisitos:

  • Recoger datos propios de sitios web y aplicaciones para crear audiencias y basar en ellos las compras de medios.
  • Contar con un entorno independiente para el desarrollo, el staging y la producción de cada juego.

Estructura de cuentas estƔndar de GA

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para cada base de usuarios lógica (el sitio web de marca global, el sitio web de marketing y la aplicación de cada juego).
  • Un flujo de datos para el sitio web de marca global. Un flujo de datos para cada sitio de marketing y otro para cada versión de la aplicación.

Estructura de cuentas de GA360

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para cada base de usuarios lógica (el sitio web de marca global, el sitio web de marketing y la aplicación de cada juego).
  • Una propiedad de agrupación que obtiene datos de todas las propiedades fuente independientes para obtener una vista global.
  • Un flujo de datos para el sitio web de marca global. Un flujo de datos para cada sitio de marketing y otro para cada versión de la aplicación.

Principios aplicados

Estructura Motivo

Una cuenta de Analytics.

Si ya se dispone de una cuenta de Analytics, no es necesario crear otra.

Unificar las propiedades en una sola cuenta que pertenece a una sola entidad legal.

Una propiedad de GA4 para el sitio de marca global, con un flujo de datos (web).

Realizar de forma independiente la medición del sitio de marca global.

Una propiedad de GA4 para la aplicación y el sitio de marketing de cada juego. Cada propiedad tiene un flujo de datos (web), un flujo de datos (de aplicación) iOS y un flujo de datos (de aplicación) Android.

Recoger los datos de cada sitio de marketing y de la aplicación correspondiente en la misma propiedad.

Utilizar los datos de sitios y aplicaciones para crear audiencias y basar en ellos las compras de medios.

Un proyecto de Firebase por cada juego. Cada proyecto estÔ vinculado a la propiedad correspondiente. Cada proyecto de Firebase incluye las versiones de desarrollo, staging y producción del juego.

Tener un proyecto de Firebase independiente para cada juego crea un entorno distinto para el desarrollo, el staging y la producción de cada juego.

Opcional: Un proyecto de Firebase independiente para cada versión del juego o combinación de versiones; por ejemplo, un proyecto para la versión en desarrollo y otro para las versiones en staging y en producción.

Se pueden subdividir los entornos de juego individuales por proyecto, pero se necesitan mÔs propiedades si se quiere medir la versión del juego asociada a ese proyecto.

Opcional: Propiedad de agrupación. Cada propiedad fuente se incluye en una propiedad de agrupación, que ofrece una visión global de la Web y de las aplicaciones.

Se pueden subdividir los entornos de juego individuales por proyecto, pero se necesitan mÔs propiedades si se quiere medir la versión del juego asociada a ese proyecto.

 

Una empresa de seguros nacional con varias filiales independientes (vida, salud, hogar, automóvil)

 

Esta empresa tiene un sitio web para proporcionar información a los clientes y generar oportunidades de venta que requieren una interacción offline para ultimar el contrato (por ejemplo, por teléfono, por correo o en un punto de venta). Cada filial tiene un sitio web, un equipo de marketing y una cuenta de Google Ads propios.

La filial de seguros de automóvil también tiene una aplicación.

Requisitos empresariales

La estructura de la cuenta debe cumplir los siguientes requisitos:

  • Los datos pertenecen a una sola entidad empresarial en una sola ubicación.
  • Los datos del sitio corporativo de la empresa deben poder analizarse para mejorar la generación de oportunidades de venta y la optimización del contenido.
  • Cada filial debe compartimentar sus datos para que el equipo de marketing correspondiente pueda crear audiencias y hacer un seguimiento de las conversiones asociadas a una sola cuenta de Google Ads.

Estructura de cuentas estƔndar de GA

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para cada base de usuarios lógica (el sitio de la empresa y el sitio y la aplicación de cada filial).
  • Un flujo de datos para el sitio web de la empresa. Un flujo de datos para el sitio web de cada filial y para cada versión correspondiente de la aplicación.

Estructura de cuentas de GA360

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para todos los sitios y aplicaciones (el sitio de la empresa y el sitio y la aplicación de cada filial).
  • Una subpropiedad por cada base de usuarios lógica (el sitio de la empresa y el sitio y la aplicación de cada filial).
  • Un flujo de datos para el sitio web de la empresa. Un flujo de datos para el sitio web de cada filial y para cada versión correspondiente de la aplicación.

Principios aplicados

Estructura Motivo

Una cuenta de Analytics.

Si ya se dispone de una cuenta de Analytics, no es necesario crear otra.

Los datos pertenecen a una sola entidad empresarial en una sola ubicación.

Una propiedad de GA4 con un flujo de datos (web) para el sitio web de la empresa (cuenta estƔndar).

Tener una única propiedad y un único flujo de datos para el sitio web de la empresa permite analizar los datos para mejorar la generación de oportunidades de venta y la optimización del contenido.

Para el sitio web de cada filial: (cuenta estƔndar).

Una propiedad de GA4 con un flujo de datos (web).

La propiedad de la filial de seguros de automóvil también necesita un flujo de datos de aplicación Android.

Tener una Ćŗnica propiedad y un Ćŗnico flujo de datos para el sitio de cada filial mantiene separados los datos de cada sitio.

Los datos web y de la aplicación de la filial de seguros de automóvil estarÔn disponibles en la misma propiedad.

Una propiedad de GA4 con un flujo de datos (web) para todos los sitios web (el de la empresa y el de la filial). (360)

Tener una única propiedad fuente y un único flujo de datos para todos los sitios web permite analizar los datos y mejorar la generación de oportunidades de venta y la optimización del contenido. AdemÔs, permite que se puedan crear subpropiedades a partir de la propiedad fuente.

Subpropiedades para el sitio web de la empresa y de cada filial.

Se puede crear una subpropiedad para filtrar cada combinación de datos lógica (sitio web de la empresa o de filial) en su propia vista de datos.

Un proyecto de Firebase para la aplicación Android de la filial de seguros de automóvil.

El proyecto de Firebase estÔ vinculado a la propiedad de la filial de seguros de automóvil (cuenta estÔndar) o a la propiedad fuente (cuenta de 360).

Tener un proyecto de Firebase para la aplicación de seguros de automóvil crea un entorno independiente para el desarrollo de la aplicación.

Al vincular el proyecto de Firebase con la propiedad, los datos web y de la aplicación estÔn disponibles en la misma propiedad (igual que en la propiedad fuente, en las cuentas de GA360).

Las propiedades (cuentas estƔndar) o subpropiedades (cuentas de 360) de las filiales estƔn vinculadas a las cuentas de Google Ads correspondientes.

Como la cuenta de Google Ads de cada filial estÔ vinculada con la propiedad de GA4 correspondiente, las audiencias de las propiedades estÔn disponibles en las cuentas pertinentes, y los datos de conversión de las cuentas de Google Ads estÔn disponibles en las propiedades de GA4 correspondientes.

 

Una empresa de viajes con varias marcas que tiene presencia en varios paĆ­ses

 

Esta empresa tiene varias marcas, cada una de ellas con un sitio web para ordenadores, un sitio web móvil y una aplicación. Cada marca tiene su propio equipo de marketing y sus propias cuentas publicitarias.

Requisitos empresariales

La estructura de la cuenta debe cumplir los siguientes requisitos:

  • Los datos deben analizarse por paĆ­s.
  • Cada equipo de marketing debe crear sus propias audiencias y atribuir conversiones a sus cuentas publicitarias vinculadas.

Estructura de cuentas estƔndar de GA

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para cada base de usuarios lógica (el sitio de la empresa y el sitio y la aplicación de cada marca).
  • Un flujo de datos para el sitio web de la empresa. Un flujo de datos para el sitio de cada marca y otro para cada versión de la aplicación.

Estructura de cuentas de GA360

  • Una cuenta. Los datos pertenecen a una sola entidad legal.
  • Una propiedad para cada base de usuarios lógica (el sitio de la empresa y el sitio y la aplicación de cada marca).
  • Una propiedad de agrupación para ver todos los conjuntos de datos geogrĆ”ficos y de entidades.
  • Un flujo de datos para el sitio web de la empresa. Un flujo de datos para el sitio de cada marca y otro para cada versión de la aplicación.

Principios aplicados

Estructura Motivo

Una cuenta de Analytics.

Si ya se dispone de una cuenta de Analytics, no es necesario crear otra.

Los datos pertenecen a una sola entidad empresarial.

Una propiedad de GA4 por marca, cada una de ellas con lo siguiente:

  • Un flujo de datos (web) para el sitio web de la marca
  • Un flujo de datos (de aplicación) para cada versión de la aplicación de la marca (Android o iOS)

Tener una propiedad por marca permite hacer lo siguiente:

  • Hacer anĆ”lisis por marca y paĆ­s.
  • Crear audiencias a partir de la base de usuarios de una marca y un paĆ­s especĆ­ficos.
  • Atribuir conversiones a las cuentas publicitarias vinculadas.

Tener flujos de datos individuales para cada plataforma permite hacer un anƔlisis de datos integral, comparativo o individual, y crear audiencias centradas en la plataforma.

Una propiedad de agrupación que reúne todas las propiedades de marca en un mismo lugar (cuentas de 360).

Una única propiedad de agrupación con todas las propiedades fuente incluidas ofrece una vista global de los datos a nivel de institución.

Las cuentas de Google Ads, Display & Video 360 y Search Ads 360 especƭficas de una marca estƔn vinculadas a las propiedades correspondientes.

Cada equipo de marketing debe crear sus propias audiencias y atribuir conversiones a las cuentas publicitarias vinculadas.

 

GuĆ­a y referencia ampliadas

El resto de esta guía proporciona información detallada para las empresas cuyas necesidades van mÔs allÔ de los ejemplos de la sección anterior. Esta guía le resultarÔ especialmente útil si es cliente de Google Analytics 360.

ƍndice:

Conceptos y definiciones

Si quiere obtener información sobre las propiedades de GA4, puede que los artículos que se indican a continuación y estos vídeos le resulten útiles:

  • Cuenta: es una colección de propiedades cuyos datos pertenecen a una sola entidad legal y que se rige por los tĆ©rminos del servicio especĆ­ficos de cada región.
    ¿Es importante que los datos de cada región pertenezcan a una entidad legal específica de esa región?
    • SĆ­: cree varias cuentas, una para cada región.
    • No: cree una cuenta en la región en que se encuentre la sede de su empresa.
  • Propiedad: estĆ” alojada en una cuenta y representa los datos de una base de usuarios. Si hay datos que deban analizarse de forma conjunta (por ejemplo, de lĆ­neas de productos, marcas o aplicaciones), le recomendamos que los agrupe en la misma propiedad (que puede servirle de propiedad fuente si tiene GA360).
    ¿Los datos que recoge estÔn relacionados con una única base de usuarios lógica? Al vincular Analytics con otros productos, ¿quiere compartir todo ese conjunto de datos con cada producto?
    • SĆ­: cree una propiedad.
    • No: cree una propiedad independiente o una subpropiedad para cada base de usuarios lógica.
  • Flujo de datos: se ubica en una propiedad y es el origen de los datos procedentes de una aplicación o de un sitio web. Le recomendamos usar un mĆ”ximo de tres flujos de datos por propiedad: un Ćŗnico flujo de datos web para medir el recorrido que siguen los usuarios en la Web, y dos flujos de datos de aplicaciones (uno para iOS y otro para Android).
    • Flujo de datos de aplicaciones: puede tener un flujo de datos para cada combinación de nombre de paquete de aplicaciones y plataforma.
    • Flujo de datos web: en la mayorĆ­a de los casos, debe usar un solo flujo de datos web para medir el recorrido web de los usuarios. Para garantizar la coherencia de los informes de usuarios y de sesiones en el caso de recorridos web que abarquen varios dominios, use un flujo de datos web combinado con la medición multidominio.

PrƔcticas recomendadas

Estas prÔcticas recomendadas y sugerencias estÔn pensadas para cubrir una gran variedad de usuarios y casos prÔcticos. Puede haber casos extremos en los que esta directriz no sea aplicable o deba adaptarse a las circunstancias concretas de cada situación.

Por lo general, deberĆ­a configurar una cuenta por empresa y una propiedad por marca o unidad de negocio, siempre que sus marcas y unidades de negocio sean entidades operativas Ćŗnicas o distintas con grupos de colaboradores o analistas independientes.

Ejemplo A

  • Empresa matriz A: 1 cuenta 
    • Marca X (automoción): 1 propiedad
    • Marca Y (artĆ­culos domĆ©sticos): 1 propiedad
    • Marca Z (electrónica de consumo): 1 propiedad

En este caso, la empresa matriz tiene una cuenta y tres propiedades distintas, y cada propiedad contiene datos relacionados Ćŗnicamente con la marca o la lĆ­nea de negocio correspondientes.

Ejemplo B

  • Gran empresa B: 1 cuenta
    • LĆ­nea de productos D (seguros de hogar): 1 propiedad
    • LĆ­nea de productos E (seguros de coche): misma propiedad que D
    • LĆ­nea de productos F (seguros de vida): misma propiedad que D y E

En este caso, la empresa ha elegido que todas sus lĆ­neas de negocio envĆ­en sus datos a una Ćŗnica propiedad. Puede que tengan clientes que usen varios productos regularmente o puede que pongan en prĆ”ctica a menudo campaƱas de venta incremental o de venta cruzada entre productos, por lo que ver todos estos datos juntos tiene sentido. Esta propiedad puede servirle de propiedad fuente de las subpropiedades en los anĆ”lisis de lĆ­neas de productos concretas (consulte los detalles mĆ”s abajo).  

Ejemplo C

  • PequeƱa empresa C (por ejemplo, Bocados gourmet): 1 cuenta
    • Todos los productos (delicatesen, sĆ”ndwiches, bebidas, etc.): 1 propiedad

En este ejemplo, Bocados gourmet es una pequeña empresa y no necesita varias propiedades. Analizan todos los datos procedentes de su negocio online de venta a domicilio de forma conjunta, porque sus clientes suelen comprar mÔs de un producto y no tiene líneas de negocio diferentes. Por eso, lo lógico es usar una propiedad para todos sus datos.

Flujos de datos

Cada propiedad fuente tiene flujos de datos que proporcionan información entrante de una aplicación o de un sitio web. Por lo tanto, un flujo de datos es simplemente un sitio web o una aplicación que envía datos a una determinada propiedad de GA4.

Estas son algunas recomendaciones:

  • Un flujo de datos web por propiedad
  • Un flujo de datos de una aplicación iOS por propiedad
  • Un flujo de datos de una aplicación Android por propiedad
A la hora de decidir qué flujos de datos vincular a una propiedad, tenga en cuenta que cada propiedad de GA4 solo puede tener vinculado un único flujo de datos de una aplicación.
Los flujos de datos no son el equivalente de las vistas en UA y no deben utilizarse para separar datos. Si las utiliza de esta forma, no podrÔ asociar usuarios a diferentes flujos de datos, ya que cada flujo es una fuente de recogida de datos independiente. Esta situación puede provocar una inflación de datos porque, en función del uso que haga de Google signals, de si ha iniciado sesión o no, o de su ID de usuario, puede que el sistema no anule los usuarios duplicados.

Integración con Search Console

Puede vincular una propiedad de GA4 con Search Console. De este modo, se importarÔn datos nuevos en abundancia a GA (como consultas procedentes de la búsqueda orgÔnica de Google) y dimensiones de registro de información (como la pÔgina de destino).

Tiene que decidir qué propiedad debe vincularse con qué propiedad de Search Console. Si usa subpropiedades y propiedades de agrupación, deberÔ decidir si quiere hacer la vinculación con la propiedad fuente, con la subpropiedad o con la propiedad de agrupación.

Vincular su propiedad de GA4 y su propiedad de Search Console es un proceso rƔpido y sencillo que puede realizar en la pƔgina Administrar de GA4. Tenga en cuenta que, para vincular ambas propiedades, debe ser un administrador verificado del sitio en la propiedad de Search Console, asƭ como tener el rol de administrador en la propiedad de GA4.

Personalizar quƩ informes se ven

Las propiedades de GA4 ofrecen control total sobre qué informes se muestran y las métricas, dimensiones y grÔficos incluidos en ellos. Puede configurar una colección completa de informes que solo sea pertinente para un grupo determinado, como el equipo de Marketing, pero tenga en cuenta que no puede restringir el acceso a estas colecciones. Todos los usuarios de la propiedad podrÔn verlas. De este modo, puede personalizar GA4 para que los informes mÔs relevantes sean los que aparecen primero o los de mÔs fÔcil acceso, sin tener que desplazarse por informes que quizÔ no necesite.

Ejemplo de una colección de informes relevantes para el equipo de marketing:

Ejemplo de colección de informes para el equipo de Marketing

Puede personalizar los informes especĆ­ficos de cada colección. Por ejemplo, la mayorĆ­a de los informes en forma de tabla incluyen la mĆ©trica "Total de ingresos", que se muestra en la configuración estĆ”ndar del informe. Esta función es muy Ćŗtil si tiene una empresa de comercio electrónico que envĆ­a datos de ingresos y quiere que sus equipos puedan analizarlos. Sin embargo, si no tiene datos de ingresos que registrar en GA, esta columna mostrarĆ” el valor de 0,00 ā‚¬ en cada fila. Si esta mĆ©trica no es pertinente para su empresa, puede quitarla para despejar los informes.

Informe "Eventos" con la mƩtrica "Total de ingresos":

Informe "Eventos" con la mƩtrica "Ingresos totales"

Interfaz de edición (haga clic en la "X" situada junto a la métrica que quiera quitar):

Interfaz de edición de eventos (haga clic en la X situada junto a la métrica que quiera quitar)

Aplique los cambios y guarde el informe sin la mƩtrica "Total de ingresos":

Evento guardado sin la mƩtrica "Ingresos totales"

Este informe es ahora mucho mƔs fƔcil de consultar para una empresa que no tiene (o no quiere mostrar) datos de ingresos en GA.

PrƔcticas recomendadas de higiene de datos

AdemÔs de aplicar filtros a sus informes para incluir o excluir determinados datos, preste especial atención a la higiene de datos. Entre las tareas de higiene de datos se cuentan las siguientes: excluir el trÔfico de IPs internas, excluir referencias no deseadas y asegurarse de que la medición multidominio estÔ configurada correctamente.

Exclusión del trÔfico de IPs internas

Quitar el trÔfico de IPs internas de los conjuntos de datos puede ser un paso importante de la configuración para muchas empresas que registran un gran volumen de trÔfico de empleados en su sitio web. Por ejemplo, los técnicos de asistencia suelen hacer referencia a artículos del centro de ayuda del sitio web de sus empresas al trabajar con clientes. De este modo, los empleados de su empresa (los usuarios internos) no influirÔn en las analíticas que usa para determinar el comportamiento de los clientes externos. Este es ahora un filtro predefinido de GA4:

Interfaz "Crear regla de trƔfico externo"

Exclusión de las referencias no deseadas

Otro aspecto de las prÔcticas recomendadas de higiene de datos que debe tener en cuenta es la exclusión del trÔfico referido no deseado. Así evitarÔ que los datos de determinadas fuentes referentes se mezclen con sus datos de producción. Al hacerlo de esta manera, se conserva el evento, pero se ignora la URL referente para que la atribución de trÔfico no se vea afectada. Esta es otra configuración predefinida de GA4.

Interfaz "Hacer lista de referencias no deseadas"

Configuración del seguimiento multidominio

Por último, un problema habitual al que siempre se han enfrentado los usuarios de GA es la gestión del trÔfico multidominio. Antes había que configurar el seguimiento multidominio con Google Tag Manager o con otro sistema de gestión de etiquetas, o bien fijarlo en el código fuente del sitio web. Esta operación requería un esfuerzo adicional que los usuarios de GA no siempre podían realizar y, por lo tanto, conllevaba problemas de higiene de datos, como recuentos de sesiones nuevos o excesivos, así como referencias procedentes de dominios de su propiedad. En la interfaz de usuario de GA4, configurar este seguimiento para mejorar la higiene de datos es un proceso muy sencillo:

Interfaz "Configurar sus dominios"

Transformación de datos

En UA, la transformación de datos se gestiona como parte de la configuración de los filtros. Por ejemplo, puede obligar al sistema a que represente en minúsculas todos los valores de una determinada dimensión, como utm_campaign. Ahora, este proceso se puede gestionar mediante la creación y modificación de eventos en propiedades de GA4.

Por ejemplo, supongamos que descubre que se ha enviado un evento determinado a su propiedad de GA4 dos veces, pero de dos maneras distintas. Por ejemplo, el evento "start_now", que genera una acción clave en su sitio web, se podría estar enviando a GA4 de varias maneras (como "start_now" y "startNow") porque aparece en varias secciones del sitio web que fueron desarrolladas por distintos equipos que, sin saberlo, escribieron el código de forma diferente. Esta es una situación habitual que puede afectar a la calidad de los datos. Ahora puede corregir este problema creando y modificando eventos en la interfaz de usuario.

Interfaz "Eventos"

Para solucionar este problema, en la sección Configurar de su propiedad de GA4, haga clic en Modificar evento.

Botón "Modificar evento" de la sección Configurar

Se abrirƔ esta pantalla, donde podrƔ especificar los cambios que quiera hacer. En este caso, deberƭa elegir quƩ evento "Start Now" quiere conservar y modificar el otro para que ambos coincidan. En el ejemplo siguiente, todos los eventos denominados "startNow" pasarƔn a llamarse "start_now". De esta forma, los dos nombres de evento se fusionarƔn en uno solo. Los informes tendrƔn una apariencia mucho mƔs despejada, ya que mostrarƔn una sola fila para representar este evento.

Interfaz "Modificar eventos"

Permisos y roles de usuario

Las propiedades de GA4 incluyen funciones optimizadas y mƔs inteligentes para gestionar roles y restricciones. Entre los roles estƔndar ahora se incluyen los siguientes:

  • Administrador: un usuario con control total sobre la cuenta
  • Editor: un usuario que tiene permiso completo para editar datos y ajustes, pero que no puede gestionar usuarios
  • Analista: un usuario que puede crear y editar elementos compartidos, ademĆ”s de ver datos y configuraciones
  • Lector: un usuario que puede ver los datos registrados y los ajustes de configuración de los informes

AdemÔs, las propiedades de GA4 permiten ocultar los datos de costes e ingresos en la interfaz de los informes si el usuario que los consulta tiene asignado el rol "Sin acceso a métricas de costes" o el rol "Sin acceso a métricas de ingresos". Esta función adicional de los permisos de usuarios es útil para proteger datos empresariales sensibles y, al mismo tiempo, permitir que determinadas audiencias puedan acceder a los datos del sitio y a los datos sobre el comportamiento de los usuarios.

Nota sobre las restricciones de acceso a los costes y a los ingresos: Los filtros de mĆ©tricas no funcionarĆ”n en una audiencia que pueda ver datos de ingresos. AdemĆ”s, los usuarios con estas restricciones podrĆ”n seguir viendo los recuentos de eventos de compra. Por lo tanto, si no quiere que los usuarios puedan ver los recuentos de eventos relativos a los datos de compras en esta situación, deberĆ” usar una subpropiedad.

Interfaz "Roles y restricciones de datos directos"

Funciones específicas de 360: subpropiedades y propiedades de agrupación

Subpropiedades

Las subpropiedades son un nuevo tipo de propiedad de GA4 disponible en las cuentas de GA360. Permiten crear un subconjunto de los datos de una propiedad fuente. Gracias a las subpropiedades, las vistas ya no son necesarias. Por ejemplo, puede crear una subpropiedad que tenga un subconjunto de los datos de la propiedad fuente y proporcionar a determinados usuarios acceso solo a esa subpropiedad. AdemÔs, las subpropiedades proporcionan funciones de higiene de datos, así como de gobierno de datos y gestión de usuarios y funciones, que se suman a las considerables ventajas de usar GA4 en grandes empresas.

Puede crear una subpropiedad a partir de cualquier propiedad fuente, pero no puede crearla a partir de una propiedad de agrupación. Las subpropiedades tienen una relación "uno a uno" con la propiedad fuente a partir de la que se han creado.

Las subpropiedades suponen un coste adicional para los clientes de la versión 360. Consulte mÔs información en la sección Consideraciones sobre el coste de este artículo.

Gobierno de datos

Uno de los principales casos prƔcticos de las subpropiedades es el gobierno de datos, que consiste en controlar quƩ datos se incluyen o se excluyen de una propiedad. Al incluir o excluir datos de una subpropiedad, puede crear un conjunto de datos especƭfico para cubrir las necesidades de una audiencia determinada o para utilizarlo en un caso prƔctico concreto. De esta forma, puede organizar mejor sus datos para que determinadas audiencias puedan acceder a ellos mƔs fƔcilmente.

Así se usaban habitualmente las vistas en UA; por ejemplo, para crear una vista solo para el trÔfico procedente de Norteamérica o para crear una vista solo para los datos del sitio web de marketing. Al separar estos datos en dos conjuntos independientes, cada grupo puede acceder a su información de forma mÔs fÔcil y rÔpida que aplicando mÔs filtros en la propiedad fuente, aunque el resultado sería el mismo. Esto es precisamente lo que puede hacer con las subpropiedades, ya que puede importar y exportar filtros de una propiedad fuente a una subpropiedad en este tipo de situaciones.

Para incluir o excluir de una subpropiedad los datos de una propiedad fuente, puede utilizar cualquier evento o dimensión personalizada que se recoja en la propiedad fuente.

Gestión de usuarios

Las subpropiedades también pueden usarse para gestionar usuarios. Por ejemplo, su empresa podría tener políticas empresariales estrictas según las cuales los usuarios de una región (por ejemplo, Norteamérica) pueden ver un determinado subconjunto de datos relacionado con su región, mientras que los de otra región (por ejemplo, Sudamérica) no deberían tener acceso a ellos. Al usar subpropiedades, puede restringir los datos de cada región dentro de su respectiva propiedad. De esta forma, no se podría acceder a los datos desde fuera de la región correspondiente.

Algo similar sucederƭa con las lƭneas de negocio que tienen datos que hay que mantener separados para cubrir sus respectivas necesidades operativas. TambiƩn podrƭa darse el caso de que hubiera que separar los datos procedentes del sitio de marketing y los relativos a la experiencia de producto (por ejemplo, si la empresa tuviera motivos para que un equipo no pudiera ver los datos de otro).

Si no tiene que restringir el acceso a los datos, sino que solo necesita dirigir un subconjunto de usuarios específico a determinados conjuntos de datos, la personalización de informes y las colecciones de informes pueden ser una solución mÔs conveniente. Por ejemplo, podría crear una colección de informes específica para el equipo de Marketing, de forma que sus miembros puedan consultar mÔs fÔcilmente los datos que les interesan. Estas funciones ayudan a organizar los datos para audiencias específicas en un formato de fÔcil acceso y sin coste adicional.

Propiedades de agrupación

Una propiedad de agrupación contiene datos de dos o mÔs propiedades. Una propiedad de este tipo puede incluir datos de propiedades comunes y de subpropiedades, pero no de otras propiedades de agrupación. Estas propiedades aportan una visión mÔs amplia de la empresa en lo referente a diferentes productos, marcas o regiones, ya que reúnen datos de varias propiedades de la misma cuenta. Las propiedades de agrupación en GA4 y UA admiten casos similares.

Las propiedades de agrupación funcionan prĆ”cticamente igual que cualquier otra propiedad. Cada propiedad de agrupación tiene su propia cuota de dimensiones personalizadas, mĆ©tricas personalizadas, propiedades de usuario y otros parĆ”metros. Todos los ajustes se controlan desde la propiedad de agrupación, ya que estas propiedades no heredan la configuración de sus respectivas propiedades fuente. AdemĆ”s, son ajustes especĆ­ficos de las propiedades de agrupación y han sido diseƱados para cubrir las necesidades de su base de usuarios.

Las propiedades de agrupación conllevan un coste adicional para los clientes de la versión 360. Consulte mÔs información en la siguiente sección.

Consideraciones sobre el coste

Cada evento que se envía a una subpropiedad o a una propiedad de agrupación se procesa dos veces, lo que conlleva un coste adicional para las cuentas de la versión 360. Cada hit de evento adicional se cobra a la mitad del precio del hit de evento inicial. Es decir, cada hit registrado por una subpropiedad o por una propiedad de agrupación cuesta un 50 % menos que un hit de evento.

Para saber cómo puede influir la configuración de su cuenta en sus facturas, puede usar una nueva función de vista previa de facturas. Con ella, los partners certificados de GA pueden consultar información mÔs precisa sobre los posibles costes de GA4 360.

Ejemplos de subpropiedades y propiedades de agrupación

Si retomamos algunos de los ejemplos que vimos al principio de esta guía, podremos analizar esas situaciones desde la perspectiva de la configuración.

Gran empresa con varias lĆ­neas de negocio complementarias

  • Gran empresa B: 1 cuenta
    • LĆ­nea de productos D (seguros de hogar): 1 propiedad
    • LĆ­nea de productos E (seguros de coche): misma propiedad que D
    • LĆ­nea de productos F (seguros de vida): misma propiedad que D y E

En este caso, la empresa tiene una cuenta con una propiedad fuente. Aunque hay distintas lƭneas de negocio con datos que podrƭan tener que analizarse por separado, los productos que las componen son complementarios y a menudo hay que analizar varios productos juntos, por lo que la empresa ha decidido enviar los datos de todos los productos a la misma propiedad fuente. No obstante, los equipos responsables de productos concretos necesitan analizar sus datos por separado. Debido al gran volumen de trƔfico que recibe toda la propiedad, han decidido crear subpropiedades para cada lƭnea de negocio.

Diagrama de una propiedad fuente con tres subpropiedades

 

Empresa matriz con varias marcas

  • Empresa matriz: 1 cuenta
    • Marca X (automoción): 1 propiedad
    • Marca Y (artĆ­culos domĆ©sticos): 1 propiedad
    • Marca Z (electrónica de consumo): 1 propiedad

En este caso, la empresa matriz tiene una cuenta con tres propiedades fuente, una por cada marca. Como cada marca se opera por separado y es necesario analizar sus datos de forma independiente, cada marca tiene su propiedad fuente. Sin embargo, la empresa matriz quiere ver todas sus marcas agrupadas en una sola propiedad para consultar información mÔs clara sobre el total de usuarios, el total de ingresos y otros aspectos. En este caso, la empresa matriz crearÔ una propiedad de agrupación con las tres propiedades de marca como fuentes agrupadas. De este modo, tendrÔ una visión global de sus necesidades y las marcas seguirÔn siendo independientes entre sí.

Diagrama de una empresa matriz con tres marcas

 

Veamos este ejemplo en detalle. Esta empresa matriz tiene un programa de fidelización que abarca todas sus marcas. Cuando un usuario participa en este programa, recibe un ID de bonificación único que podemos asociar al usuario como una propiedad de usuario o como un parÔmetro en cada evento.

El equipo responsable de este programa trabaja a nivel de empresa matriz y necesita ver los datos de los participantes del programa, relativos a todas las marcas, en una misma propiedad. Pueden conseguirlo usando una combinación de subpropiedades y propiedades de agrupación para que el equipo del programa de fidelización tenga su propio conjunto de datos con el que trabajar. Cada propiedad fuente produciría una subpropiedad con datos relativos solo a los participantes del programa y, a continuación, las tres subpropiedades se enviarían a una propiedad de agrupación para registrar los datos de fidelización.

Diagrama en el que se muestran dos propiedades de agrupación

 

Multinacional con regiones y subregiones

En este caso, la cuenta de esta multinacional tiene tres subpropiedades de agrupación regionales con dos subpropiedades fuente cada una. 

Diagrama que muestra una propiedad de agrupación global con tres propiedades de agrupación regionales

Vinculación: Google Ads, SA360 y DV360

En las propiedades de GA4 se han introducido algunas mejoras referentes a la vinculación con Google Ads. Sin embargo, los aspectos fundamentales de la vinculación siguen siendo los mismos. Puede vincular su cuenta de Google Ads con su propiedad de GA4 para compartir audiencias y estadísticas de sitios con Google Ads. De esta forma, podrÔ aprovechar las ventajas de tener en su propiedad de GA4 los datos que se registran en Google Ads. La vinculación con una cuenta de Google Ads se realiza desde la propiedad de GA. Puede vincular una propiedad fuente, una subpropiedad o una propiedad de agrupación.

Cambio importante introducido en GA4 respecto a UA: en UA debe seleccionar cada cuenta de Google Ads a la que va a exportar una audiencia, hasta un mƔximo de 10 cuentas. En las propiedades de GA4, una audiencia se comparte con todas las cuentas vinculadas. Con este cambio, compartir audiencias es mucho mƔs fƔcil, pero se deben compartir todas o ninguna. TƩngalo en cuenta a la hora de desarrollar sus audiencias de GA4.

Si vincula su propiedad de GA4 con su cuenta de Google Ads, podrÔ consultar las estadísticas de los sitios en Google Ads. Esta función exporta directamente, de GA a la interfaz de usuario de Google Ads, datos sobre el comportamiento de interacción de los usuarios. Aunque puede vincular su cuenta con cualquier tipo de propiedad, le recomendamos que la vincule solo con la propiedad fuente o solo con la subpropiedad, pero no con ambas. Así evitarÔ que se cuenten datos duplicados, como sucedería si vinculara su cuenta con una propiedad fuente y una subpropiedad a la vez.

Se pueden compartir audiencias con Google Ads desde cualquier propiedad de GA4 (es decir, propiedad común, subpropiedad o propiedad de agrupación). Sin embargo, tenga en cuenta que una audiencia de una subpropiedad o de una propiedad de agrupación tendrÔ datos distintos que los de la propiedad fuente, que es una propiedad común. Esta discordancia se debe a las operaciones de filtrado o al uso de varios conjuntos de datos. Es importante tener en cuenta este aspecto al usar la segmentación por audiencia en Google Ads.

Del mismo modo, las conversiones dependen del tipo de propiedad vinculada. No es recomendable importar el mismo tipo de conversiones desde una propiedad fuente, una subpropiedad y una propiedad de agrupación. Le recomendamos que vincule la propiedad fuente de GA con Google Ads y que exporte conversiones solo de la propiedad fuente. Sin embargo, pueden darse excepciones a esta recomendación. Por ejemplo, podría tener cuentas de Google Ads específicas de una región que necesite vincular a nivel de subpropiedad.

Los datos se importan de Google Ads a una propiedad de GA4 en el momento en que se hace la consulta. De este modo, los datos que se muestran en la interfaz siempre son los mƔs actualizados, y no se registran duplicados ni datos agregados en las subpropiedades ni en las propiedades fuente.

Search Ads 360

Al establecer una integración con SA360, los datos se transmitirÔn de la propiedad fuente a una subpropiedad o a una propiedad de agrupación. Esto significa que, si la vinculación se establece en la propiedad fuente, la subpropiedad o la propiedad de agrupación recibirÔn datos de SA360, pero ni la subpropiedad ni la propiedad de agrupación podrÔn establecer o controlar la vinculación en sí.

Cambio importante introducido en las propiedades de GA4 respecto a las propiedades de UA: en UA debe seleccionar cada cuenta a la que va a exportar una audiencia, hasta un mĆ”ximo de 10 cuentas. En las propiedades de GA4, una audiencia se comparte con todas las cuentas vinculadas. Con este cambio, compartir audiencias es mucho mĆ”s fĆ”cil, pero debe compartir todas o ninguna. TĆ©ngalo en cuenta a la hora de desarrollar sus audiencias de GA4.

Display & Video 360

Al establecer una integración con DV360, los datos se transmiten de la propiedad fuente a una subpropiedad o a una propiedad de agrupación. Esto significa que, si la vinculación se establece en la propiedad fuente, la subpropiedad o la propiedad de agrupación recibirÔn datos de DV360, pero ni la subpropiedad ni la propiedad de agrupación podrÔn establecer o controlar la vinculación en sí.

Cambio importante introducido en las propiedades de GA4 respecto a las propiedades de UA: en UA debe seleccionar cada cuenta a la que va a exportar una audiencia, hasta un mĆ”ximo de 10 cuentas. En las propiedades de GA4, una audiencia se comparte con todas las cuentas vinculadas. Con este cambio, compartir audiencias es mucho mĆ”s fĆ”cil, pero debe compartir todas o ninguna. TĆ©ngalo en cuenta a la hora de desarrollar sus audiencias de GA4.

¿Te ha resultado útil esta información?
¿Cómo podemos mejorar esta pÔgina?
false
BĆŗsqueda
Borrar bĆŗsqueda
Cerrar bĆŗsqueda
Aplicaciones de Google
MenĆŗ principal
2771510091661682069
true
Buscar en el Centro de ayuda
true
true
true
true
true
69256