Cómo acortar las diferencias entre los datos de la UI de Google Analytics y los exportados a BigQuery

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

"¿Por qué las cifras no coinciden con las de la UI?"

Si ya has trabajado con datos de exportación de eventos de BigQuery en tu propiedad de GA4, en algún momento te habrás planteado esta pregunta. O, lo que es peor, alguien te la habrá planteado y puede que, mientras tratabas de responder, te haya hecho la siguiente temida pregunta adicional:

"¿Y dónde lo dice?"

En este artículo, trataremos de responder a ambas preguntas.

Antes de pasar a analizar las diferencias entre las cifras, se debe comprender la finalidad de los datos de exportación de eventos de BigQuery. Los usuarios de Google Analytics envían los datos recogidos a GA a través de uno de los métodos de recogida: etiqueta de Google, Google Tag Manager, Measurement Protocol, SDKs e Importación de datos. Según la configuración de la propiedad de GA, Google Analytics añade un valor considerable a los datos recogidos antes de que lleguen a las superficies de informes estándar, como los informes estándar, Exploraciones y la API Data. Estas adiciones de valor pueden incluir Google signals, modelización, atribución de tráfico, predicción, etc.

El objetivo de las superficies de informes estándar es ofrecer el máximo valor a los usuarios de GA con la menor fricción. Sin embargo, entendemos que, entre el amplio abanico de usuarios, puede que haya quienes quieran complementar las adiciones de valor con Google Analytics o incluso hacer algo completamente personalizado. Para estos usuarios, la exportación de eventos de BigQuery es el punto de partida idóneo. La exportación de eventos de BigQuery incluirá datos recogidos, que se envían desde el cliente o la aplicación a Google Analytics. La exportación de eventos de BigQuery no contendrá datos granulares sobre la mayoría de las adiciones de valor mencionadas antes.

Por lo tanto, en un gran número de casos prácticos, no se espera que las superficies de informes estándar y los datos de BigQuery Export sean conciliables en lo que respecta a estas partes de adición de valor. Si hay coherencia interna en ambos casos y coinciden con lo que estás recogiendo, te recomendamos que sigas adelante.

Veamos ahora algunas de las razones concretas por las que surgen diferencias y analicemos formas de mitigarlas cuando sea posible. Este artículo se centra únicamente en la exportación de eventos diarios de BigQuery y no en la exportación de flujo.

Muestreo

Para comparar de forma precisa tus datos de BigQuery Export con informes estándar, informes de la API Data o informes de Exploraciones, confirma que no se basan en datos de muestra. En el artículo sobre el muestreo de datos en GA4 encontrarás más detalles y formas de utilizar el muestreo.

Usuarios activos

Si haces un recuento de todos los usuarios que han registrado al menos un evento en tu propiedad de GA4, obtienes la métrica Total de usuarios. Aunque esta métrica está disponible en la sección Exploraciones de la UI de GA4, la principal métrica de usuario que se usa en los informes de GA4 es Usuarios activos. En la UI de GA4 y en los informes, si solo se menciona Usuarios, suele referirse a Usuarios activos. Por lo tanto, para calcular el número de usuarios a partir de los datos de BigQuery, tendrás que filtrar y mantener solo a los usuarios activos para que las cifras sean similares a las de la UI de GA. El método de cálculo variará también según la identidad para los informes que hayas seleccionado.

Implementación técnica

En los datos de exportación de eventos de BigQuery, si haces un recuento del número de IDs de usuario diferentes, verás la métrica Total de usuarios. Esta es una consulta de ejemplo que se basa en user_pseudo_id para mostrar las métricas Total de usuarios y Usuarios nuevos:

-- 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 usuarios activos, limita la consulta a los eventos donde is_active_user sea 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 habituales, como Usuarios activos y Sesiones. Eso significa que, cuando ves los recuentos únicos de estas métricas en la UI o a través de la API, son una aproximación con una precisión determinada. Como tienes acceso a los datos granulares, puedes calcular la cardinalidad exacta de las métricas en BigQuery. Por lo tanto, las métricas pueden variar en un pequeño porcentaje. Con un intervalo de confianza del 95 %, la precisión del recuento de sesiones podría ser del ±1,63 %. Los niveles de precisión varían según la métrica y cambian según los intervalos de confianza. Consulta los esquemas de HLL++ para conocer los niveles de precisión con diferentes intervalos de confianza en los diferentes parámetros de precisión de HLL++.

Implementación técnica

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

Retraso en la recogida de datos

Las tablas de exportación diaria se crean después de que GA haya recogido todos los eventos del día. Se pueden añadir eventos con marcas de tiempo a la tabla hasta 72 horas después de la fecha de creación de la tabla. Consulta más información al respecto y algunos ejemplos. Esto llegaría a ser un mayor problema si tu SDK de Firebase o tu implementación de Measurement Protocol envían eventos offline o retrasados. Dependiendo del momento en el que la superficie de informes estándar y BigQuery se actualicen en ese plazo de 72 horas, podrás ver diferencias entre ellas. Para hacer dicha implementación, se deben comparar datos de hace más de 72 horas.

Informes de alta cardinalidad

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

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

Como puedes ver, el número total de eventos no cambia. Sin embargo, los valores menos frecuentes se agrupan y no puedes volver a agregar la tabla en función de ninguna dimensión (por ejemplo, no puedes tomar la tabla de datos agregados y obtener el recuento total de eventos de una ciudad específica con gran precisión). El ejemplo se hace más exhaustivo si filtras los datos agregados en función de alguna de las dimensiones.

Esta agrupación de la fila (other) solo se produce en el módulo de informes y en la API Data cuando el informe supera el límite de cardinalidad. Si haces los cálculos desde BigQuery, siempre obtendrás los datos reales: las filas más granulares. Consulta más información sobre la fila (other) y las prácticas recomendadas para evitarla.

Google signals

Activar Google signals en tu propiedad de GA4 ofrece algunas ventajas, como la anulación de duplicados de usuarios en diferentes plataformas y dispositivos. Si no se han implementado ni User-ID ni Google signals y una persona visualiza tu sitio web en tres navegadores web diferentes, Google Analytics lo contará como tres usuarios diferentes y los datos de exportación de BigQuery tendrán tres user_pseudo_id independientes. Pero si Google signals está activado y la persona ha iniciado sesión en su cuenta de Google en los tres navegadores, Google Analytics duplicará a un usuario y mostrará el recuento en las superficies de informes estándar. Sin embargo, BigQuery seguirá mostrando tres user_pseudo_id independientes. No hay información de Google signals disponible en BigQuery Export. Por lo tanto, lo más probable es que los informes con datos de Google signals tengan un recuento de usuarios menor en comparación con BigQuery Export.

La mejor forma de minimizar este efecto es implementar User-IDs en tu propiedad de GA4 y activar Google signals. Así te asegurarás de que la anulación de duplicados se produzca primero en función de user_id. El campo user_id de los usuarios que hayan iniciado sesión se rellenará en BigQuery y se podrá usar para hacer cálculos. Sin embargo, con los usuarios que no hayan iniciado sesión (es decir, las sesiones sin user_id), se seguirá utilizando Google signals para la anulación de duplicados.

Además, ten en cuenta que algunos informes de las superficies de informes estándar podrían tener un umbral aplicado y no devolver determinados datos. La mayor parte de la información que pueda estar sujeta a umbrales no suele estar disponible en los datos exportados de BigQuery.

Modo de consentimiento y datos modelizados

El modo de consentimiento en sitios web y aplicaciones móviles te permite comunicar a Google el estado del consentimiento de cookies o de identificadores de tus usuarios. Cuando los visitantes deniegan su consentimiento, GA4 rellena las lagunas en la recogida de datos a través de la modelización de conversiones y la modelización de comportamiento. Los datos modelizados no se incluyen en los datos de exportación de eventos de BigQuery. Cuando el modo de consentimiento está implementado, el conjunto de datos de BigQuery contiene pings sin cookies recogidos por GA y cada sesión tiene un user_pseudo_id diferente. Debido a la modelización, habrá diferencias entre las superficies de informes estándar y los datos granulares de BigQuery. Por ejemplo, debido a la modelización de comportamiento, puede que veas menos usuarios activos en comparación con los datos exportados de BigQuery, ya que la modelización puede intentar predecir las sesiones de usuarios concretos que no hayan dado su consentimiento.

De nuevo, para minimizar este efecto, debes implementar User-ID en tu propiedad de GA4. user_id y las dimensiones personalizadas se exportan a BigQuery independientemente del estado del 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 de usuario (primera visita) y de evento. Estos son los datos recogidos. Sin embargo, como Google Analytics implementa su propio modelo de atribución a nivel de sesión, la información no está disponible directamente en BigQuery Export ni se puede calcular con total precisión con los datos disponibles. En función de tu caso práctico, puede que te venga bien combinar el conjunto de datos de BigQuery con los datos propios relevantes y crear tu propio modelo de atribución. Próximamente, puede que se incluyan datos adicionales recogidos para la atribución del tráfico en la exportación de eventos de BigQuery.

Errores de cálculo habituales

• Método de cálculo: cuando calcules distintas métricas en BigQuery, asegúrate de utilizar la metodología correcta. Por ejemplo:
  • El método estándar de recuento de sesiones para las propiedades de Google Analytics 4 cuenta las combinaciones únicas de user_pseudo_id/user_id y ga_session_id, independientemente del periodo. En Universal Analytics, las sesiones se reinician a medianoche. Si sigues el modelo de UA, calculas las sesiones de cada día y las sumas para obtener un recuento total de sesiones, estarías contando dos veces las sesiones que abarcan varios días.
  • En función de la identidad para los informes que hayas seleccionado, tendrás que actualizar el método de cálculo del número de usuarios.
• Ámbito de dimensiones y métricas: asegúrate de usar en tus cálculos el ámbito correcto a nivel de usuarios, sesiones, artículos o eventos.
• Zona horaria: en BigQuery Export, event_date indica la zona horaria de los informes, mientras que event_timestamp es una marca de tiempo UTC en microsegundos. Así que lo ideal es que, si se utiliza event_timestamp en una consulta, se ajuste a la zona horaria correcta de los informes cuando se compare con las cifras de la UI.
• Filtrado de datos y límites de exportación: si has configurado el filtrado de datos para la exportación de eventos de BigQuery o el volumen de exportación de eventos diarios ha superado el límite, los datos de exportación de eventos de BigQuery no coincidirán con los de las superficies de informes estándar.

Este artículo tiene bastante contenido, así que absórbelo poco a poco. Esperamos que puedas seleccionar las soluciones adecuadas para tu proyecto entre estas directrices. Si tienes alguna pregunta, únete al servidor de Discord de GA, donde las consultas son bienvenidas.