Meça e depure a performance com o Google Analytics 4 e o BigQuery

Saiba como enviar dados das Métricas da Web para as propriedades do Google Analytics 4 e exportar os dados para análise no BigQuery e no Looker Studio.

O Google oferece várias ferramentas, como o Search Console, o PageSpeed Insights (PSI, na sigla em inglês) e o Chrome User Experience Report (CrUX, na sigla em inglês), que permitem que os desenvolvedores vejam como os sites se saem em relação às métricas de Core Web Vitals para os usuários reais no campo.

Essas ferramentas são ótimas porque oferecem uma visão geral do desempenho do site para usuários reais e não exigem nenhuma configuração para começar a usar.

No entanto, há alguns motivos importantes para não depender apenas dessas ferramentas para medir o desempenho do seu site:

  • As ferramentas baseadas em CrUX informam dados por períodos mensais ou anteriores de 28 dias. Isso significa que você terá que esperar muito tempo após fazer as mudanças para ver os resultados.
  • As ferramentas baseadas no CrUX só podem ser segmentadas por um número limitado de dimensões, como país, tipo de conexão e categoria de dispositivo (computador ou dispositivo móvel). Não é possível dividir os dados por dimensões específicas da sua empresa (por exemplo, usuários engajados, usuários em um grupo de experimentos específico etc.).
  • As ferramentas baseadas no CrUX podem informar o que é sua performance, mas não o motivo. Com as ferramentas de análise, você pode enviar mais dados para ajudar a rastrear e depurar problemas.

Por esses motivos, recomendamos que todos os proprietários de sites monitorem as métricas das Core Web Vitals usando a ferramenta de análise atual. Esta postagem explica como usar ferramentas sem custo financeiro oferecidas pelo Google para fazer isso.

Depois de configurar tudo, você poderá criar painéis como estes:

Captura de tela do relatório do conector das Métricas da Web

Captura de tela do relatório do conector das Métricas da Web

E se você quiser uma visão geral de todas as etapas descritas aqui, confira nossa palestra do Google I/O '21:

Medir

Sempre foi possível medir a performance com o Google Analytics usando métricas personalizadas, mas há alguns recursos novos no Google Analytics 4 (GA4) que os desenvolvedores devem gostar.

Embora a interface da Web do Google Analytics tenha ferramentas de análise poderosas, é difícil superar a eficiência e a flexibilidade do acesso a dados de eventos brutos usando uma linguagem de consulta que você provavelmente já conhece.

Para começar a medir as Core Web Vitals usando o Google Analytics 4 e o BigQuery, você precisa fazer três coisas:

  1. Crie uma propriedade do Google Analytics 4 e um projeto do BigQuery.
  2. Ative o BigQuery Export na configuração da propriedade do Google Analytics para que todos os dados recebidos sejam preenchidos automaticamente nas tabelas do projeto do BigQuery.
  3. Adicione a biblioteca JavaScript web-vitals ao seu site para medir as métricas das Core Web Vitals e enviar os dados ao Google Analytics 4, incluindo os dados de atribuição.

Analisar

Depois de configurar tudo, os dados de eventos vão ser preenchidos na interface do BigQuery, e você poderá consultar os dados assim:

SELECT * FROM `my_project_id.analytics_XXXXX.events_*`
WHERE event_name IN ('LCP', 'INP', 'CLS')

Confira uma prévia dos resultados dessa consulta:

Dados de eventos das Web Vitals no BigQuery

Consultar dados das Métricas da Web

Antes de começar a consultar os dados de eventos do Web Vitals, é importante entender como os dados são agregados.

O mais importante é entender que, em alguns casos, vários eventos podem ser recebidos para a mesma métrica na mesma página. Isso pode acontecer se o valor da métrica mudar e um valor atualizado for informado (uma ocorrência comum com a CLS).

Para os eventos de Web Vitals, o último valor enviado é sempre o mais preciso. Portanto, antes de realizar qualquer análise, é importante filtrar apenas esses valores. O snippet de código fornecido pela biblioteca JavaScript do Web Vitals para enviar dados ao Google Analytics 4 inclui o envio de um ID exclusivo por métrica. Assim, você pode usar a consulta a seguir para limitar os resultados apenas ao último valor recebido para cada ID de métrica:

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)

Todas as outras consultas mencionadas nesta postagem vão começar com essa subconsulta.

Exemplos de consultas

As próximas seções mostram alguns exemplos de consultas comuns do Web Vitals que você pode executar.

LCP, INP e CLS no percentil de 75% (p75) em todo o site

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  metric_name,
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS p75,
  COUNT(1) as count
FROM (
  SELECT
    metric_name,
    ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
  FROM web_vitals_events
)
GROUP BY 1

Todos os valores de LCP individuais, do maior para o menor

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
FROM web_vitals_events
WHERE metric_name = 'LCP'
ORDER BY metric_value DESC
# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  page_path,
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS LCP,
  COUNT(1) as count
FROM (
  SELECT
    REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
    ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
  FROM web_vitals_events
  WHERE metric_name = 'LCP'
)
GROUP BY 1
ORDER BY count DESC
LIMIT 10

As 10 páginas com a pior CLS (p75)

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  page_path,
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS CLS,
  COUNT(1) as count
FROM (
  SELECT
    REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
    ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
  FROM web_vitals_events
  WHERE metric_name = 'CLS'
)
GROUP BY 1
HAVING count > 50 # Limit to relatively popular pages
ORDER BY CLS DESC
LIMIT 10

Depurar

As consultas anteriores mostram como consultar os dados de métricas das Core Web Vitals, o que é útil para entender sua performance atual e como ela está evoluindo ao longo do tempo. Mas o que fazer se a performance estiver pior do que o esperado, mas você não souber por quê?

Saber o que são suas pontuações não é útil se você não puder agir e corrigir os problemas.

Depurar a performance no campo explica como enviar outras informações de depuração com seus dados de análise. Se você seguir as instruções detalhadas nessa postagem, as informações de depuração também vão aparecer no BigQuery.

Exemplos de consultas

As consultas a seguir mostram como usar o parâmetro de evento debug_target para ajudar a identificar a causa raiz dos problemas de desempenho.

Principais elementos que contribuem para o CLS

O debug_target é uma string de seletor de CSS que corresponde ao elemento na página mais relevante para o valor da métrica.

No caso da CLS, o debug_target representa o maior elemento da maior mudança de layout que contribuiu para o valor da CLS. Se nenhum elemento for deslocado, o valor de debug_target será null.

A consulta a seguir lista as páginas do pior para o melhor usando o valor de CLS no 75º percentil, agrupadas pelo debug_target:

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  page_path,
  debug_target,
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS CLS,
  COUNT(1) as count
FROM (
  SELECT
    REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = "debug_target") as debug_target,
    ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
    *
  FROM web_vitals_events
  WHERE metric_name = 'CLS'
)
GROUP BY 1, 2
HAVING count > 50 # Limit to relatively popular pages
ORDER BY CLS DESC

Resultado da consulta para os principais elementos que contribuem para a CLS

Saber quais elementos na página estão mudando vai facilitar muito a identificação e correção da causa raiz do problema.

Os elementos informados aqui podem não ser os mesmos que você vê ao modificar suas páginas localmente. Por isso, é muito importante capturar esses dados. É muito difícil corrigir problemas que você não percebe.

Depurar outras métricas

A consulta anterior mostra os resultados da métrica CLS, mas a mesma técnica pode ser usada para gerar relatórios sobre os destinos de depuração de LCP e INP. Basta substituir a cláusula where pela métrica relevante para depurar:

WHERE metric_name = 'INP'
WHERE metric_name = 'LCP'

Consulte novamente Depurar a performance no campo para instruções sobre como coletar e enviar informações de depuração para cada uma das métricas das Core Web Vitals.

Visualizar

Pode ser difícil conseguir insights apenas analisando os resultados da consulta. Por exemplo, a consulta a seguir lista os valores diários de percentis de 75 para LCP no conjunto de dados.

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  event_date,
  metric_name,
  APPROX_QUANTILES(ROUND(metric_value, 2), 100)[OFFSET(75)] AS p75
FROM
  (
    SELECT
      event_date,
      metric_name,
      ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value'), 3) AS metric_value
    FROM web_vitals_events
    WHERE
      metric_name = 'LCP'
  )
GROUP BY
  1, 2
ORDER BY event_date

Com esses resultados de consulta, é difícil identificar tendências ou outliers apenas analisando os dados.

Resultados da consulta de valor da métrica diária

Nesses casos, a visualização dos dados pode ajudar a gerar insights mais rapidamente.

Visualizar os resultados da consulta no Looker Studio

O BigQuery oferece uma maneira rápida de visualizar os resultados de consultas usando o Data Studio. O Looker Studio é uma ferramenta de visualização de dados e painéis que pode ser usada sem custos financeiros. Para visualizar os resultados da consulta, após a execução na interface do BigQuery, clique no botão Explore Data e selecione Explore with Looker Studio.

Opção "Explorar com o Looker Studio" no BigQuery

Isso vai criar um link direto do BigQuery para o Looker Studio na visualização de exploração. Nessa página, você pode selecionar os campos que quer visualizar, escolher tipos de gráfico, configurar filtros e criar gráficos ad hoc para uma análise visual mais rápida. Com base nos resultados da consulta anterior, é possível criar este gráfico de linhas para conferir a tendência dos valores de LCP ao longo do tempo:

Gráfico de linhas de valores diários de LCP no Looker Studio

Com essa vinculação direta entre o BigQuery e o Looker Studio, você pode criar gráficos rápidos usando qualquer uma das suas consultas e fazer análises visuais. No entanto, se você quiser fazer outras análises, é possível conferir vários gráficos em um painel interativo para ter uma visão mais holística ou analisar os dados em mais detalhes. Ter um painel prático significa que você não precisa escrever consultas e gerar gráficos manualmente sempre que quiser analisar as métricas.

Você pode criar um painel no Looker Studio usando o conector nativo do BigQuery. Para fazer isso, acesse datastudio.google.com, crie uma nova fonte de dados, selecione o conector do BigQuery e escolha o conjunto de dados com que você quer trabalhar:

Como usar o conector nativo do BigQuery no Looker Studio

Materializar dados das Métricas da Web

Ao criar painéis de dados de eventos de Métricas da Web, como descrito anteriormente, não é eficiente usar o conjunto de dados de exportação do Google Analytics 4 diretamente. Devido à estrutura dos dados do GA4 e ao pré-processamento necessário para as métricas das Métricas da Web, partes da consulta acabam sendo executadas várias vezes. Isso cria dois problemas: o desempenho do painel e os custos do BigQuery.

Você pode usar o modo sandbox do BigQuery sem custos financeiros. Com o nível de uso sem custos financeiros do BigQuery, o primeiro 1 TB de dados de consulta processados por mês é sem custo financeiro. Para os métodos de análise discutidos nesta postagem, a menos que você esteja usando um conjunto de dados significativamente grande ou consultando com frequência o conjunto de dados, é possível permanecer dentro desse limite sem custo financeiro todos os meses. No entanto, se você tem um site de alto tráfego e quer monitorar regularmente diferentes métricas usando um painel interativo rápido, sugerimos o pré-processamento e a materialização dos seus dados das Métricas da Web, além do uso dos recursos de eficiência do BigQuery, como particionamento, clustering e armazenamento em cache.

O script abaixo vai pré-processar seus dados do BigQuery (tabela de origem) e criar uma tabela materializada (tabela de destino). Ao usar essa consulta para seu próprio conjunto de dados, também é possível definir um período para a tabela de origem, para diminuir a quantidade de dados processados.

# Materialize Web Vitals metrics from GA4 event export data

# Replace target table name
CREATE OR REPLACE TABLE bigquery_project_id.ga4_demo_dev.web_vitals_summary
  PARTITION BY DATE(event_timestamp)
  CLUSTER BY metric_name
AS
SELECT
  ga_session_id,
  IF(
    EXISTS(SELECT 1 FROM UNNEST(events) AS e WHERE e.event_name = 'first_visit'),
    'New user',
    'Returning user') AS user_type,
  IF(
    (SELECT MAX(session_engaged) FROM UNNEST(events)) > 0, 'Engaged', 'Not engaged')
    AS session_engagement,
  evt.* EXCEPT (session_engaged, event_name),
  event_name AS metric_name,
  FORMAT_TIMESTAMP('%Y%m%d', event_timestamp) AS event_date
FROM
  (
    SELECT
      ga_session_id,
      ARRAY_AGG(custom_event) AS events
    FROM
      (
        SELECT
          ga_session_id,
          STRUCT(
            country,
            device_category,
            device_os,
            traffic_medium,
            traffic_name,
            traffic_source,
            page_path,
            debug_target,
            event_timestamp,
            event_name,
            metric_id,
            IF(event_name = 'LCP', metric_value / 1000, metric_value) AS metric_value,
            user_pseudo_id,
            session_engaged,
            session_revenue) AS custom_event
        FROM
          (
            SELECT
              (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
                AS ga_session_id,
              (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
                AS metric_id,
              ANY_VALUE(device.category) AS device_category,
              ANY_VALUE(device.operating_system) AS device_os,
              ANY_VALUE(traffic_source.medium) AS traffic_medium,
              ANY_VALUE(traffic_source.name) AS traffic_name,
              ANY_VALUE(traffic_source.source) AS traffic_source,
              ANY_VALUE(
                REGEXP_SUBSTR(
                  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location'),
                  r'^[^?]+')) AS page_path,
              ANY_VALUE(
                (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'debug_target'))
                AS debug_target,
              ANY_VALUE(user_pseudo_id) AS user_pseudo_id,
              ANY_VALUE(geo.country) AS country,
              ANY_VALUE(event_name) AS event_name,
              SUM(ecommerce.purchase_revenue) AS session_revenue,
              MAX(
                (
                  SELECT
                    COALESCE(
                      value.double_value, value.int_value, CAST(value.string_value AS NUMERIC))
                  FROM UNNEST(event_params)
                  WHERE key = 'session_engaged'
                )) AS session_engaged,
              TIMESTAMP_MICROS(MAX(event_timestamp)) AS event_timestamp,
              MAX(
                (
                  SELECT COALESCE(value.double_value, value.int_value)
                  FROM UNNEST(event_params)
                  WHERE key = 'metric_value'
                )) AS metric_value,
            FROM
              # Replace source table name
              `bigquery_project_id.analytics_XXXXX.events_*`
            WHERE
              event_name IN ('LCP', 'INP', 'CLS', 'first_visit', 'purchase')
            GROUP BY
              1, 2
          )
      )
    WHERE
      ga_session_id IS NOT NULL
    GROUP BY ga_session_id
  )
CROSS JOIN UNNEST(events) AS evt
WHERE evt.event_name NOT IN ('first_visit', 'purchase');

Esse conjunto de dados materializados oferece várias vantagens:

  • A estrutura dos dados é simplificada e mais fácil de consultar.
  • Ele retém apenas os eventos das Métricas da Web do conjunto de dados original do GA4.
  • As informações sobre o ID da sessão, tipo de usuário (novo x recorrente) e engajamento ficam disponíveis diretamente nas colunas.
  • A tabela é particionada por data e agrupada em cluster pelo nome da métrica. Isso geralmente reduz a quantidade de dados processados em cada consulta.
  • Como você não precisa usar caracteres curinga para consultar essa tabela, os resultados da consulta podem ser armazenados em cache por até 24 horas. Isso reduz os custos de repetir a mesma consulta.
  • Se você usar o BigQuery BI Engine, vai poder executar funções e operadores SQL otimizados nesta tabela.

É possível consultar diretamente essa tabela materializada na interface do BigQuery ou usá-la no Looker Studio com o conector do BigQuery.

Usar o conector das Métricas da Web

Desenvolvemos uma solução em pacote que cria um modelo de painel por você já que fazer isso do zero demoraria muito. Primeiro, confira se você materializou a tabela das Core Web Vitals usando a consulta anterior. Em seguida, acesse o conector das Métricas da Web do Looker Studio neste link: goo.gle/web-vitals-connector

Depois de fornecer uma autorização única, você vai ver a tela de configuração abaixo:

Tela de autorização do conector das Métricas da Web

Forneça o ID da tabela materializada do BigQuery (ou seja, a tabela de destino) e o ID do projeto de faturamento do BigQuery. Depois de clicar em "Conectar", o Looker Studio vai criar um novo painel com modelo e associar os dados a ele. Você pode editar, modificar e compartilhar o painel como quiser. Se você criar um painel uma vez, não vai precisar acessar o link do conector novamente, a menos que queira criar vários painéis usando diferentes conjuntos de dados.

Ao navegar no painel, você encontra as tendências diárias das Métricas da Web e algumas informações sobre o uso do site, como usuários e sessões, na guia Resumo.

Na guia Análise de usuários, é possível selecionar uma métrica e conferir um detalhamento do percentil e da contagem de usuários de acordo com diferentes métricas de uso e de negócios.

A guia Análise de caminho da página ajuda a identificar as áreas problemáticas do site. Aqui, você pode escolher uma métrica para conferir a visão geral. Mas você também vê o mapa de dispersão de todos os caminhos da página com o valor do percentil no eixo y e a contagem de registros no eixo x. O mapa de dispersão pode ajudar a identificar páginas com valores de métrica menores do que o esperado. Depois de selecionar as páginas usando o gráfico de dispersão da tabela Caminho da página, você pode detalhar ainda mais a área problemática visualizando a tabela Destino de depuração.

A guia Análise de receita é um exemplo de como monitorar as métricas comerciais e de desempenho no mesmo lugar. Essa seção mostra todas as sessões em que o usuário fez uma compra. Você pode comparar a receita gerada com a experiência do usuário durante uma sessão específica .

Uso avançado

À medida que você se familiarizar com o conjunto de dados, poderá editar o painel e adicionar seus próprios gráficos para uma análise mais rica e direcionada. Para tornar o painel mais útil, siga estas etapas:

  • Configure a consulta programada no BigQuery para receber dados atualizados. A consulta de materialização que executamos anteriormente só faz um snapshot dos seus dados naquele momento. Se você quiser manter o painel atualizado com novos dados, execute uma consulta programada que será executada todos os dias e anexe a tabela materializada com os novos dados.
  • Agrupe dados próprios (por exemplo, CRM) para insights de negócios. Na tabela materializada, é possível adicionar user_id como uma coluna separada. Isso vai permitir que você combine seus dados próprios. Se os dados próprios ainda não estiverem no BigQuery, você pode carregar os dados ou usar uma fonte de dados federada.
  • Informe a versão do site ou app como um parâmetro nos dados enviados ao Google Analytics e adicione como uma coluna na tabela materializada. Em seguida, adicione esses dados de versão como uma dimensão nos gráficos para facilitar a visualização das mudanças de versão que afetam a performance.
  • Se você espera um uso significativamente intenso do conjunto de dados por consulta direta ou painel, tente usar a versão paga do BigQuery BI Engine.

Resumo

Esta postagem abordou os conceitos básicos de como usar o Google Analytics 4 e o BigQuery para medir e depurar a performance com dados de usuários reais coletados no campo. Também explicamos como criar relatórios e painéis automatizados usando o Looker Studio e o Conector das Métricas da Web para facilitar a visualização dos dados.

Algumas conclusões importantes desta postagem:

  • Medir a performance com dados reais do usuário é fundamental para entender, depurar e otimizar seu site.
  • Você pode ter insights mais detalhados quando as métricas de performance e de negócios estão no mesmo sistema. O Google Analytics e o BigQuery tornam isso possível.
  • A exportação do BigQuery de dados brutos do Google Analytics oferece um potencial ilimitado para análises detalhadas e personalizadas usando uma linguagem de consulta que você provavelmente já conhece.
  • O Google tem várias APIs e ferramentas de visualização, como o Looker Studio, que permitem que você crie seus relatórios exatamente como quiser.