[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