Capítulo 1. El nuevo Google Analytics 4

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Este capítulo presenta el nuevo Google Analytics 4 (GA4) y explora por qué se ha desarrollado. Veremos en qué aspectos Google consideraba que su predecesor, Universal Analytics, tenía carencias y cómo GA4 pretende reforzar esas áreas con la base de un nuevo modelo de datos.

También veremos cómo la integración de Google Cloud Platform (GCP) con GA4 mejora su funcionalidad y echaremos un primer vistazo a los casos de uso que ayudarán a ilustrar las nuevas capacidades de GA4 y a ponerte en marcha con tus propios proyectos de datos.

Presentación de GA4

Google Analytics 4 salió de la versión beta y se presentó como el nuevo Google Analytics a principios de 2021. Su nombre beta "App+Web" fue sustituido por Google Analytics 4.

Las diferencias clave entre GA4 y Universal Analytics destacadas en el post de anuncio de GA4 eran sus capacidades de aprendizaje automático, el esquema de datos unificado en web y móvil, y el diseño centrado en la privacidad.

Google llevaba muchos años planeando el lanzamiento de GA4 antes de su anuncio público. Tras su lanzamiento, Google Analytics se convirtió en el sistema de análisis web más popular, aunque en 2021 su diseño seguía reflejando los objetivos de diseño de los 15 años anteriores. Aunque la plataforma ha sido mejorada a lo largo de los años por el equipo dedicado a Google Analytics, había algunos retos modernos que eran más difíciles de resolver: los usuarios pedían vistas únicas de los clientes para la web y las aplicaciones móviles en lugar de tener que enviar datos a dos propiedades separadas, Google Cloud era líder en tecnologías de aprendizaje automático, pero el aprendizaje automático no era fácil de integrar con el modelo de datos de GA, y la privacidad de los usuarios era una preocupación creciente que requería un control más estricto sobre dónde fluían los datos analíticos.

Cuando se lanzó por primera vez en 2005, Google Analytics trastornó el sector de la analítica al ofrecer una versión gratuita con todas las funciones de lo que antes sólo estaba disponible en productos empresariales de pago. Reconociendo que cuanto más supieran los webmasters sobre su tráfico, más probable sería que invirtieran en AdWords (ahora Google Ads), Google Analytics fue una inversión beneficiosa para todos que dio a todos acceso a la voz de sus usuarios mientras navegaban por su sitio web.

En 2020, el panorama analítico era muy diferente. Los productos analíticos de la competencia se lanzaron con modelos de datos más sencillos que podían funcionar en todas las fuentes de datos y eran más adecuados para el aprendizaje automático y la privacidad (una característica esencial para el usuario). Se podía utilizar la nube para hacer un sistema analítico más abierto, dando más control a los profesionales de la analítica. Las soluciones analíticas de la competencia podrían incluso ejecutarse en la propia infraestructura en la nube de Google, lo que cambiaría la economía de construir o comprar. Las soluciones analíticas ideales tendrían valores predeterminados sensatos para quienes buscan una puesta en marcha rápida, pero serían más personalizables y escalables para satisfacer las necesidades de los clientes más aventureros.

La unificación de la analítica móvil y web

Aunque su nombre anterior de "App+Web" fue sustituido por GA4 en el lanzamiento, el nombre descartado era más representativo de por qué GA4 era diferente.

Hasta su desaparición a finales de 2019, Google Analytics para aplicaciones móviles (Android/iOS) tenía su propio sistema de análisis independiente, distinto del análisis web. Estos kits de desarrollo de software (SDK) utilizaban un modelo de datos diferente que era más adecuado para la analítica de aplicaciones, donde conceptos como páginas vistas, sesiones y usuarios significaban cosas ligeramente diferentes, lo que significaba que no podían compararse fácilmente con las cifras de la web. Los usuarios que visitaban tanto la aplicación como la web no solían estar vinculados.

El modelo de datos de GA4 sigue una estructura personalizable, sólo de eventos, que estaba siendo adoptada por las aplicaciones móviles. Universal Analytics imponía limitaciones sobre cuándo podían combinarse los datos, lo que se conoce como ámbito de datos, lo que significaba que los profesionales del marketing tenían que pensar en cómo encajaban sus datos en ámbitos como usuario, sesión o eventos. Éstos estaban predeterminados por Google, por lo que te veías obligado a adoptar su modelo de datos. Con el enfoque de sólo eventos de GA4, tienes más flexibilidad para determinar cómo quieres que sean tus datos.

Cuando los antiguos SDK de Google Analytics para móviles expiraron en 2019, Google animó a los usuarios a pasarse a los SDK de Firebase. Firebase se había desarrollado como una experiencia completa de desarrollador móvil para iOS y Android con un SDK móvil integrado para crear aplicaciones móviles desde cero, que ahora incluía analítica web. El nuevo GA4 representaba un flujo de datos adicional en la parte superior: el nuevo flujo web. Tener los flujos de iOS, Android y web utilizando el mismo sistema significa que ahora tenemos una forma verdaderamente conectada de medir la analítica digital a través de todas esas fuentes.

Firebase y BigQuery: primeros pasos en la nube

Para muchos profesionales del marketing, GA4 es su primera introducción a los nuevos productos en la nube que forman parte integral de su funcionamiento: Firebase y BigQuery.

Firebase y BigQuery son ambos productos dentro de GCP, un amplio servicio que Google ofrece para todo tipo de servicios en la nube. Este libro se centra en los productos que forman parte de su oferta de análisis de datos en la nube, pero ten en cuenta que éstos son sólo un subconjunto de toda la plataforma en la nube.

Firebase es un amplio marco de desarrollo móvil que ahora incluye Google Analytics. Los desarrolladores móviles también lo utilizan para dar potencia sin servidor a las aplicaciones móviles con funciones útiles como la configuración remota para cambiar el código de las aplicaciones desplegadas sin volver a publicarlas en la tienda de aplicaciones, API de aprendizaje automático como el modelado predictivo, la autenticación, las alertas móviles y las integraciones de anuncios de Google. Firebase es un subconjunto de servicios de GCP que en algunos casos son un cambio de marca del producto subyacente de GCP; por ejemplo, Firebase Cloud Functions es lo mismo que GCP Cloud Functions.

BigQuery puede considerarse una de las joyas de GCP; está reconocido como uno de sus productos más atractivos en comparación con los equivalentes que se ejecutan en otros proveedores de nube. BigQuery es una base de datos SQL hecha a medida para cargas de trabajo analíticas, y fue una de las primeras bases de datos sin servidor disponibles. Incluye innovaciones como un modelo de precios que almacena los datos a bajo coste, mientras que cobra bajo demanda por las consultas, y un motor de consultas rapidísimo que se ejecuta en Dremel y ofrece en algunos casos velocidades 100 veces superiores a MySQL. Es posible que los usuarios de GA360 ya estén familiarizados con él, ya que una de sus funciones era exportar datos sin muestrear a BigQuery, pero sólo si comprabas una licencia de GA360 (¡ésta fue mi introducción a la nube!). Las exportaciones a BigQuery de GA4 estarán disponibles para todos, lo cual es emocionante porque BigQuery es en sí mismo una puerta de acceso al resto de GCP. BigQuery ocupa un lugar destacado en este libro.

Implementación GA4

Este libro no es una guía exhaustiva sobre la implantación de GA4; un lugar mejor para ello serían los recursos descritos en el Capítulo 10. Sin embargo, el libro cubre configuraciones comunes que ofrecerán una visión completa, desde la recogida de datos hasta el valor empresarial.

Existen esencialmente tres formas de configurar la captura de datos de sitios web: gtag.js, analytics.js, o Google Tag Manager (GTM). En casi todos los casos, recomendaría implementarlos a través de GTM, sobre el que puedes leer más en el Capítulo 3. Las razones para ello son la flexibilidad y la capacidad de desacoplar el trabajo del dataLayer de la configuración de las analíticas, lo que minimizará la cantidad de trabajo de desarrollo necesario dentro del HTML del sitio web. Los recursos del desarrollador serán más eficaces implementando un dataLayer ordenado para tu GTM, ya que éste cubrirá todas tus necesidades de seguimiento, no sólo las etiquetas GA4 o Google. Cualquier cambio adicional en tu configuración de seguimiento puede realizarse en la interfaz web de GTM, sin necesidad de dedicar un valioso tiempo de desarrollo a cada pequeña modificación.

Con la introducción de GTM Server Side (SS), las configuraciones posibles también pueden incluir integraciones directas con Google Cloud y sistemas backend junto con modificaciones de las solicitudes y respuestas de la llamada HTTP, lo que te proporciona la máxima flexibilidad.

Analítica universal frente a GA4

Se dice que GA4 es una evolución de su predecesor, Universal Analytics (apodado GA3 desde el lanzamiento de GA4), pero ¿en qué se diferencia realmente?

Una de las primeras preguntas que se hace la gente cuando oye hablar de GA4 es: "¿En qué es tan diferente como para que quiera cambiarme? ¿Por qué debería pasar por la molestia de reequipar, reciclar y volver a aprender un sistema que ha funcionado bien durante los últimos 15 años?". Esta es una pregunta clave, y esta sección examina por qué.

Un tema de ayuda de Google dedicado a también trata esta cuestión.

Un nuevo modelo de datos

El primer gran cambio se produce en el propio modelo de datos, tratado más adelante en "El modelo de datos GA4".

Universal Analytics estaba muy centrado en las métricas del sitio web, donde conceptos como usuarios, sesiones y páginas vistas eran más fáciles de definir; sin embargo, estos conceptos eran más difíciles de definir para otras fuentes de datos, como aplicaciones móviles y visitas al servidor. A menudo significaba que había que incorporar soluciones provisionales o ignorar algunas métricas en los informes cuando los datos procedían de determinadas fuentes. También significaba que algunas métricas no funcionaban bien juntas o eran imposibles de consultar.

GA4 pasa de un esquema de datos impuesto a algo mucho más libre: ahora todo es un evento. Esta flexibilidad te permite definir tus propias métricas con mayor facilidad, pero para los usuarios que no quieran llegar a ese nivel de detalle, también proporcionan tipos de eventos automáticos por defecto para ofrecerte algunas de las métricas conocidas.

Esto también significa que ahora es posible recopilar automáticamente algunos datos que antes debían configurarse por separado, como los clics en enlaces, por lo que las implementaciones de GA4 deberían requerir menos experiencia para aplicarse correctamente, ayudando a reducir la barrera de entrada para los nuevos usuarios de analítica digital. Los conocimientos especializados, como la diferencia entre una métrica de sesión y una métrica de aciertos, serán menos críticos.

Un enfoque más flexible de las métricas

Los eventos GA4 pueden modificarse después de haber sido enviados. Esto te permite corregir errores de seguimiento o estandarizar eventos ("venta" frente a "transacción") sin necesidad de modificar los scripts de seguimiento, lo que facilita mucho la acción.

Al crear definiciones personalizadas para tus propios eventos, no hay ningún esquema predefinido que debas recordar. Crea tu evento con parámetros opcionales, y regístralo dentro de la interfaz GA4 para empezar a ver ese evento aparecer en tus informes.

Exportaciones BigQuery

La exportación de BigQuery, que antes era una función de GA360, ahora estará disponible aunque no pagues la versión empresarial de GA4. Firebase Analytics para móviles tenía esta función en su lanzamiento, y como GA4 es sólo un complemento de aquélla, la analítica web también la tiene.

Esto cambia las reglas del juego, porque normalmente la parte más difícil de un proyecto de datos es acceder a los datos brutos que hay bajo tus aplicaciones de forma que puedas trabajar fácilmente con ellos. Con las exportaciones BigQuery de GA4, sólo tienes que rellenar unos pocos formularios web para conseguir que esos datos fluyan casi en tiempo real, listos para el análisis mediante BigQuery SQL.

Dado que BigQuery está tan integrado con el resto de GCP, esto también significa que tiene estrechas integraciones con el resto de la pila de datos de GCP, como Pub/Sub, Dataflow y Data Studio. Estos servicios te permiten canalizar datos directamente desde BigQuery, y como sus API son abiertas, también es una fuente o sumidero popular para muchos servicios de terceros.

Todo esto significa que el viejo problema de los silos de datos, donde los datos que necesitas están encerrados tras bases de datos con políticas y políticas empresariales diferentes, tiene ahora una vía de solución al enviarlos todos a un único destino: BigQuery. Así es como puedes empezar a vincular las ventas y el marketing o extraer datos útiles de segundas partes, como las previsiones meteorológicas, con mayor facilidad. Según mi experiencia, trasladar todos los datos útiles a un único lugar ha tenido los efectos más transformadores en la madurez digital de un cliente, ya que se ha eliminado uno de los obstáculos más comunes: "¿Cómo obtenemos los datos?

No hay muestreo: todo es en tiempo real

Una motivación para las exportaciones BigQuery de GA360 fue que era una de las formas de obtener datos sin muestrear, y eso también es aplicable ahora a GA4. Aunque se han mejorado los límites de muestreo dentro de la WebUI, los datos subyacentes siempre están sin muestrear y disponibles en tiempo real. Si alguna vez necesitas una exportación sin muestreo, está disponible a través de BigQuery o utilizando la API de datos gratuita. Esto elimina la barrera de pagar por GA360 para disponer de los datos para algunos casos de uso que necesitan fuentes de datos analíticos de alta precisión y en tiempo real.

Privacidad y datos analíticos digitales

Hoy en día, los usuarios son mucho más conscientes del valor de sus datos, y la privacidad se ha convertido en un tema candente en el sector. Se reconoce que los usuarios necesitan una opción totalmente informada para consentir dónde se utilizan sus datos, y es responsabilidad del sitio web ganarse la confianza y valorar correctamente esos datos. Para contribuir a ello, existe el Modo Consentimiento de Google, que elimina las cookies y sus identificadores personales almacenados, de modo que no estén disponibles para Google Analytics hasta que el usuario dé su consentimiento. Sin embargo, los datos no personales pueden seguir siendo útiles, y GA4 ofrece una forma de modelar cómo serían tus sesiones de datos y conversiones si el 100% de tus usuarios consintieran en dar sus datos. Dado que lo más probable es que tus nuevos clientes sean los que aún no confían en tu sitio web ni dan su consentimiento, ésta puede ser una información valiosa para ayudarte a mejorar tu rendimiento.

¿Cuándo es GA4 la respuesta?

Dados los cambios en GA4, a continuación se ofrece un resumen de las oportunidades que ofrece GA4 sobre Universal Analytics para ayudar con las preguntas más frecuentes:

  • ¿Cómo podemos integrar nuestros datos de analítica digital con GCP para que nuestros datos funcionen más allá de los servicios GA4 (¡de lo que trata principalmente este libro!)?

  • ¿Cómo unificamos el seguimiento de los usuarios en todas nuestras propiedades digitales, incluidas nuestras aplicaciones móviles y el sitio web?

  • ¿Cómo podemos hacer más fácilmente implementaciones analíticas a medida por encima de las predeterminadas?

  • ¿Cómo podemos acceder a nuestros datos de analítica digital para alimentar nuestro modelo de aprendizaje automático?

  • ¿Cómo podemos respetar las opciones de privacidad pero seguir disponiendo de algunos datos sobre el rendimiento de nuestro sitio web?

En esta sección hemos hablado de por qué deberías utilizar GA4 y de sus principales diferencias con respecto a Universal Analytics. La fuente fundamental de estos cambios es la forma en que GA4 registra sus datos en su nuevo modelo de datos, en el que profundizaremos en la siguiente sección.

El modelo de datos GA4

El modelo de datos de GA4 es lo que lo diferencia de Universal Analytics. Este nuevo modelo de datos permite a GA4 ofrecer sus funciones más avanzadas. Esta sección profundiza en el modelo de datos y su funcionamiento.

Los elementos clave de este modelo de datos son

Simplicidad

Todo es un acontecimiento del mismo tipo. No se imponen relaciones arbitrarias a los datos.

Velocidad

Dado el modelo de datos más sencillo, el procesamiento reducido de los eventos permite que todo se haga en tiempo real.

Flexibilidad

Los eventos pueden tener cualquier nombre hasta el límite de tu cuota (500 por defecto). Se pueden adjuntar parámetros a cada evento para ajustar sus metadatos.

Ahora nos adentraremos en la maleza y exploraremos la sintaxis de cómo se crean los aciertos de los eventos GA4.

Eventos

Los eventos son la unidad atómica de captura de datos en GA4. Cada acción que realiza un usuario en tu sitio web según tu configuración envía un evento a los servidores de Google.

He aquí sólo un acontecimiento:

{"events": [{"name": "book_start"}]}

El simple recuento del número de eventos "book_start" proporciona información útil, como cuántas personas han empezado el libro, el número medio de lecturas del libro al día, etc.

Para garantizar que una colección de eventos se asocia a un usuario, esos eventos necesitan un ID común. En GA4, esto significa enviar también un client_id, que es un ID seudónimo que suele encontrarse dentro de la cookie de GA4. Suele construirse como un número aleatorio con una marca de tiempo adjunta cuando se creó por primera vez:

{"client_id":"1234567.1632724800","events": [{"name": "book_start"}]}

La línea anterior son los datos mínimos requeridos para los eventos enviados a tu cuenta GA4.

Nota

Las marcas de tiempo suelen indicarse en tiempo de época Unix, o el número de segundos transcurridos desde la medianoche del 1 de enero de 1970. Por ejemplo, las cookies con 1632724800 se traducirían como lunes 27 de septiembre de 2021, 08:39:56 CEST -el momento en que estoy escribiendo esta frase.

Estos ejemplos son del Protocolo de Medición v2, que es una forma de enviar eventos. La forma mucho más común es utilizar los scripts de seguimiento GA4 en tu sitio web o aplicación iOS o Android para construir y crear estos eventos. Pero creo que es útil saber qué hace ese script.

El mismo evento enviado desde un rastreador web utilizando gtag() tendría el siguiente aspecto:

gtag('event', 'book_start')

La biblioteca JavaScript de GA4 se encarga de la cookie para suministrar el client_id, por lo que sólo tienes que proporcionar el nombre de tu evento personalizado.

Al utilizar los scripts de seguimiento de GA4, la biblioteca intenta ayudarte a evitar la configuración de los tipos de eventos más comunes, proporcionándote eventos recopilados automáticamente. Éstos cubren eventos útiles como páginas vistas, vídeos vistos, clics, descargas de archivos y desplazamientos. Esto ya es una ventaja sobre Universal Analytics: lo que antes tenías que configurar ahora viene de serie con GA4. Menos configuración significa implementaciones más rápidas y menos posibilidades de errores. Para utilizar estos eventos automáticos, puedes elegir cuáles activar a través de los ajustes de medición mejorados.

También hay eventos recomendados, que son eventos que tú implementas pero que siguen una estructura de nombres recomendada por Google. Éstos están más adaptados a tu sitio web e incluyen recomendaciones para verticales como viajes, comercio electrónico o sitios web de empleo. También merece la pena atenerse a ellas porque los futuros informes pueden basarse en estas convenciones de nomenclatura para sacar a la luz nuevas funciones. Los eventos genéricos recomendados incluyen los inicios de sesión de los usuarios, las compras y compartir contenido.

Puesto que estos eventos automáticos y recomendados están estandarizados, si recopilas tus propios eventos personalizados, asegúrate de no duplicar sus nombres para evitar choques y confusiones. Esperemos que puedas ver la flexibilidad del sistema en su intento de proporcionar estandarización con valores predeterminados sensatos para evitar tener que reinventar la rueda en cada implementación.

Parámetros personalizados

Sin embargo, el recuento de sucesos por sí solo no es suficiente para un sistema analítico útil, . Para cada suceso, puede no haber ninguno o muchos parámetros que aporten información adicional en torno a él.

Por ejemplo, un evento de inicio de sesión te dará el número de inicios de sesión en tu sitio web, pero probablemente quieras desglosarlo por cómo se conecta un usuario: con correo electrónico o con un inicio de sesión social. En ese caso, tu evento recomendado login también sugiere un parámetro method para que lo especifiques:

gtag('event', 'login', {
  'method': 'Google'
})

Si se hiciera con el protocolo de medición más fundamental, tendría elsiguiente aspecto:

{
 "client_id":"a-client-id",
 "events": [
   {"name": "login",
    "params": {
      "method": "Google"
      }
    }]
 }

Observa que hemos añadido una matriz de params con la información adicional.

Artículos de comercio electrónico

Una clase especial de parámetros personalizados son los artículos, que son una matriz anidada más dentro de los parámetros personalizados que contiene toda la información del artículo. El comercio electrónico suele representar los flujos de datos más complicados, porque a las ventas se asocian múltiples artículos, actividades y datos.

Sin embargo, los principios son en gran medida los mismos: en este caso, el parámetro personalizado esuna matriz que contiene algunos campos recomendados como item_id, price y item_brand:

{
  "items": [
        {
          "item_id": "SKU_12345",
          "item_name": "jeggings",
          "coupon": "SUMMER_FUN",
          "discount": 2.22,
          "affiliation": "Google Store",
          "item_brand": "Gucci",
          "item_category": "pants",
          "item_variant": "Black",
          "price": 9.99,
          "currency": "USD"
        }]
}

Combina esto con los eventos de comercio electrónico recomendados, como purchase y algunos otros parámetros, y la carga útil completa del evento se convierte en lo siguiente:

{
 "client_id": "a-client-id",
    "events": [{
      "name": "purchase",
      "params": {
        "affiliation": "Google Store",
        "coupon": "SUMMER_FUN",
        "currency": "USD",
        "items": [{
          "item_id": "SKU_12345",
          "item_name": "jeggings",
          "coupon": "SUMMER_FUN",
          "discount": 2.22,
          "affiliation": "Google Store",
          "item_brand": "Gucci",
          "item_category": "pants",
          "item_variant": "Black",
          "price": 9.99,
          "currency": "USD",
          "quantity": 1
        }],
        "transaction_id": "T_12345",
        "shipping": 3.33,
        "value": 12.21,
        "tax": 1.11
      }
    }]
}

Aunque el código anterior representa algunos de los eventos más complejos enviados a GA4, espero que puedas apreciar la simplicidad del modelo subyacente. Utilizando sólo eventos y parámetros, GA4 puede configurarse para capturar interacciones complejas en tu sitio web.

Propiedades del usuario

Además de los datos a nivel de evento, también es posible establecer datos a nivel de usuario. Se trata de datos asociados a los client_id o user_id que tengas registrados. Podrían utilizarse para establecer el segmento de clientes o las preferencias de idioma.

Advertencia

Ten en cuenta aquí respetar las opciones de privacidad del usuario. Si estás añadiendo información a un usuario concreto, leyes como el Reglamento General de Protección de Datos (RGPD) de la UE exigen que obtengas el consentimiento del usuario para recopilar sus datos con el fin que has indicado.

El envío de propiedades de usuario es muy parecido al envío de eventos, pero en su lugar utilizas el campo user_properties, así como los eventos que quieras enviar:

{
 "client_id":"a-client-id",
 "user_properties": {
   "user_type":{
     "value": "bookworm"
   }
 },
 "events": [
   {"name": "book_start",
    "params": {
      "title": "Learning Google Analytics"
    }}
   ]
}

Utilizando gtag() quedaría así:

gtag('set', 'user_properties', {
  'user_type': 'bookworm'
});
gtag('event', 'book_start', {
  'title': 'Learning Google Analytics'
});

En esta sección, hemos visto cómo enviar eventos GA4 de varias formas, como el protocolo de medición y gtag, y la sintaxis de envío de eventos con parámetros y propiedades de usuario. Ahora pasamos a cómo procesar esos eventos que salen de GA4 a través de sus integraciones con GCP.

Plataforma en la nube de Google

Ahora GCP puede integrarse firmemente en tu sistema GA4 a través de sus sistemas preexistentes de análisis de datos. Ofrece servicios en tiempo real, de aprendizaje automático y a escala de un billón, por los que pagas sólo cuando los utilizas, al tiempo que te permite desprenderte de las tareas aburridas de mantenimiento, seguridad y actualizaciones. Deja que tu empresa se centre en lo que es experta, y que la nube se ocupe de las tareas no esenciales. Mediante la estructura de pago por uso de la nube, los equipos pequeños pueden crear servicios que antes habrían necesitado mucha más mano de obra y recursos informáticos.

En esta sección, examinamos los servicios de GCP que probablemente utilizarás al integrarte con GA4, las habilidades y funciones que necesitará tu equipo para aprovechar estas herramientas, cómo empezar, cómo gestionar los costes y cómo seleccionar el servicio en la nube adecuado para ti.

Servicios BPC pertinentes

Este libro se centra más en los servicios de aplicaciones de datos de GCP, pero sigue siendo una amplia gama de servicios que se actualizan constantemente. Para una visión completa más allá del alcance de este libro, recomiendo Data Science on the Google Cloud Platform de Valliappa Lakshmanan (O'Reilly).

Los siguientes servicios clave en la nube se utilizan en los casos de uso que aparecen más adelante en el libro y han sido esenciales en mi trabajo general. Hay muchos servicios en la nube diferentes, y elegir el adecuado puede ser un poco desconcertante cuando estás empezando. Te sugiero que consideres los servicios aquí destacados como útiles para empezar.

En el libro nos familiarizaremos con los siguientes servicios, por orden aproximado de utilidad:

BigQuery

Como ya se ha mencionado, BigQuery ocupará un lugar destacado en como destino y origen de cargas de trabajo analíticas y de datos. Incluso tiene capacidades de modelado con BigQuery ML.

Funciones en la nube

Pegamento entre servicios, las Funciones Cloud te permiten ejecutar pequeños fragmentos de código, como Python, en un entorno sin servidor.

Pub/Sub

Pub/Sub es un sistema de colas de mensajes que garantiza que cada mensaje se entregue al menos una vez a una escala que puede manejar todo el Internet que se envía a través de su cola.

Construir en la nube

Cloud Build es una herramienta de integración continua/desarrollo continuo (CI/CD) que te permite activar contenedores Docker por lotes en respuesta a los envíos de GitHub. Es un caballo de batalla oculto detrás de varias de mis soluciones.

Cloud Composer/Airflow

Cloud Composer/Airflow es un orquestador que te permite crear de forma fiable complicados flujos de datos interdependientes, incluida la programación.

Flujo de datos

Dataflow es una solución por lotes y de streaming para datos en tiempo real que está bien integrada con muchos servicios de GCP.

Carrera en las nubes

Cloud Run es similar a Cloud Functions, pero te permite ejecutar contenedores Docker que contengan el código que quieras.

Normalmente hay varias formas de crear lo que necesitas, y las diferencias pueden ser sutiles, pero te recomiendo que seas pragmático y consigas algo que funcione primero, para luego optimizar qué servicio exacto puede ser mejor para ejecutarlo más adelante. Por ejemplo, puedes tener una importación de datos diaria ejecutándose en una consulta programada de BigQuery, pero descubrir a medida que tus necesidades se hacen más complejas que Cloud Composer es una herramienta mejor para coordinar la importación.

Sin embargo, no todas estas herramientas son "apuntar y hacer clic". Es necesario codificarlas para que ofrezcan lo que necesitas, por lo que en la siguiente sección repasaremos qué habilidades necesitas para ofrecer sus capacidades.

Habilidades de codificación

Uno de los aspectos más desalentadores de la aplicación de estas integraciones puede ser que requiere habilidades que puedes pensar que sólo tienen los programadores informáticos. Quizá te consideres "no técnico".

Yo solía pensar lo mismo. Recuerdo que al principio de mi carrera decía: "No sé JavaScript" y esperaba seis semanas a que se liberara el tiempo para que un desarrollador pusiera en marcha un trozo de código de cinco líneas en un sitio web. Cuando tuve tiempo y ganas, empecé a probar por mi cuenta, cometiendo muchos errores por el camino. También aprendí que los profesionales también cometían muchos errores, y la única diferencia era que ellos tenían la motivación para seguir adelante. También me di cuenta de que muchas de las cosas que hacía en Excel eran en realidad más complicadas y difíciles de trabajar que si utilizara una herramienta más adecuada para el trabajo. Resolver la tarea en Excel requería más capacidad cerebral que hacerlo en R, por ejemplo.

Así que, si tienes ganas, te animo a que sigas adelante. Si te resulta difícil, no es necesariamente porque no tengas talento: estas cosas son ajenas a todo el mundo al principio. La codificación puede parecer increíblemente quisquillosa en algunos casos, y las cosas pueden salir mal si se te escapa un solo ";". Sin embargo, una vez que aprendes un área, la siguiente es un poco más fácil. Yo empecé siendo un usuario experto de Excel, luego aprendí Python y JavaScript, después me enamoré de R, luego tuve que aprender a apreciar SQL y bash, y ahora chapoteo con Go. La naturaleza de la programación es que, a medida que aprendes y mejoras, el código de hace seis meses te parecerá horrible. Esto es natural; lo importante es poder mirar atrás y ver el progreso. Una vez que consigues que algo funcione, eso es experiencia, y crece lentamente hasta que 10 años después te sientas a escribir un libro sobre ello.

Para mí, el código abierto era también una forma de perfeccionar mis habilidades, ya que poner código al descubierto y recibir comentarios era un multiplicador además de cualquier experiencia que tuviera ejecutando ese código. Por eso estoy tan agradecido por cualquier comentario que reciba hoy, en GitHub o de otro modo. El código de este libro también estará disponible en un repositorio de GitHub que acompañará al libro, que me esforzaré por mantener actualizado y libre de errores.

Nota

Por la misma lógica, si lees algo de mi código y tienes algún comentario sobre cómo se puede hacer mejor, ¡ponte en contacto conmigo! Siempre estoy aprendiendo.

Los casos prácticos de este libro incluyen ejemplos de código que abarcan los siguientes lenguajes:

JavaScript

Es esencial para todo el seguimiento basado en páginas web que implique HTML y se utiliza sobre todo para la captura de datos mediante etiquetas. También se utiliza mucho en GTM para crear plantillas personalizadas.

Python

Python, un lenguaje muy popular compatible con en una amplia gama de plataformas, es útil conocerlo, ya que puede considerarse el segundo mejor lenguaje para todo. También tiene una sólida representación de aprendizaje automático, aunque probablemente no la necesites a menos que trabajes en implementaciones avanzadas.

R

Aunque podrías utilizar Python, la comunidad de ciencia de datos de R lo convierte, en mi opinión, en el mejor lenguaje para la ciencia de datos. Sus bibliotecas y su comunidad de código abierto lo cubren todo, desde la ingesta de datos hasta su activación mediante cuadros de mando e informes interactivos. Atribuyo la mayor parte de mi forma de pensar sobre cómo enfocar los flujos de trabajo de datos a la mentalidad que obtuve de R, por lo que influye en los proyectos incluso cuando no se utiliza directamente.

bash

Cuando interactúes con servidores en la nube, lo más probable es que utilices sistemas basados en Linux, como Ubuntu o Debian, que se basan en bash para funcionar en lugar de una interfaz gráfica como Windows. También es útil saber algo de programación bash de línea de comandos cuando se trabaja con archivos muy grandes que no se importan fácilmente a otros lenguajes. gcloud y otras CLI también presuponen cierto conocimiento de shell scripting, siendo bash el más popular.

SQL

En la mayoría de los casos, los datos en bruto con los que trabajas en estarán en una base de datos, y SQL será el mejor método para extraerlos. SQL también introduce una forma de pensar sobre los objetos de datos que resulta útil.

Aunque es posible copiar y pegar para salir victorioso, te recomiendo que repases línea por línea y comprendas al menos lo que hace cada sección del código.

Suponiendo que ahora dispones de algo de código, ya sea gracias a tus propias habilidades o a las de tu equipo, pasamos ahora a cómo empezar en GCP e implementar tu primer código en la nube.

Incorporación a GCP

GCP es un componente principal del negocio de Google, y tiene flujos completamente separados de Google Analytics que tendrás que aprender a navegar.

Puedes empezar gratis, pero lo primero que debes saber es que para cualquier cosa seria, vas a tener que añadir una tarjeta de pago para tu uso de la nube. Sin embargo, puedes obtener varios meses de uso cubiertos por los bonos de incorporación disponibles.

La página de inicio de Google te guiará en tu primer inicio de sesión.

Consejo

Si ya tienes un Proyecto Google Cloud,, puede que aún así merezca la pena crear uno nuevo para los ejemplos de este libro, para asegurarte de que están activados con las últimas versiones de las API. Por ejemplo, lo más probable es que tengas que activar la API de informes de Google Analytics, la API de administración de Google Analytics y la API de Cloud Build, y comprobar que la API de BigQuery está activada por defecto.

Ascendiendo en la pirámide sin servidor

Liberar realmente el poder de la nube implica una evolución en el pensamiento sobre cómo abordar los problemas informáticos utilizando sus puntos fuertes. El primer paso de las empresas en la nube suele implicar un modelo de "vida y cambio" en el que simplemente replican en la nube lo que tenían funcionando localmente, como una base de datos MySQL local sustituida por un servidor en la nube que ejecuta MySQL. Otra estrategia es "mover y mejorar", que implica, porejemplo, colocar tu base de datos MySQL dentro de Google Cloud SQL, una instancia gestionada de MySQL.

Sin embargo, un modelo de "levantar y cambiar" sólo reportará beneficios menores en comparación con todo el potencial de la nube. Para que una empresa logre una verdadera transformación digital, necesita adoptar los metaservicios superiores construidos sobre los fundamentos de la computación y el almacenamiento, con la previsión de que hacerlo te vinculará necesariamente un poco más al servicio de ese proveedor de la nube.

El argumento de las empresas de la nube para utilizar estos servicios es que te desprendes de los recursos informáticos para mantener, parchear y desarrollar los servicios creados y, en su lugar, inviertes en utilizar las aplicaciones creadas sobre ellos de una forma más bajo demanda. Es sin duda este modelo el que me ha permitido escribir este libro, ya que sin la computación en nube, crear tus propios servicios sería mucho más complicado y limitaría tu capacidad de experimentar con soluciones. Cuando los recursos informáticos se externalizan eficazmente, se necesitan equipos mucho más reducidos para lograr resultados.

Un ejemplo de ello es BigQuery. Crear tu propio servicio BigQuery requeriría que invirtieras en tener preparadas enormes granjas de servidores, que cuestan dinero cuando están inactivas sólo para que estén disponibles cuando necesites los recursos para una "gran consulta". Utilizando el servicio BigQuery para la misma consulta, esos recursos se compran en línea cuando son necesarios, y pagas efectivamente sólo por los segundos que están funcionando.

Para ilustrar esto, me parece útil el diagrama de la pirámide sin servidor de la Figura 1-1. Esboza algunos de los servicios y las compensaciones que obtienes cuando seleccionas un servicio para ejecutar tu caso de uso.

Google Cloud Platform Pyramid Hierarchy on which service you should choose for your applications
Figura 1-1. Jerarquía piramidal del PCG

En el nivel inferior, tienes las máquinas virtuales y el almacenamiento, que son básicamente versiones en la nube de los ordenadores que se ejecutan en tu escritorio. Si quieres un control total de la configuración, puedes activarlas con algunas ventajas de la nube, como copias de seguridad,seguridad y parches. Esta capa se denomina a veces infraestructura como servicio (IaaS).

En el siguiente nivel, tienes servicios que ejecutan máquinas virtuales y almacenamiento por ti, pero lo abstraen para que sólo tengas que preocuparte de las configuraciones que necesitas. App Engine es un ejemplo de ello, y esta capa a veces se denomina plataforma como servicio (PaaS).

En el nivel superior, tienes otro nivel de abstracción que se ejecuta sobre el PaaS equivalente. Estos servicios suelen estar más orientados a las funciones, por lo que se dispone de servicios como el almacenamiento de datos analíticos (BigQuery). Esto se conoce a veces como base de datos como servicio (DBaaS).

E incluso por encima de eso, puedes tener servicios que eliminen parte de la configuración para ofrecer aún más comodidad. A menudo sólo necesitas proporcionar el código que necesitas ejecutar o los datos que quieres transformar. Las Funciones en la Nube son un ejemplo: no necesitas saber cómo ejecuta la función su código, sino sólo especificar cómo quieres que se ejecute. Esto se denomina funciones como servicio (FaaS).

Con esto en mente, puedes juzgar dónde debe situarse tu aplicación. Los servicios de la parte superior de la pirámide suelen tener un mayor coste por ejecución, pero si estás por debajo de un determinado volumen o coste de implementación, siguen representando un enorme ahorro de costes. A medida que necesites poseer o escalar más la infraestructura, puedes considerar moverte hacia abajo en la pirámide para tener más control.

Los casos de uso de este libro pretenden estar lo más arriba posible en la pirámide. Estos servicios suelen ser los últimos desarrollos y los más rápidos para empezar, y te darán la escala para servirte hasta tus primeros mil millones de usuarios.

Y eso está realmente al alcance de la mano: al seleccionar tu servicio, debe tener en cuenta cuánto se va a utilizar, lo que puede incluir hasta la escala global de Google. Quizá no lo necesites ahora mismo, pero merece la pena tenerlo en cuenta por si necesitas rediseñar tu aplicación en caso de que tenga un éxito inesperado.

Aquí es donde resulta útil estar muy arriba en la pirámide (como se detalla en la Figura 1-1), ya que esos servicios suelen tener aprovisionamiento autoescalable. Hay que limitarlo para evitar errores costosos, pero esencialmente, si tienes el dinero, debes esperar un rendimiento similar para mil usuarios que para mil millones. Más abajo en la jerarquía, sigues teniendo opciones, pero tendrías que implicarte más en las configuraciones de cuándo y dónde deberías aplicar esa escala.

Concluyendo nuestra introducción a GCP

Este ha sido un breve recorrido relámpago de por qué la nube es tan poderosa y cómo puede aplicarse su poder a tu implementación de GA4. Hemos hablado de cómo la nube pone en tu mano recursos que hace sólo unos años habrían requerido un gran equipo de TI para habilitarlos, y también hemos hablado de los conceptos de modelos sin servidor frente a modelos lift-and-shift para saber cómo puedes enfocar esto. Esto implicará una expansión de tus funciones digitales para incluir los lenguajes de codificación que ayudan a habilitar tales servicios, con la promesa de que invertir en esas habilidades te convertirá en un vendedor digital más eficaz en general. La mayor parte de este libro tratará sobre cómo poner esto en práctica, con algunos ejemplos de casos de uso sobre cosas que puedes hacer ahora mismo.

Introducción a nuestros casos de uso

Este libro presenta todos los conceptos y tecnologías relevantes para las integraciones GA4, pero la teoría y la planificación sólo pueden llegar hasta cierto punto. La forma real en que aprendí las habilidades que se tratan en este libro fue implementando aplicaciones. Cometí errores por el camino, pero esos errores fueron a menudo las experiencias de aprendizaje más valiosas, porque una vez que depuras por qué algo salió mal, adquieres una mayor comprensión de cómo hacerlo bien.

Para ayudarte a poner en marcha tu propio viaje, una vez introducidos todos los bloques de construcción necesarios para tus propias aplicaciones en los capítulos siguientes, nuestros casos de uso de los capítulos 7, 8 y 9 están dedicados a casos de uso técnicos que detallan todo el ciclo de vida de una aplicación de datos GA4, incluyendo ejemplos de código: creación de los casos de negocio, requisitos técnicos y decisiones sobre qué tecnologías utilizar. Si sigues todo en secuencia, al final deberías tener una integración que funcione.

Advertencia

En la práctica, puedes saltarte accidentalmente algunos pasos y tener que volver atrás y leer detenidamente lo que te has saltado. Además, para cuando pongas en práctica un caso de uso concreto, las tecnologías pueden haber cambiado ligeramente y necesitar una actualización.

Incluso con un ejemplo perfectamente implementado, es poco probable que coincida exactamente con lo que necesita tu propio negocio o con lo que debería priorizar. Los casos de uso cubren mi experiencia de los problemas habituales de los clientes, pero los tuyos serán sin duda ligeramente diferentes. Como lo más probable es que tengas que adaptar los casos de uso a tus propias necesidades, es importante que entiendas no sólo lo que hay que hacer, sino también por qué lo hacemos de una manera y no de otra. Así podrás adaptar el proceso a tus propias prioridades.

A pesar de tus requisitos individuales, se pueden vincular algunos temas comunes en relación con la forma de enfocar estos proyectos. El Capítulo 2 abarca un marco que tienen en común todos los proyectos de integración de datos en los que he trabajado con éxito. Los casos de uso seguirán este marco para darte práctica en su aplicación. Las cuatro áreas principales son la ingestión de datos, el almacenamiento, el modelado y la activación. Sin embargo, la pregunta que plantea el caso de uso es el motor principal de todo esto, porque si intentas resolver un problema que en realidad no va a ayudar a tu empresa cuando se resuelva, todo el esfuerzo no será tan eficaz como deseas. Encontrar el problema adecuado que resolver es importante para tu propio negocio, por eso en el Capítulo 2 también repasaremos algunas preguntas que puedes hacerte para ayudarte a definirlo.

Los casos prácticos de uso te permitirán concentrarte únicamente en el trabajo práctico de implementación. La mejor forma de aprender será seguirlos y ponerlos en práctica, en lugar de limitarte a leerlos. También pueden servirte de referencia cuando pongas en práctica tus propios casos de uso, ya que a menudo puedes reutilizar aspectos de una solución dentro de otra. Por ejemplo, todos los casos de uso de este libro utilizan GA4 como fuente de ingestión de datos. Los casos de uso también intentan utilizar varias tecnologías diferentes para cubrir una amplia gama de aplicaciones.

Caso práctico: Compras predictivas

El primer caso de uso del Capítulo 7 es un de referencia para que te acostumbres al planteamiento general que comparte su estructura con los casos de uso más complejos que aparecen más adelante en el libro. Sólo utilizaremos una plataforma, GA4. Los mismos principios se siguen aplicando a los casos de uso más complejos, pero esto también debería mostrar cómo es posible cambiar GA4 por otras aplicaciones si se adapta mejor a tus necesidades. Este caso utiliza varias de las nuevas funciones de GA4, incluido su aprendizaje automático y las exportaciones de audiencia.

La compra predictiva utiliza el modelado para predecir si un usuario comprará o no en el futuro. Esto puede utilizarse para modificar el contenido del sitio o la estrategia publicitaria para esos usuarios. Por ejemplo, si la probabilidad de que un usuario realice una compra es superior al 90%, quizá debamos suprimir el marketing dirigido a ese usuario porque el trabajo ya está hecho. Por el contrario, si la probabilidad de compra es inferior al 30%, quizá deberíamos considerar a ese usuario una causa perdida. Promulgar una política de este tipo significa que puedes mover tu asignación presupuestaria para dirigirte sólo al 60% de los usuarios que pueden o no comprar. Esto debería reducir tu coste por adquisición (CPA) y aumentar potencialmente tus ingresos por ventas.

Para ello, utilizaremos GA4 para hacer lo siguiente:

  • Recopilar datos sobre el sitio web, incluidos los eventos de conversión

  • Almacena todos los datos que necesitamos

  • Proporciona modelado de datos utilizando sus métricas predictivas como la compra y la probabilidad

  • Exporta a Google Ads para activarlo utilizando las Audiencias de GA4

Este proceso se ilustra en el sencillo diagrama de arquitectura de datos de la Figura 1-2.

Data Architecture for the Predictive Audiences use case: website data is sent to Google Analytics 4 which creates the predictive audience that is then exported to Google Ads
Figura 1-2. Arquitectura de datos para el caso de uso de audiencias predictivas

No será necesaria ninguna programación para ponerlo en marcha, y toda la configuración se hará dentro de la IU.

Las métricas predictivas son una función integrada dentro de GA4 y utilizan directamente las capacidades de Google en aprendizaje automático para marcar una diferencia real en el funcionamiento de tu negocio. Sin embargo, tu sitio web debe cumplir ciertos criterios para poder utilizar la función de métricas predictivas, lo que te resta control sobre cuándo se puede utilizar la función. Si no puedes utilizar las métricas predictivas, es posible que aún puedas utilizar tus propios datos y construir el modelo tú mismo y utilizar después la integración de Google Ads. Cubriremos esto en la siguiente sección.

Caso práctico: Segmentación de audiencias

El caso de uso de segmentación de audiencias en Capítulo 8 te muestra cómo comprender mejor el comportamiento agregado de tus clientes. ¿Qué tendencias o comportamientos comunes puedes detectar para atender mejor a ese segmento? ¿Cuántos tipos de clientes tienes? ¿Los segmentos basados en datos que has encontrado coinciden con los supuestos de tu negocio?

Estos proyectos de segmentación se han utilizado históricamente para ayudar a personalizar los mensajes de marketing para esos usuarios. Por ejemplo, se puede identificar a determinados clientes como más propensos a comprar productos de venta cruzada, de modo que puedes limitar los mensajes de marketing sólo a esos clientes para reducir los costes de las campañas y evitar mensajes innecesarios a clientes a los que pueden molestar.

Puedes segmentar en función de muchos criterios diferentes. Un método de éxito anterior a Internet es el modelo RFM, que examina la recencia, la frecuencia y el comportamiento monetario de los usuarios y segmenta a aquellos con puntuaciones similares en cada sector. Con la gran cantidad de datos disponibles ahora, puedes hacer otros modelos con cientos de campos. El modelo que elijas se regirá en gran medida por los requisitos empresariales de tu caso de uso, así como por sus consideraciones de privacidad. La privacidad es importante aquí, ya que puede ser necesario recabar el consentimiento de los usuarios para incluir sus datos en los modelos. Si no recoges el consentimiento, el cliente puede molestarse si se le selecciona como objetivo.

Utilizando este ejemplo, nos gustaría que nuestros costes de Google Ads fueran más eficientes. En este contexto, Google Ads asumirá el papel de activación de datos, ya que es ahí donde enviaremos los datos para realizar un cambio en el comportamiento del usuario. Nuestro argumento comercial es reducir los costes y obtener mayores ventas si podemos adaptar mejor nuestros mensajes.

Nos gustaría utilizar los datos que tenemos sobre el comportamiento de un cliente en el sitio web y su historial de compras para determinar si debemos o no mostrarle determinados anuncios. Para ello, utilizaremos lo siguiente:

  • GA4 y nuestra base de datos de gestión de relaciones con los clientes (CRM) como fuentes de datos

  • Almacenamiento en la nube y BigQuery como nuestro almacenamiento de datos

  • BigQuery para crear nuestros segmentos

  • Firestore para enviar esos segmentos a nuestros usuarios GA4 en tiempo real

  • GTM SS para enriquecer los datos GA4

  • GA4 Audiencias para enviar esos segmentos a Google Ads

Las interacciones entre estos servicios se muestran en la Figura 1-3.

Por el camino, también nos aseguraremos de que se respeten las opciones de privacidad y de que no se exporten ni transfieran datos personales donde no se necesiten.

Las tecnologías que utilizaremos para los siguientes servicios se tratarán más adelante en profundidad en los capítulos correspondientes:

  • GA4 para medición web

  • Una base de datos de producción para el historial de compras de los usuarios

  • Importación a través de Almacenamiento en la Nube, Pub/Sub y Funciones en la Nube

  • BigQuery para crear los modelos de segmentación

  • Cloud Composer para programar las actualizaciones

  • Almacenamiento en la nube, Pub/Sub y Funciones en la nube para importar los segmentos a GA4

  • GA4 para crear los públicos

Necesitarás conocimientos de Python y SQL, así como cierto trabajo de configuración dentro de GA4, la consola de Google Cloud y Google Ads. También tendremos que asegurarnos de que estamos recopilando los datos correctos dentro de GA4 para que podamos vincular la actividad web con los datos de CRM de una manera que respete la privacidad.

Data Architecture for the User Segmentation use case
Figura 1-3. Arquitectura de datos para el caso de uso de segmentación de usuarios

Caso práctico: Previsión en tiempo real

El caso práctico del Capítulo 9 trata sobre la creación de una aplicación de previsión en tiempo real. La analítica en tiempo real suele ser una de las primeras peticiones de las empresas cuando se adentran en la analítica, pero normalmente se le quita prioridad si descubren que no pueden reaccionar a ese flujo de datos en tiempo real. Sin embargo, si tienes esa capacidad, es un proyecto apasionante en el que trabajar porque puedes ver los beneficios inmediatos.

Un buen ejemplo de este caso de uso es la redacción de un editor que reacciona a los acontecimientos en tiempo real durante el día a la hora de elegir qué historias publicar o promocionar. En una empresa donde los clics y las visualizaciones significan ingresos, un éxito viral en las redes sociales puede tener un gran impacto empresarial. Conseguir ese éxito requiere repetidos intentos, edición y promoción en las páginas de inicio, y una alimentación constante en tiempo real de los temas y sentimientos que marcan tendencia en las redes sociales. El caso de uso que detallamos aquí muestra cómo tomar ese flujo de datos de analítica web y prever lo que hará ese tráfico basándose en la captación actual. Puedes hacer estas previsiones sobre Audiencias GA4 que se hayan configurado para identificar diferentes segmentos de tus clientes.

Este caso de uso demostrará el uso de Docker para gestionar la ejecución de la solución del panel de control en Cloud Run, que ejecuta el paquete de aplicaciones web Shiny de R. Una razón clave para utilizar Docker es que puedes cambiar el código que se ejecuta dentro de los contenedores por cualquier otro lenguaje, por lo que se podría sustituir por Python, Julia u otro futuro lenguaje de ciencia de datos. Los roles de datos para este proyecto incluyen:

  • Ingesta de datos mediante API

  • Almacenamiento de datos dentro de la aplicación

  • Modelado de datos en R

  • Activación de datos mediante un panel R Shiny

Para lograr este caso de uso, necesitaremos lo siguiente:

  • GA4 para recoger el flujo de eventos web en tiempo real

  • Cloud Run para ejecutar el panel de control

  • GA4 Audiencias para tener un segmento útil para hacer previsiones

La Figura 1-4 muestra cómo se conectan entre sí estos recursos.

Real-time data is taken from GA4 and a forecast is created to inform employee what content they should prioritise for social media content and on-site banners via Google Optimise
Figura 1-4. Se toman datos en tiempo real de GA4 y se crea una previsión para ayudar a priorizar el contenido para las redes sociales y los banners in situ a través de Google Optimize

Utilizaremos algunos conocimientos de R para crear las fuentes y el modelado en tiempo real, y utilizaremos algunos conocimientos de visualización de cuadros de mando para crear el cuadro de mando.

Resumen

Este capítulo ha presentado las principales formas de utilizar GA4 para avanzar en tus implementaciones de analítica digital. Exploramos por qué se creó GA4 en primer lugar y cómo difiere y mejora Universal Analytics con su nuevo modelo de datos más sencillo. También exploramos cómo su integración con GCP abre tu analítica digital a todo un nuevo mundo de aplicaciones que implican servicios como Firebase y BigQuery. Aunque el uso de estos nuevos servicios en la nube requiere nuevas habilidades como la codificación, los nuevos servicios de la nube hacen que esto sea más accesible que en el pasado. Las ofertas de arquitectura sin servidor han hecho posible abstraerse de gran parte del trabajo de configuración y escalado de los servicios informáticos. Una recomendación general cuando se empieza es intentar utilizar servicios lo más arriba posible en la arquitectura para mantener la barrera de entrada lo más baja posible.

Aunque la tecnología ya está disponible, cómo abordarla y utilizarla mejor es una habilidad clave que puede resultar desconocida para los profesionales del marketing digital que no hayan utilizado la nube antes, por lo que en el Capítulo 2, estableceremos el marco general y la estrategia para crear proyectos de análisis de datos de éxito que puedan repetirse en muchos proyectos. Desarrollaremos las funciones de la ingestión de datos, la recopilación de datos, el modelado de datos y la activación de datos desde una perspectiva estratégica, listos para los capítulos de aplicación práctica que siguen.

Get Aprender Google Analytics now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial