Cómo actualizar tus informes para Google Analytics 4 sin dolor de cabeza

Los usuarios de Google Analytics Universal (GAU) deberán cambiar a Google Analytics 4 (GA4) en el verano de 2023. El principal problema con esto es que el modelo de datos y la lógica de cálculo de métricas son radicalmente diferentes en GA4 en comparación con GAU. Después de realizar el cambio a GA4, parte de los datos históricos se mantendrán en la estructura GAU, mientras que los nuevos datos se almacenarán en la estructura GA4. Por esta razón, las empresas deben hacer un gran esfuerzo para evaluar las métricas año tras año (YoY) después del cambio (al menos 100+ horas de trabajo para analistas de datos de nivel medio).

Para los analistas, esto significa que pasarán día tras día escribiendo y organizando páginas de consultas SQL para lograr la alineación entre las métricas de Google Analytics Universal y Google Analytics 4. Sin embargo, ¡hay una manera de evitar esto! Los analistas pueden crear informes ad hoc en minutos sin tener que reescribir constantemente las consultas SQL y, en este artículo, le decimos cómo hacerlo.

Universal Analytics desaparecerá el 1 de julio de 2023 y será reemplazado por Google Analytics 4. Para los clientes de Google Analytics 360 (la versión paga de GA), el período de transición se ha prolongado hasta el 1 de julio de 2024. Pero no importa qué versión de GA usa, es solo cuestión de tiempo antes de que sus informes se actualicen al nuevo esquema de datos.

A la luz de este cambio, una de las tareas más desafiantes para los analistas es proporcionar datos de Google Analytics Universal y Google Analytics 4 en un formato unificado.

Circunstancias que complican esta tarea:

• La lógica de cálculo de métricas difiere significativamente entre GAU y GA4. En particular, estas versiones de productos calculan incluso las métricas tradicionales de manera diferente. No puede arrastrar todas las métricas de GAU y GA4 a un gráfico y esperar que todo funcione sin problemas.
• Los esquemas de datos de Google BigQuery también son significativamente diferentes. Universal Analytics aplica esquemas de datos basados ​​en sesiones, mientras que Google Analytics 4 tiene esquemas de datos basados ​​en eventos.
• Los paneles incluyen métricas interanuales y tendencias de estacionalidad. Entonces, la pregunta es cómo seguir usando tableros con todas estas métricas.

Veamos un ejemplo específico. Digamos que tenemos este tablero:

La parte más crucial de este tablero son las métricas de estacionalidad, que representan una comparación de métricas específicas para los períodos actuales y pasados. Los datos históricos y operativos deben estar en el mismo formato para respaldar las métricas interanuales en los paneles de marketing.

En este caso, el desafío del analista es actualizar N+ consultas SQL heredadas para proporcionar informes confiables para el equipo de marketing. Es difícil probar y depurar todo lo que puede verse afectado incluso por correcciones menores a las consultas SQL.

También se deben considerar los riesgos de transición. Después de transferir un informe a la nueva fuente (de GAU a GA4), es posible que los analistas no tengan en cuenta las diferencias fundamentales en el esquema de datos y la lógica de cálculo de las métricas. Por ejemplo, las sesiones se forman de manera diferente: solo la primera fuente de usuario se considera en GA4 y todas las demás fuentes que conducen a una sesión se ignoran. Por lo tanto, algunas fuentes de tráfico no estarán visibles en el informe.

Al principio, esto puede pasar desapercibido. Pero en dos o tres trimestres, un tablero incorrecto conducirá a un gasto publicitario ineficiente, con una pérdida de presupuesto del 30% o más.

Preparar y crear tableros nos recuerda a Jenga. Cada vez que necesitan reemplazar un bloque en un informe, los analistas cruzan los dedos y esperan que no se derrumbe toda la estructura.

En OWOX, ya estamos resolviendo con éxito problemas similares al transferir los informes de nuestros clientes del esquema de datos de Universal Analytics (o GA 360) al esquema de datos de Google Analytics 4. Por eso queremos compartir nuestra solución y algunas consultas SQL con los lectores de nuestro blog. Con suerte, esta información lo ayudará a transferir sus informes sin dolores de cabeza.

Nuestro enfoque para preparar informes (independientemente de la esfera comercial para la que se crean) se basa en datos sin procesar en lugar de modelos.

Un modelo de datos describe entidades de datos, sus atributos y las relaciones entre entidades. Por ejemplo, las acciones de los usuarios en el sitio web se combinan para una sesión determinada y un usuario puede realizar varias conversiones en línea en una sesión.

Hay cuatro objetos: Acciones, Usuarios, Sesión y Conversión en línea, y tres conexiones: uno a muchos entre sesiones y acciones, uno a muchos entre el usuario y las conversiones en línea, y uno a muchos entre sesiones y conversiones en línea.

El modelo de datos refleja nuestra percepción del mundo real y responde preguntas como¿De qué se tratan nuestros datos?¿Cómo se relaciona?¿Qué condiciones y restricciones aplicamos al trabajar con datos?Un modelo de datos es necesario para que las personas se entiendan claramente.

El modelado de datos es el proceso de transformar datos en un formato que cumpla con los requisitos de su modelo de datos.

• Aumente el valor y la eficiencia del trabajo analítico al:
• Acelerar los cambios en las estructuras de informes y la lógica de cálculo de métricas
• Reducir el costo de respaldar informes y tableros
• Simplificación de las discusiones y aprobaciones de informes
• Aumente la calidad de los datos en los informes al:
• Evitar la duplicación al implementar la lógica de cálculo de parámetros y métricas
• Tener una capa de datos que sea la fuente de datos precisos

El modelo de datos reemplaza numerosas herramientas y describe la lógica de un informe, ya que describe objetos y su lógica de cálculo (que es válida para todos los informes).

OWOX BI transforma los datos sin procesar en un formato listo para análisis, lo que le ahorra horas de preparación de datos. Integra a la perfección los datos de Universal Analytics y Google Analytics 4 en sus informes.

Este es un ejemplo de un modelo de datos construido en base a los datos de Google Analytics:

Como puede ver, hay varios objetos, incluidas sesiones, transacciones, páginas y dispositivos.

Lo más interesante e importante aquí es que la estructura de estos objetos no está interconectada y no tiene nada que ver con las fuentes de datos. No importa qué fuentes se utilicen para llenar estos objetos con datos en vivo (Matomo, Adobe, Google Analytics, etc.). Independientemente de la fuente de datos, el modelo devuelve los mismos objetos que el modelo de datos representa para su negocio. Ilustra los objetos del mundo real y las métricas con las que trabaja.

Veamos cómo se ve en el mundo real.

En lugar de escribir consultas SQL sobre datos sin procesar, como sesiones exportadas de Universal Analytics o eventos exportados de Google Analytics 4, puede crear datos modelados. Son tablas universales y fáciles de entender en la parte superior que representan objetos y entidades del mundo real, como sesiones, usuarios y páginas vistas.

Consideremos ejemplos específicos y esquemas de datos.

Aquí hay un ejemplo de datos sin procesar. Estas son capturas de pantalla de un esquema de datos de Google BigQuery para Google Analytics Universal (izquierda) y Google Analytics 4 (derecha).

Como escribimos anteriormente, los esquemas de datos difieren. Necesitamos encontrar una manera de vincular estos datos al panel de control de Google Data Studio.

Según nuestra experiencia, la creación de tablas modeladas es la mejor manera de simplificar la preparación de datos. Así es como pueden verse:

Estas son las listas de objetos del modelo de datos anterior. Puede ver que la lista de objetos es la misma para Google Analytics 360 y Google Analytics 4.

Esto significa que puede conectar su consulta de tablero con estos datos utilizando las mismas consultas. La estructura de esta consulta es la misma.

Veamos las razones importantes para considerar la creación de sus informes sobre datos modelados en lugar de datos sin procesar.

1. Los datos son como la fruta: debes limpiarlos antes de licuarlos.Los analistas recopilan datos de servicios y sistemas dispares. Naturalmente, la estructura y el formato de esos datos varían según las fuentes. Para crear informes, los datos de diferentes fuentes deben fusionarse correctamente. Por sí mismos, los datos cargados a través de conectores o varios servicios ETL son inexactos (contienen errores, duplicados y discrepancias) y carecen de una lógica y estructura unificadas. Los datos inexactos y fragmentados deben limpiarse y normalizarse en un formato listo para análisis.

Con OWOX BI, no necesita limpiar, estructurar y procesar datos manualmente. El servicio normalizará automáticamente los datos sin procesar en un formato listo para análisis.

2. No necesita copiar y reescribir la lógica comercial para cada informe;por ejemplo, no es necesario que:

• Transacciones deduplicadas
• Filtrar bot y tráfico interno
• Definir reglas de agrupación de canales
• Definir criterios para usuarios nuevos y recurrentes
• Arreglar el seguimiento de parámetros UTM

Sin duda, todos los analistas de datos han escuchado solicitudes de especialistas en marketing como estas: Nos gustaría ajustar o mejorar nuestras reglas de agrupación de canales en función de datos históricos, o Nos gustaría identificar criterios para usuarios nuevos y recurrentes que no funcionan de la manera en que funciona. en Google Analytics, pero a nuestra manera o Nos gustaría considerar regresar solo a aquellos usuarios que hayan realizado una compra en los últimos seis meses.

Si crea informes basados ​​en datos sin procesar, todas las transformaciones de datos y las actividades de preparación deben ejecutarse en el nivel del informe. Eso significa que debe dedicar mucho tiempo a copiar la lógica comercial en cada informe.

Si crea informes sobre datos modelados, no tiene que copiar la lógica empresarial. Lo creas una vez en la etapa de modelado.

3. La creación de informes basados ​​en datos modelados acelera el análisis ad hoc.Puede ahorrar tiempo al escribir nuevas transformaciones de orquestación y SQL para habilitar el análisis anual.

4. Gracias al modelado de datos, puede crear una única fuente de información para todos los informes.Cuando cambia la fuente de datos en un informe, ya no tiene que resolver todas las consultas problemáticas. Puede confiar en esta fuente para sesiones, transacciones y datos de eventos.

5. Simplifique la capa de informes.Crear informes sobre datos modelados es más fácil que tratar con campos anidados y campos de registro, junto con escribir algunas funciones complicadas de ventana o incluso funciones de extracción JSON.

1. Los datos modelados son una capa intermedia más.Se necesita tiempo para ajustar, y también debe monitorear y depurar los datos modelados.

2. JOIN complejos para normalizaciones.

3. Tratamiento de datos extra.Para convertir datos en un formato de modelo, debe consultar los datos. Le recomendamos que utilice una tabla de partición en una fecha. Con una tabla de partición construida alrededor de las dimensiones de la fecha, puede actualizar solo los datos necesarios. No tiene que volver a escribir todas las tablas enormes y pagar por todos los datos procesados ​​y gigabytes o terabytes de datos en Google BigQuery. Simplemente puede actualizar y actualizar la partición que necesita. Este enfoque es más económico que manejar todas las tablas de datos.

Para ayudarlo a manejar estos inconvenientes, hemos preparado plantillas SQL para modelar los datos de Google Analytics 360 y Google Analytics 4. Puede consultarlos descargando los materiales adicionales proporcionados en este artículo.

¿Qué tan fácil es actualizar sus informes al nuevo esquema de datos de Google Analytics 4? Utilice datos modelados. En lugar de crear informes sobre datos sin procesar, puede crear tablas planas universales y fáciles de entender sobre los esquemas GA Universal y GA 4.

Hacer esto eliminará la necesidad de copiar datos e insertar lógica de normalización en docenas de consultas SQL. Lo hará una vez en la etapa de modelado de datos. Aunque no es una panacea para todos los proyectos, es el método óptimo para aquellos que requieren informes especiales con regularidad.

Regístrese para una demostración de OWOX BI si desea configurar y orquestar tablas modeladas. Con gusto compartiremos detalles sobre cómo preparar tablas similares en sus proyectos en función de sus datos.