Como atualizar seus relatórios para o Google Analytics 4 sem dor de cabeça

Os usuários do Google Analytics Universal (GAU) terão que mudar para o Google Analytics 4 (GA4) no verão de 2023. O principal problema com isso é que o modelo de dados e a lógica de cálculo das métricas são radicalmente diferentes no GA4 em comparação com o GAU. Depois de fazer a mudança para GA4, parte dos dados históricos serão mantidos na estrutura GAU, enquanto os novos dados serão armazenados na estrutura GA4. Por esse motivo, as empresas devem fazer um esforço sério para avaliar as métricas ano a ano (YoY) após a mudança (pelo menos mais de 100 horas de trabalho para analistas de dados de nível médio).

Para os analistas, isso significa que eles passarão dia após dia escrevendo e organizando páginas de consultas SQL para alcançar o alinhamento entre o Google Analytics Universal e as métricas do Google Analytics 4. No entanto, há uma maneira de contornar isso! Os analistas podem criar relatórios ad hoc em minutos sem reescrever constantemente as consultas SQL e, neste artigo, explicamos como.

O Universal Analytics será desativado em 1º de julho de 2023 e será substituído pelo Google Analytics 4. Para clientes do Google Analytics 360 (a versão paga do GA), o período de transição foi prolongado até 1º de julho de 2024. Mas não importa qual versão do GA você usa, é apenas uma questão de tempo até que seus relatórios sejam atualizados para o novo esquema de dados.

Diante dessa mudança, uma das tarefas mais desafiadoras para os analistas é fornecer dados do Google Analytics Universal e do Google Analytics 4 em um formato unificado.

Circunstâncias que complicam esta tarefa:

• A lógica de cálculo de métricas difere significativamente entre GAU e GA4. Notavelmente, essas versões do produto calculam até mesmo as métricas tradicionais de maneira diferente. Você não pode arrastar todas as métricas do GAU e do GA4 para um gráfico e esperar que tudo corra bem.
• Os esquemas de dados do Google BigQuery também são significativamente diferentes. O Universal Analytics aplica esquemas de dados baseados em sessão, enquanto o Google Analytics 4 possui esquemas de dados baseados em eventos.
• Os painéis incluem métricas YoY e tendências de sazonalidade. Então a questão é como continuar usando dashboards com todas essas métricas.

Vejamos um exemplo específico. Digamos que temos este painel:

A parte mais importante deste painel são as métricas de sazonalidade, que representam uma comparação de métricas específicas para os períodos atual e passado. Os dados históricos e operacionais devem estar no mesmo formato para oferecer suporte às métricas YoY nos painéis de marketing.

Nesse caso, o desafio do analista é atualizar N+ consultas SQL legadas para fornecer relatórios confiáveis ​​para a equipe de marketing. É difícil testar e depurar tudo o que pode ser afetado por pequenas correções em consultas SQL.

Os riscos de transição também devem ser considerados. Depois de transferir um relatório para a nova fonte (do GAU para o GA4), os analistas podem não levar em conta as diferenças fundamentais no esquema de dados e na lógica de cálculo das métricas. Por exemplo, as sessões são formadas de forma diferente: apenas a primeira origem do usuário é considerada no GA4 e todas as outras origens que levam a uma sessão são negligenciadas. Portanto, algumas origens de tráfego não ficarão visíveis no relatório.

A princípio, isso pode passar despercebido. Mas em dois a três trimestres, um painel incorreto levará a gastos ineficientes com publicidade, com 30% ou mais de vazamento de orçamento.

Preparar e criar painéis nos lembra de Jenga. Sempre que precisam substituir um bloco em um relatório, os analistas cruzam os dedos e torcem para que toda a estrutura não caia.

Na OWOX, já estamos resolvendo problemas semelhantes ao transferir os relatórios de nossos clientes do esquema de dados do Universal Analytics (ou GA 360) para o esquema de dados do Google Analytics 4. É por isso que queremos compartilhar nossa solução e algumas consultas SQL com nossos leitores do blog. Espero que essas informações o ajudem a transferir seus relatórios sem dores de cabeça.

Nossa abordagem para preparar relatórios (independentemente da esfera de negócios para a qual eles são criados) é baseada em dados brutos e não em dados modelados.

Um modelo de dados descreve entidades de dados, seus atributos e os relacionamentos entre entidades. Por exemplo, as ações dos usuários no site são mescladas para uma determinada sessão e um usuário pode fazer várias conversões online em uma sessão.

Existem quatro objetos — Ações, Usuários, Sessão e Conversão online — e três conexões: um-para-muitos entre sessões e ações, um-para-muitos entre o usuário e as conversões online e um-para-muitos entre sessões e conversões on-line.

O modelo de dados reflete nossa percepção do mundo real e responde a perguntas comosobre o que são nossos dados?Como está relacionado?Quais condições e restrições aplicamos ao trabalhar com dados?Um modelo de dados é necessário para que as pessoas se entendam claramente.

A modelagem de dados é o processo de transformar dados em um formato que atenda aos requisitos do seu modelo de dados.

• Aumente o valor e a eficiência do trabalho analítico ao:
• Acelerando mudanças nas estruturas de relatórios e na lógica de cálculo de métricas
• Reduzindo o custo de suporte a relatórios e painéis
• Simplificando discussões e aprovações de relatórios
• Aumente a qualidade dos dados nos relatórios:
• Evitando duplicação ao implementar a lógica de cálculo de parâmetros e métricas
• Ter uma camada de dados que é a fonte de dados precisos

O modelo de dados substitui inúmeras ferramentas e descreve a lógica de um relatório, pois descreve objetos e sua lógica de cálculo (válida para todos os relatórios).

O OWOX BI transforma dados brutos em um formato pronto para análise, economizando horas de preparação de dados. Ele integra perfeitamente os dados do Universal Analytics e do Google Analytics 4 em seus relatórios.

Aqui está um exemplo de um modelo de dados criado com base nos dados do Google Analytics:

Como você pode ver, existem vários objetos, incluindo sessões, transações, páginas e dispositivos.

O mais interessante e importante aqui é que a estrutura desses objetos não está interligada e não tem nada a ver com as fontes de dados. Não importa quais fontes são usadas para preencher esses objetos com dados ao vivo (Matomo, Adobe, Google Analytics, etc.). Independentemente da fonte de dados, o modelo retorna os mesmos objetos que o modelo de dados representa seu negócio. Ele ilustra os objetos e métricas do mundo real com os quais você trabalha.

Vamos ver como é no mundo real.

Em vez de escrever consultas SQL sobre dados brutos, como sessões exportadas do Universal Analytics ou eventos exportados do Google Analytics 4, você pode criar dados modelados. São tabelas universais e fáceis de entender na parte superior que representam objetos e entidades do mundo real, como sessões, usuários e exibições de página.

Vamos considerar exemplos específicos e esquemas de dados.

Aqui está um exemplo de dados brutos. Estas são capturas de tela de um esquema de dados do Google BigQuery para Google Analytics Universal (à esquerda) e Google Analytics 4 (à direita).

Como escrevemos acima, os esquemas de dados diferem. Precisamos encontrar uma maneira de vincular esses dados ao painel do Google Data Studio.

Com base em nossa experiência, criar tabelas modeladas é a melhor maneira de simplificar a preparação de dados. Veja como eles podem ser:

Estas são as listas de objetos do modelo de dados acima. Você pode ver que a lista de objetos é a mesma para Google Analytics 360 e Google Analytics 4.

Isso significa que você pode conectar sua consulta de painel com esses dados usando as mesmas consultas. A estrutura desta consulta é a mesma.

Vejamos os motivos importantes para considerar a criação de seus relatórios em dados modelados em vez de dados brutos.

1. Dados são como frutas: você deve limpá-los antes de misturá-los.Os analistas coletam dados de serviços e sistemas diferentes. Naturalmente, a estrutura e o formato desses dados variam entre as fontes. Para criar relatórios, os dados de diferentes fontes devem ser mesclados corretamente. Por si só, os dados carregados por meio de conectores ou vários serviços ETL são imprecisos (contendo erros, duplicatas e discrepâncias) e carecem de lógica e estrutura unificadas. Dados imprecisos e fragmentados devem ser limpos e normalizados em um formato pronto para análise.

Com OWOX BI, você não precisa limpar, estruturar e processar dados manualmente. O serviço normalizará automaticamente os dados brutos em um formato pronto para análise.

2. Você não precisa copiar e reescrever a lógica de negócios para cada relatório;por exemplo, você não precisa:

• Desduplicar transações
• Filtrar bot e tráfego interno
• Definir regras de agrupamento de canais
• Definir critérios para usuários novos e recorrentes
• Corrigir rastreamento de parâmetro UTM

Sem dúvida, todo analista de dados já ouviu solicitações de profissionais de marketing como estas: Gostaríamos de ajustar ou melhorar nossas regras de agrupamento de canais com base em dados históricos ou Gostaríamos de identificar critérios para usuários novos e recorrentes que não funcionam da maneira como funciona no Google Analytics, mas à nossa maneira ou Gostaríamos de considerar como retorno apenas os usuários que fizeram uma compra nos últimos seis meses.

Se você criar relatórios com base em dados brutos, todas as transformações de dados e atividades de preparação deverão ser executadas no nível do relatório. Isso significa que você deve gastar muito tempo copiando a lógica de negócios em cada relatório.

Se você criar relatórios sobre dados modelados, não precisará copiar a lógica de negócios. Você o cria uma vez no estágio de modelagem.

3. A criação de relatórios com base em dados modelados acelera a análise ad hoc.Você pode economizar tempo escrevendo novas transformações de SQL e orquestração para permitir a análise anual.

4. Graças à modelagem de dados, você pode criar uma única fonte de verdade para todos os relatórios.Quando você altera a fonte de dados em um relatório, não precisa mais resolver todas as consultas problemáticas. Você pode contar com essa fonte para sessões, transações e dados de eventos.

5. Simplifique a camada de relatórios.Construir relatórios sobre dados modelados é mais fácil do que lidar com campos aninhados e campos de registro, além de escrever algumas funções complicadas de janela ou mesmo funções de extração JSON.

1. Dados modelados são mais uma camada intermediária.Leva tempo para ajustar e você também deve monitorar e depurar dados modelados.

2. JOINs complexos para normalizações.

3. Processamento de dados extras.Para converter dados em um formato de modelo, você precisa consultar os dados. Aconselhamos você a usar uma tabela de partições em um encontro. Com uma tabela de partição construída em torno de dimensões de data, você pode atualizar apenas os dados necessários. Você não precisa reescrever todas as tabelas enormes e pagar por todos os dados processados ​​e gigabytes ou terabytes de dados no Google BigQuery. Você pode apenas atualizar e atualizar a partição de que precisa. Essa abordagem é mais econômica do que lidar com todas as tabelas de dados.

Para ajudá-lo a lidar com esses contras, preparamos modelos SQL para modelar dados do Google Analytics 360 e Google Analytics 4. Você pode verificá-los baixando os materiais adicionais fornecidos neste artigo.

É fácil atualizar seus relatórios para o novo esquema de dados do Google Analytics 4? Use dados modelados. Em vez de criar relatórios sobre dados brutos, você pode criar tabelas planas universais e fáceis de entender sobre os esquemas GA Universal e GA 4.

Isso eliminará a necessidade de copiar dados e inserir a lógica de normalização em dezenas de consultas SQL. Você fará isso uma vez no estágio de modelagem de dados. Embora não seja uma bala de prata para todos os projetos, é o método ideal para aqueles que exigem relatórios especiais regularmente.

Inscreva-se para uma demonstração do OWOX BI se quiser configurar e orquestrar tabelas modeladas. Teremos o prazer de compartilhar detalhes sobre como preparar tabelas semelhantes em seus projetos com base em seus dados.