Combler le fossé entre l'interface utilisateur de Google Analytics et l'exportation BigQuery

Minhaz Kazi, Developers Advocate, Google Analytics – Avril 2023

"Mais pourquoi les chiffres ne correspondent-ils pas à ceux de l'interface utilisateur ?"

Si vous avez déjà utilisé les données d'exportation d'événements BigQuery pour votre propriété GA4, vous avez certainement posé cette question à un moment donné. Pire encore, quelqu'un d'autre vous a demandé ça. En essayant d'y répondre, on vous a probablement demandé Question suivante redoutable:

"Et où dit-on cela ?"

Avec ce post, nous allons essayer de faire la lumière sur ces deux aspects.

Avant d'examiner en détail la variation des chiffres, il est important de comprendre l'objectif des données d'exportation d'événements BigQuery. Utilisateurs Google Analytics envoient les données collectées à GA via l'une des méthodes de collecte : Google Tag, Google Tag Manager, le protocole de mesure, les SDK et l'importation de données. En fonction des paramètres de la propriété GA, Google Analytics apporte une valeur significative qui viennent s'ajouter aux données collectées avant qu'elles n'apparaissent dans les rapports standards. y compris les rapports standards, Explorations et l'API Data. Ces valeurs peuvent inclure les signaux Google, la modélisation, le trafic (attribution, prédiction, etc.).

Les surfaces de reporting standards visent à offrir aux utilisateurs GA une valeur maximale le moins de friction possible. Cependant, nous sommes conscients que pour un large éventail d'utilisateurs, certains voudront peut-être compléter les valeurs ajoutées par Google Analytics ou même quelque chose de entièrement personnalisé. Pour ces utilisateurs, l'exportation d'événements BigQuery le point de départ souhaité. Les exportations d'événements BigQuery contiennent des données collectées, qui est envoyé à Google Analytics depuis le client ou l'application. Exportation d'événements BigQuery ne contiendra pas de données détaillées sur la plupart des valeurs ajoutées mentionnées ci-dessus.

Ainsi, pour un grand nombre de cas d'utilisation, les surfaces de reporting standards et Les données BigQuery Export ne devraient pas être réconciliables avec ces de valeur ajoutée. S'il existe une cohérence interne dans les deux et qu'ils correspondent avec ce que vous collectez, vous devriez pouvoir y accéder.

Examinons maintenant quelques-unes des raisons spécifiques qui peuvent expliquer ces différences des moyens de les atténuer lorsque cela est possible. Cet article se concentre Exportation des événements quotidiens uniquement, et non l'exportation en flux continu.

Échantillonnage

Pour comparer précisément vos données BigQuery Export avec des rapports standards, l'outil les rapports de l'API ou les rapports d'exploration confirment qu'ils ne sont pas basés sur des données échantillonnées. La section Échantillonnage de données dans GA4 fournit plus de détails et des moyens de gérer l'échantillonnage.

Utilisateurs actifs

Si vous comptabilisez tous les utilisateurs qui ont enregistré au moins un événement sur votre GA4 vous obtenez la métrique Nombre total d'utilisateurs. Bien que le nombre total d'utilisateurs est disponible dans Explorations dans l'UI GA4, la principale métrique utilisateur utilisée pour dans GA4 correspond aux Utilisateurs actifs. Dans l'interface utilisateur de GA4 et dans les rapports, si uniquement Utilisateurs et qui fait généralement référence aux utilisateurs actifs. Lors du calcul du nombre d'utilisateurs à partir des données BigQuery, vous devez filtrer et ne conserver que les utilisateurs actifs pour que les chiffres soient comparables à ceux de l'interface utilisateur GA. La méthode de calcul varient en fonction de l'identité pour le reporting que vous avez sélectionnée.

Implémentation technique

Dans les données d'exportation d'événements BigQuery, si vous comptez le nombre d'ID utilisateur distincts, vous obtiendra le nombre total d'utilisateurs (Total Users). Voici un exemple de requête affichant à la fois Utilisateurs et nouveaux utilisateurs en fonction de 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;

Pour ne sélectionner que des utilisateurs actifs, limitez votre requête aux événements où is_active_user est 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 utilise l'algorithme HyperLogLog++ (HLL++) pour estimer la cardinalité des métriques courantes, comme les utilisateurs actifs et les sessions. Cela signifie que lorsque vous affichez le nombre unique de ces métriques dans l'interface utilisateur ou via l'API, il s'agit avec une certaine précision. Dans BigQuery, puisque vous avez accès des données détaillées, vous pouvez calculer la cardinalité exacte de ces métriques. Donc les métriques peuvent varier légèrement. À un intervalle de confiance de 95 %, la précision peut être de ±1,63% pour le nombre de sessions. Les niveaux de précision varient pour différentes métriques et changent en fonction des intervalles de confiance. Voir Dessins HLL++ pour les niveaux de précision à différents intervalles de confiance pour différents paramètres de précision de HLL++.

Implémentation technique

Consultez la section Approximation du nombre unique dans Google Analytics pour comprendre comment HLL++ dans Google Analytics et comment reproduire cette fonctionnalité à l'aide de requêtes BigQuery.

Délai de collecte des données

Les tableaux d'exportation quotidiens sont créés une fois que GA a collecté tous les événements de la journée. Les tables quotidiennes peuvent être mises à jour jusqu'à 72 heures après la date de la table avec des événements horodatés avec la date du tableau. Lire les détails et consulter des exemples. C'est plus un problème si l'implémentation du SDK Firebase ou du protocole de mesure envoie en mode hors connexion, les événements retardés. En fonction du moment où la surface de reporting standard et BigQuery mises à jour dans ces 72 heures, vous constaterez peut-être des différences entre elles. Pour une telle implémentation, vous devez comparer des données plus anciennes plus de 72 heures.

Rapports à cardinalité élevée

Supposons que vous consultiez un rapport via des rapports standards ou l'API Data. Le rapport affiche une grande quantité de données et comporte des dimensions avec cardinalité. Des dimensions à cardinalité élevée peuvent entraîner un dépassement de la valeur limite de cardinalité de la table sous-jacente. Dans ce cas, Google Analytics regroupera les valeurs moins fréquentes et les étiquettera comme (other).

À l'aide d'un exemple simplifié à petite échelle, si la limite de cardinalité de la tableau sous-jacent est de 10 lignes, voici ce à quoi vous pouvez vous attendre:

Comme vous pouvez le constater, le nombre total d'événements reste inchangé. Toutefois, moins de les valeurs les plus fréquentes sont regroupées, et il n'est pas possible de réagréger le tableau pour n'importe quelle dimension (par exemple, vous ne pouvez pas utiliser le tableau cumulé le nombre d'événements pour une ville spécifique avec une précision élevée). Dans cet exemple, nous obtenons si vous filtrez les données globales en fonction de n'importe quelle dimension.

Ce regroupement de la ligne "(other)" se produit uniquement dans le module de reporting et dans le API Data lorsque le rapport dépasse la limite de cardinalité. Si vous effectuez votre dans BigQuery, vous obtenez toujours des données de vérité terrain, les lignes les plus précises. En savoir plus sur la ligne "(other)" et les bonnes pratiques concernant comment l'éviter.

Signaux Google

L'activation des signaux Google sur votre propriété GA4 présente plusieurs avantages : de dédupliquer les utilisateurs sur les plates-formes et les appareils. Si vous ne collectez pas les informations ou activer les signaux Google, et lorsqu'une personne consulte votre site Web navigateurs Web différents, Google Analytics attribue cette activité à trois d'utilisateurs différents, et BigQuery Export possède trois user_pseudo_id distincts. En revanche, lorsque les signaux Google sont activés et que l'utilisateur est connecté à son compte Google dans les trois navigateurs, les attributs Google Analytics l'activité à un utilisateur et reflète ce nombre dans les surfaces de reporting standards. Cependant, BigQuery affiche toujours trois valeurs user_pseudo_id distinctes, car Les informations sur les signaux Google ne sont pas disponibles dans l'exportation BigQuery. Ainsi, les rapports contenant les données des signaux Google auront probablement moins d'utilisateurs que vers BigQuery Export.

Le meilleur moyen d'atténuer cet effet est d'implémenter le User-ID dans votre compte GA4. et activer les signaux Google. Vous aurez ainsi l'assurance la déduplication s'effectue d'abord en fonction de user_id. Pour les utilisateurs connectés : user_id sera renseigné dans BigQuery et pourra être utilisé à des fins de calcul. Toutefois, pour les utilisateurs qui ne sont pas connectés (c'est-à-dire les sessions sans user_id), Les signaux Google seront toujours utilisés pour la déduplication.

Notez également que certains rapports des surfaces standards peuvent avoir appliqués des seuils et ne renvoient pas certaines données. La plupart des informations qui peuvent être soumis au seuil n'est généralement pas disponible dans l'exportation BigQuery.

Mode Consentement et données modélisées

Le mode Consentement sur les sites Web et les applications mobiles vous permet de communiquer l'état du consentement à Google concernant les cookies ou les identifiants d'applications. Lorsque les visiteurs refusent le consentement, GA4 comble les lacunes de la collecte des données grâce à la modélisation des événements clés et au comportement la modélisation. Aucune des données modélisées n'est disponible dans l'exportation d'événements BigQuery. Lorsque le mode Consentement est implémenté, l'ensemble de données BigQuery contient des pings sans cookie collectées par GA, et chaque session aura un user_pseudo_id différent. Motif : il y aura des différences entre les surfaces de reporting standards et des données précises dans BigQuery. Par exemple, grâce à la modélisation du comportement, peut voir moins d'utilisateurs actifs par rapport à BigQuery Export la modélisation peut tenter de prédire les multiples sessions d'utilisateurs sans consentement utilisateurs.

Encore une fois, pour réduire l'impact de ce changement, vous devez implémenter le User-ID dans votre compte GA4. . user_id et les dimensions personnalisées sont exportées vers BigQuery, l'état de consentement de vos utilisateurs.

Données d'attribution du trafic

Dans BigQuery, les données d'attribution du trafic sont disponibles lors de la première visite de l'utilisateur. au niveau de l'événement. Ce sont les données collectées. Cependant, puisque Google Analytics utilise son propre modèle d'attribution au niveau de la session, ces informations sont ni directement disponibles dans BigQuery Export, ni calculées la précision des données avec les données disponibles. Selon votre cas d'utilisation, vous pouvez envisager associer l'ensemble de données BigQuery à toutes les données first party pertinentes votre propre modèle d'attribution. À l'avenir, d'autres données collectées pour le trafic l'attribution peut être disponible via l'exportation d'événements BigQuery.

Erreurs de calcul courantes

• Méthode de calcul:lorsque vous calculez différentes métriques dans BigQuery, assurez-vous d'utiliser la bonne méthodologie. Exemple :
  • Méthode standard de comptabilisation des sessions pour Google Analytics 4 des propriétés compte les combinaisons uniques user_pseudo_id/user_id et ga_session_id quel que soit le période. Dans Universal Analytics, les sessions sont réinitialisées à minuit. Si vous suivez le modèle UA, calculez les sessions pour chaque jour et ajoutez-les pour obtenir le nombre total de sessions, comptez deux fois qui s'étendent sur plusieurs jours.
  • Selon l'identité pour le reporting sélectionnée, le nombre d'utilisateurs méthode de calcul doit être mise à jour.
• Champ d'application des dimensions et des métriques: assurez-vous que vos calculs utilisent le au niveau de l'utilisateur, de la session, de l'élément ou de l'événement.
• Fuseau horaire: dans BigQuery Export, event_date correspond à l'heure du rapport. tandis que event_timestamp est un code temporel UTC exprimé en microsecondes. Donc Idéalement, si vous utilisez event_timestamp dans une requête, vous devez l'ajuster le fuseau horaire des rapports lors de la comparaison avec les chiffres de l'interface utilisateur.
• Filtrage des données et limites d'exportation: si vous avez configuré le filtrage des données pour l'exportation d'événements BigQuery ou le volume quotidien d'exportations d'événements a dépassé les données d'exportation d'événements BigQuery ne correspondront pas aux valeurs surfaces de reporting.

AVEC tout cela, il y a un peu à UNNEST dans ce post. J’espère que vous pouvez SELECT les bonnes solutions pour votre projet DISTINCT À PARTIR des directives ici. Si vous Si vous avez des questions, REJOINDRE le serveur Discord GA OÙ les requêtes sont les plus bienvenues !