Uma ponte entre a interface do Google Analytics e o BigQuery Export

Minhaz Kazi, mediador de desenvolvedores, Google Analytics – abril de 2023

"Por que os números não correspondem à interface?"

Se você já trabalhou com dados de exportação de eventos do BigQuery da sua propriedade do GA4, com certeza já fez essa pergunta. Ou pior: outra pessoa te perguntou isso. E enquanto você tentava responder, provavelmente fizeram esta terrível pergunta:

"E onde isso está escrito?"

Neste artigo, vamos tentar esclarecer as duas questões.

Antes de entrar em detalhes sobre como os números variam, é importante entender a finalidade dos dados de exportação de eventos do BigQuery. Os usuários do Google Analytics enviam os dados coletados para o GA usando um destes métodos de coleta: tag do Google, Gerenciador de tags do Google, Measurement Protocol, SDKs e importação de dados. Com base nas configurações da propriedade do GA, o Google Analytics faz uma adição de valor significativa aos dados coletados antes de eles chegarem às plataformas de geração de relatórios, incluindo os relatórios padrão, as Análises detalhadas e a API Data. Essas adições podem incluir Indicadores do Google, modelagem, atribuição de tráfego, previsão etc.

O objetivo das plataformas de geração de relatórios padrão é fornecer o maior valor possível aos usuários do GA com o menor atrito. No entanto, entendemos que, no amplo espectro de usuários, alguns podem querer complementar o valor agregado pelo Google Analytics ou até mesmo fazer algo totalmente personalizado. Para esses usuários, a exportação de eventos do BigQuery é o ponto de partida. A exportação de eventos do BigQuery trabalha com os dados coletados, que são enviados do cliente ou app para o Google Analytics. Ela não contém dados granulares sobre a maioria das adições de valor mencionadas acima.

Assim, em um grande número de casos de uso, não esperamos que seja possível reconciliar as plataformas de geração de relatórios padrão e os dados de exportação do BigQuery no que se refere a essas adições de valor. Se eles tiverem consistência interna e corresponderem aos dados que você está coletando, não precisa se preocupar.

Agora, vamos conferir alguns dos motivos específicos das diferenças e conhecer formas de minimizá-las quando possível. Este artigo se concentra apenas na exportação de eventos diários do BigQuery, e não na exportação de streaming.

Amostragem

Para ter uma comparação precisa dos seus dados do BigQuery Export com os relatórios padrão, da API Data ou de análise detalhada, confirme que eles se baseiam em dados de amostra. A amostragem de dados no GA4 oferece mais detalhes e formas de lidar com esse tipo de análise.

Usuários ativos

A contagem de todos os usuários que registraram pelo menos um evento na sua propriedade do GA4 é apresentada na métrica Total de usuários. Ela está disponível nas Análises detalhadas na interface do GA4, mas a principal métrica de usuários encontrada nos relatórios desse produto é Usuários ativos. Na interface e nos relatórios do GA4, o termo Usuários geralmente se refere aos Usuários ativos. Portanto, ao calcular a contagem de usuários com base nos dados do BigQuery, é necessário filtrar e manter apenas os usuários ativos para que os números sejam comparáveis aos que aparecem na interface do GA. O método de cálculo também varia de acordo com a identidade do relatório selecionada.

Implementação técnica

Nos dados da exportação de eventos do BigQuery, a contagem do número de IDs de usuário diferentes é apresentada na métrica Total de usuários. Confira um exemplo de consulta que mostra o "Total de usuários" e "Novos usuários" com base em user_pseudo_id:

-- Example: Get 'Total User' count and 'New User' count.

WITH
  UserInfo AS (
    SELECT
      user_pseudo_id,
      MAX(IF(event_name IN ('first_visit', 'first_open'), 1, 0)) AS is_new_user
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
    GROUP BY 1
  )
SELECT
  COUNT(*) AS user_count,
  SUM(is_new_user) AS new_user_count
FROM UserInfo;

Para selecionar apenas usuários ativos, limite sua consulta a eventos em que é is_active_user é true:

-- Example: Get exact and approximate Active User count.

WITH
  ActiveUsers AS (
    SELECT
      user_pseudo_id
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
      AND is_active_user
    GROUP BY 1
  )
SELECT
  COUNT(DISTINCT user_pseudo_id) AS exact_active_user_count,
  APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_active_user_count
FROM ActiveUsers;

HyperLogLog++

O Google Analytics usa o algoritmo HyperLogLog++ (HLL++) para estimar a cardinalidade de métricas comuns, incluindo "Usuários ativos" e "Sessões". Isso significa que a contagem única dessas métricas na interface ou na API é um número aproximado com uma certa precisão. No BigQuery, como você tem acesso aos dados granulares, é possível calcular a cardinalidade exata dessas métricas. Por isso, pode haver uma pequena porcentagem de variação. Com um intervalo de confiança de 95%, a precisão pode ser de ±1,63% para a contagem de sessões. Os níveis de precisão variam em métricas diferentes e de acordo com os intervalos de confiança. Consulte Esboços do HLL++ e confira os níveis de precisão em diferentes intervalos de confiança para parâmetros de precisão distintos do HLL++.

Implementação técnica

Acesse o artigo Aproximação da contagem única no Google Analytics para entender como o HLL++ foi implementado no Google Analytics e como você pode replicar a funcionalidade usando consultas do BigQuery.

Atraso na coleta de dados

As tabelas de exportação diárias são criadas depois que o GA coleta todos os eventos do dia. Elas podem ser atualizadas até 72 horas após a data da tabela com eventos que incluem o carimbo de data e hora do dia correspondente. Confira detalhes e exemplos. Isso pode ser um problema se a sua implementação do SDK do Firebase ou do Measurement Protocol envia eventos off-line ou atrasados. Dependendo de quando a plataforma de geração de relatórios padrão e o BigQuery forem atualizados dentro dessas 72 horas, você poderá notar diferenças entre eles. Para essa implementação, faça comparações em dados com mais de 72 horas.

Relatórios de alta cardinalidade

Vamos supor que você esteja visualizando um relatório na seção de relatórios padrão ou na API Data. Ele mostra uma grande quantidade de dados e tem dimensões com alta cardinalidade. Esse tipo de dimensão pode fazer com que o relatório exceda o limite de cardinalidade da tabela. Quando isso acontece, o Google Analytics agrupa os valores menos frequentes e os marca como (Outros).

Usando um exemplo simplificado e de pequena escala, se o limite de cardinalidade da tabela for de 10 linhas, confira o que vai acontecer:

Como você pode notar, o número total de eventos permanece inalterado. No entanto, os valores menos frequentes são agrupados, e não é possível agregar a tabela novamente com base em qualquer dimensão. Por exemplo, não dá para usar a tabela de agregação e derivar a contagem total de eventos de uma cidade específica com alta precisão. O exemplo fica mais claro quando filtramos os dados agregados com base em qualquer uma das dimensões.

Esse agrupamento da linha "(Outros)" só ocorre no módulo de relatórios e na API Data quando o relatório excede o limite de cardinalidade. Se você fizer cálculos com base no BigQuery, sempre vai ter dados de informações empíricas, as linhas mais granulares. Saiba mais sobre linha "(Outros)" e confira práticas recomendadas para evitá-la.

Indicadores do Google

A ativação dos Indicadores do Google na sua propriedade do GA4 tem vários benefícios, incluindo a possibilidade de eliminar a duplicação de usuários em várias plataformas e dispositivos. Quando o User-ID e os Indicadores do Google não estão implementados, e uma pessoa acessa seu site em três navegadores da Web, o Google Analytics conta essas interações como três usuários diferentes, e o BigQuery Export mostra três user_pseudo_ids distintos. No entanto, quando os Indicadores do Google estão ativados e a pessoa está conectada à Conta do Google nos três navegadores, o Google Analytics duplica um usuário e mostra essa contagem nas plataformas de geração de relatórios padrão. O BigQuery ainda mostra três user_pseudo_ids diferentes. Nenhuma informação dos Indicadores do Google está disponível na exportação do BigQuery. Assim, os relatórios com dados dos Indicadores do Google provavelmente têm uma contagem menor de usuários em comparação com a exportação do BigQuery.

A melhor maneira de diminuir esse efeito é implementando User-IDs na sua propriedade do GA4 com a ativação dos Indicadores do Google. Isso garante que a eliminação de duplicação aconteça primeiro com base em user_id. Para usuários conectados, o campo user_id será preenchido no BigQuery e poderá ser usado em cálculos. No entanto, quando os usuários não fazem login (ou seja, sessões sem user_id), os Indicadores do Google ainda são usados para a eliminação de duplicação.

Além disso, alguns relatórios em plataformas de geração de relatórios padrão podem ter limites aplicados e não retornar alguns dados. A maioria das informações que podem estar sujeitas a um limite geralmente não está disponível na exportação do BigQuery.

Modo de consentimento e dados estimados

O modo de consentimento em sites e apps para dispositivos móveis permite que você comunique ao Google o status de consentimento dos seus usuários referentes a cookies ou identificadores de app. Quando os visitantes negam o consentimento, o GA4 preenche as lacunas da coleta de dados com a estimativa de conversão e a modelagem comportamental. Nenhum dos dados estimados está disponível na exportação de eventos do BigQuery. Quando o modo de consentimento está implementado, o conjunto de dados do BigQuery contém pings sem cookies coletados pelo GA, e cada sessão tem um user_pseudo_id diferente. Devido à modelagem, haverá diferenças entre as plataformas de geração de relatórios padrão e os dados granulares no BigQuery. Por exemplo, com a modelagem comportamental, o número de usuários ativos pode ser menor em comparação com o BigQuery Export, já que o recurso pode tentar prever as várias sessões dos usuários individuais que não deram consentimento.

Novamente, para reduzir esse efeito, é necessário implementar User-IDs na sua propriedade do GA4. O user_id e as dimensões personalizadas são exportadas para o BigQuery, seja qual for o status de consentimento dos seus usuários.

Dados de atribuição de tráfego

No BigQuery, os dados de atribuição de tráfego estão disponíveis para o usuário (primeira visita) e o evento. Esses são os dados coletados. No entanto, como o Google Analytics implementa o próprio modelo de atribuição no nível da sessão, essas informações não estão diretamente disponíveis no BigQuery Export nem podem ser calculadas com precisão total usando os dados disponíveis. Dependendo do seu caso de uso, considere mesclar o conjunto de dados do BigQuery com os dados próprios relevantes e criar seu próprio modelo de atribuição. No futuro, outros dados coletados para atribuição de tráfego poderão ser disponibilizados pela exportação de eventos do BigQuery.

Erros comuns de cálculo

• Método de cálculo: ao calcular métricas diferentes no BigQuery, garanta o uso da metodologia correta. Por exemplo:
  • O método padrão de contagem de sessões das propriedades do Google Analytics 4 contabiliza as combinações únicas de user_pseudo_id/user_id e ga_session_id, independentemente do período. No Universal Analytics, as sessões eram redefinidas à meia-noite. Se você seguir o modelo do UA, calcular as sessões de cada dia e fazer a soma para chegar ao número total, vai contar duas vezes as sessões que abrangem vários dias.
  • Dependendo da identidade do relatório selecionada, o método de cálculo da contagem de usuários precisa ser atualizado.
• Escopo da métrica e da dimensão: verifique se os cálculos usam o escopo correto de usuários, sessões, itens ou eventos.
• Fuso horário: na exportação do BigQuery, event_date é o fuso horário do relatório, enquanto event_timestamp é um carimbo de data/hora no fuso horário UTC, em microssegundos. Portanto, se você usar event_timestamp em uma consulta, o ideal é fazer o ajuste para o fuso horário do relatório na comparação com os números da interface.
• Filtragem de dados e limites de exportação: se você configurou a filtragem de dados para a exportação de eventos do BigQuery ou se o seu volume de exportações de eventos diários excedeu o limite, os dados de exportação de eventos do BigQuery não vão corresponder às plataformas de geração de relatórios padrão.

Esta postagem tem bastante conteúdo para você. Espero que as diretrizes apresentadas aqui sejam úteis na hora de escolher as melhores soluções para seu projeto. Se você tiver alguma dúvida, use o servidor do Discord no GA, onde suas consultas são muito bem-vindas.