Cierra la brecha entre la IU de Google Analytics y BigQuery Export

Minhaz Kazi, Developer Advocate, Google Analytics, abril de 2023

"Pero ¿por qué los números no coinciden con la IU?"

Si trabajaste con los datos de exportación de eventos de BigQuery para tu propiedad GA4, sin duda ya hiciste esta pregunta en algún momento. O peor, alguien más te lo preguntó. Y, mientras tratas de responder, es probable que te hayan hecho la temible pregunta de seguimiento:

"¿Y dónde dice eso?".

En esta publicación, trataremos de aclarar ambas.

Antes de entrar en detalles sobre cómo varían los números, es importante comprender el propósito previsto de los datos de exportación de eventos de BigQuery. Los usuarios de Google Analytics envían los datos recopilados a Google Analytics a través de uno de estos métodos: la etiqueta de Google, Google Tag Manager, el Protocolo de medición, los SDK y la Importación de datos. Según la configuración de la propiedad de Google Analytics, Google Analytics agrega un valor significativo a los datos recopilados antes de que lleguen a las plataformas de informes estándares, incluidos los informes estándares, las Exploraciones y la API de datos. Estas incorporaciones de valor pueden incluir la inclusión de los indicadores de Google, el modelado, la atribución de tráfico, la predicción, etcétera.

El objetivo de las plataformas de informes estándar es proporcionar el máximo valor a los usuarios de Google Analytics con la menor fricción. Sin embargo, sabemos que, en el amplio espectro de usuarios, es posible que algunos quieran complementar las adiciones de valor de Google Analytics o incluso hacer algo completamente personalizado. Para estos usuarios, la exportación de eventos de BigQuery es el punto de partida previsto. La exportación de eventos de BigQuery tendrá datos recopilados, que se envían desde el cliente o la app a Google Analytics. La exportación de eventos de BigQuery no contendrá datos detallados sobre la mayoría de las incorporaciones de valor mencionadas anteriormente.

Por lo tanto, para una gran cantidad de casos de uso, no se espera que las plataformas de informes estándar y los datos de exportación de BigQuery se puedan conciliar cuando se trata de estas partes de adición de valor. Si hay coherencia interna en ambos y coinciden con lo que estás recopilando, no debes preocuparte.

Ahora, veamos algunos de los motivos específicos de las diferencias y exploremos formas de mitigarlas cuando sea posible. Esta publicación se centra solo en la exportación de eventos diarios de BigQuery y no en la exportación de flujos.

Muestreo

Para comparar de forma precisa tus datos de BigQuery Export con los informes estándares, los informes de la API de datos o los informes de exploración, confirma que no se basen en datos de muestra. Muestreo de datos en GA4 ofrece más detalles y formas de abordar el muestreo.

Usuarios activos

Si registras todos los usuarios que registraron, al menos, un evento en tu propiedad GA4, obtendrás la métrica Total de usuarios. Aunque la métrica Total de usuarios está disponible en Exploraciones en la IU de GA4, la métrica del usuario principal que se usa para generar informes en GA4 es Usuarios activos. En la IU de GA4 y en los informes, si solo se menciona la palabra Usuarios, por lo general, se refiere a Usuarios activos. Por lo tanto, cuando calcules el recuento de usuarios a partir de los datos de BigQuery, deberás filtrar y conservar solo los usuarios activos para que los números sean comparables con la IU de Google Analytics. El método de cálculo también variará según la Identidad de los informes seleccionada.

Implementación técnica

En los datos de exportación de eventos de BigQuery, si cuentas la cantidad de IDs de usuarios distintos, obtendrás el recuento de Total de usuarios. A continuación, se incluye una consulta de muestra que muestra el total de usuarios y los usuarios nuevos según 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 seleccionar solo los usuarios activos, limita tu consulta a eventos en los que is_active_user es 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++

Google Analytics usa el algoritmo HyperLogLog++ (HLL++) para estimar la cardinalidad de métricas comunes, incluidos los usuarios activos y las sesiones. Esto significa que cuando ves el recuento único de estas métricas en la IU o a través de la API, son una aproximación con cierta precisión. En BigQuery, dado que tienes acceso a los datos detallados, puedes calcular la cardinalidad exacta para estas métricas. Por lo tanto, las métricas pueden variar en un porcentaje pequeño. Con un intervalo de confianza del 95%, la precisión puede ser de ±1.63% para el recuento de sesiones. Los niveles de precisión variarán para las diferentes métricas y cambiarán según los intervalos de confianza. Consulta Bocetos de HLL++ a fin de conocer los niveles de precisión en diferentes intervalos de confianza para los diferentes parámetros de precisión de HLL++.

Implementación técnica

Consulta Aproximación de recuento único en Google Analytics para comprender cómo se implementó HLL++ en Google Analytics y cómo puedes replicar la funcionalidad mediante consultas de BigQuery.

Demora en la recopilación de datos

Las tablas de exportación diaria se crean después de que Google Analytics recopila todos los eventos del día. Las tablas diarias se pueden actualizar hasta 72 horas después de la fecha de la tabla con eventos que tienen marca de tiempo con la fecha de la tabla. Lee detalles sobre esto y consulta ejemplos. Esto es más problemático si tu implementación del SDK de Firebase o del Protocolo de medición envía eventos sin conexión o retrasados. Según el momento en el que se actualicen la plataforma de informes estándar y BigQuery dentro de esas 72 horas, es posible que veas diferencias entre ellas. Para esta implementación, se deben realizar comparaciones con datos de más de 72 horas.

Informes de alta cardinalidad

Supongamos que estás viendo un informe a través de informes estándares o la API de datos. El informe muestra una gran cantidad de datos y tiene dimensiones con alta cardinalidad. Las dimensiones de alta cardinalidad pueden hacer que el informe supere el límite de cardinalidad de la tabla subyacente. Cuando esto suceda, Google Analytics agrupará los valores menos frecuentes y los etiquetará como (other).

Con un ejemplo simplificado y a pequeña escala, si el límite de cardinalidad de la tabla subyacente es de 10 filas, esto es lo que puedes esperar:

Como puedes ver, la cantidad total de eventos no se modifica. Sin embargo, los valores menos frecuentes se agrupan y no puedes volver a agregar la tabla en función de ninguna dimensión (p.ej., no puedes tomar la tabla conjunta y derivar el recuento total de eventos para una ciudad específica con alta precisión). El ejemplo se vuelve más profundo si filtras los datos agregados en función de cualquiera de las dimensiones.

Esta agrupación de la fila (other) se realiza solo en el módulo de informes y en la API de datos cuando el informe supera el límite de cardinalidad. Si haces cálculos desde BigQuery, siempre obtendrás los datos de verdad fundamental, es decir, las filas más detalladas. Obtén más información sobre la fila (other) y las prácticas recomendadas para evitarla.

Indicadores de Google

Activar indicadores de Google en tu propiedad GA4 tiene varios beneficios, como anular la duplicación de usuarios en diferentes plataformas y dispositivos. Si no recopilas IDs de usuario ni activas los indicadores de Google y una persona ve tu sitio web en tres navegadores web diferentes, Google Analytics atribuye esa actividad a tres usuarios diferentes, y BigQuery Export tendrá tres user_pseudo_id diferentes. En cambio, con los indicadores de Google activados y la persona accedió a su única Cuenta de Google en los tres navegadores, Google Analytics atribuye esa actividad a un usuario y refleja ese recuento en las plataformas de informes estándares. Sin embargo, BigQuery seguirá mostrando tres user_pseudo_id independientes porque la información de los indicadores de Google no está disponible en la exportación de BigQuery. Por lo tanto, es probable que los informes con datos de los indicadores de Google tengan un recuento de usuarios menor en comparación con BigQuery Export.

La mejor manera de disminuir este efecto es implementar User-ID en tu propiedad GA4 junto con activar los indicadores de Google. Esto garantizará que la anulación de duplicación se produzca primero en función de user_id. Para los usuarios que accedieron a sus cuentas, el campo user_id se propagará en BigQuery y se puede usar con fines de cálculo. Sin embargo, en el caso de los usuarios que no accedieron (es decir, sesiones sin user_id), se seguirán usando los indicadores de Google para anular la duplicación.

Además, ten en cuenta que es posible que algunos informes en las plataformas de informes estándar tengan umbrales aplicados y que no muestren ciertos datos. Por lo general, la mayor parte de la información que puede estar sujeta a umbrales no está disponible en la exportación de BigQuery.

Modo de consentimiento y datos modelados

El modo de consentimiento en sitios web y apps para dispositivos móviles te permite comunicar a Google el estado de consentimiento de las cookies o del identificador de la app de tus usuarios. Cuando los visitantes rechazan el consentimiento, GA4 llena los vacíos de la recopilación de datos con el modelado de eventos clave y el modelado de comportamiento. Ninguno de los datos modelados está disponible en la exportación de eventos de BigQuery. Cuando se implementa el modo de consentimiento, el conjunto de datos de BigQuery contendrá pings sin cookies recopilados por Google Analytics y cada sesión tendrá un user_pseudo_id diferente. Debido al modelado, habrá diferencias entre las plataformas de informes estándar y los datos detallados en BigQuery. Por ejemplo, debido al modelado de comportamiento, es posible que veas menos usuarios activos en comparación con BigQuery Export, ya que el modelado podría intentar predecir las sesiones múltiples de usuarios individuales sin consentimiento.

Una vez más, para reducir el efecto de esto, debes implementar User-ID en tu propiedad GA4. user_id y las dimensiones personalizadas se exportan a BigQuery sin importar el estado de consentimiento de los usuarios.

Datos de atribución de tráfico

En BigQuery, los datos de atribución de tráfico están disponibles a nivel del usuario (primera visita) y del evento. Estos son los datos recopilados. Sin embargo, debido a que Google Analytics implementa su propio modelo de atribución a nivel de sesión, esa información no está directamente disponible en BigQuery Export ni se puede calcular con una precisión total con los datos disponibles. Según tu caso de uso, puedes considerar unir el conjunto de datos de BigQuery con cualquier dato de origen relevante y crear tu propio modelo de atribución. En el futuro, es posible que los datos recopilados adicionales para la atribución de tráfico estén disponibles a través de la exportación de eventos de BigQuery.

Errores de cálculo comunes

• Método de cálculo: Cuando calcules diferentes métricas en BigQuery, asegúrate de usar la metodología correcta. Por ejemplo:
  • El método estándar para contar sesiones de las propiedades Google Analytics 4 es contar las combinaciones únicas de user_pseudo_id/user_id y ga_session_id, independientemente del período. En Universal Analytics, las sesiones se restablecerían a la medianoche. Si sigues el modelo de UA, calculas las sesiones para cada día y las sumas para obtener un recuento total de sesiones, contarías dos veces las sesiones que abarcan varios días.
  • Según la identidad de los informes seleccionada, se deberá actualizar el método de cálculo del recuento de usuarios.
• Alcance de la dimensión y la métrica: Asegúrate de que tus cálculos usen el alcance a nivel de usuario, sesión, elemento o evento correcto.
• Zona horaria: En la exportación de BigQuery, event_date es para la zona horaria de los informes, mientras que event_timestamp es una marca de tiempo UTC en microsegundos. Por lo tanto, si una consulta usa event_timestamp en una consulta, deberá ajustarse a la zona horaria de los informes correcta cuando se compare con los números de la IU.
• Filtros de datos y límites de exportación: Si configuraste el filtrado de datos para la exportación de eventos de BigQuery o el volumen de exportación de eventos diarios excedió el límite, los datos de exportación de eventos de BigQuery no coincidirán con los de las plataformas de informes estándares.

CON todo eso, hay un poco de UNNEST en esta publicación. Esperamos que puedas SELECCIONAR las soluciones adecuadas para tu proyecto DISTINCT DESDE las pautas que se indican aquí. Si tienes preguntas, usa JOIN al servidor de Discord de GA WHERE que las consultas son más bienvenidas.