Combler le fossé entre l'interface utilisateur 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'UI ?"

Si vous avez 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, c'est quelqu'un d'autre vous a posé cette question. Et en essayant d'y répondre, on vous a probablement posé la redoutable question de suivi:

"Où est-ce que ça signifie ?"

Avec cet article, nous allons tenter de mettre en lumière 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. Les utilisateurs Google Analytics envoient les données collectées à GA via l'une des méthodes de collecte suivantes : la balise Google, Google Tag Manager, le protocole de mesure, les SDK ou l'importation de données. En fonction des paramètres de la propriété GA, Google Analytics ajoute une valeur importante aux données collectées avant qu'elles n'atteignent les surfaces de reporting standards, y compris les rapports standards, Explorations et l'API Data. Ces valeurs peuvent inclure l'inclusion de signaux Google, de la modélisation, de l'attribution du trafic, des prédictions, etc.

Les surfaces de reporting standards visent à fournir la valeur maximale aux utilisateurs GA avec un minimum de friction. Toutefois, nous sommes conscients que pour un large éventail d'utilisateurs, certains voudront compléter les valeurs ajoutées par Google Analytics, voire personnaliser quelque chose. Pour ces utilisateurs, l'exportation d'événements BigQuery est le point de départ idéal. L'exportation des événements BigQuery comportera des données collectées, qui sont envoyées du client ou de l'application à Google Analytics. L'exportation des événements BigQuery ne contiendra pas de données précises sur la plupart des ajouts de valeurs mentionnés ci-dessus.

Ainsi, pour un grand nombre de cas d'utilisation, les surfaces de reporting standards et les données d'exportation BigQuery ne devraient pas être rapprochées en ce qui concerne ces éléments d'ajout de valeur. S'il existe une cohérence interne entre les deux et qu'ils correspondent à ce que vous collectez, vous devriez être prêt.

Penchons-nous maintenant sur les raisons spécifiques de ces différences et découvrons comment les atténuer si possible. Cet article ne porte que sur l'exportation d'événements quotidiens BigQuery, et non sur l'exportation en flux continu.

Échantillonnage

Pour comparer précisément vos données BigQuery Export avec les rapports standards, les rapports de l'API Data ou les rapports d'exploration, vérifiez qu'ils ne sont pas basés sur des échantillons de données. L'échantillonnage de données dans GA4 fournit des informations supplémentaires et des moyens de remédier à l'échantillonnage.

Utilisateurs actifs

Si vous comptabilisez tous les utilisateurs qui ont enregistré au moins un événement dans votre propriété GA4, vous obtenez la métrique Nombre total d'utilisateurs. Bien que la métrique Nombre total d'utilisateurs soit disponible dans Explorations dans l'interface utilisateur de GA4, la principale métrique utilisateur utilisée pour la création de rapports dans GA4 est Utilisateurs actifs. Dans l'interface utilisateur de GA4 et dans les rapports, si seul la catégorie Utilisateurs est mentionnée, cela fait généralement référence aux utilisateurs actifs. Ainsi, lorsque vous calculerez le nombre d'utilisateurs à partir des données BigQuery, vous devrez filtrer et ne conserver que les utilisateurs actifs pour que les chiffres soient comparables à ceux affichés dans l'UI GA. La méthode de calcul varie également 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 comptabilisez le nombre d'ID utilisateur distincts, vous obtenez le nombre total d'utilisateurs. Voici un exemple de requête qui affiche à la fois le nombre total d'utilisateurs et les 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 pour lesquels 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, y compris les sessions et les utilisateurs actifs. Par conséquent, lorsque vous affichez le nombre de métriques uniques dans l'UI ou via l'API, il s'agit d'une approximation avec une certaine précision. Dans BigQuery, comme vous avez accès à des données précises, vous pouvez calculer la cardinalité exacte de ces métriques. Les métriques peuvent donc varier légèrement. À 95% d'intervalle de confiance, la précision peut être de ±1,63% pour le nombre de sessions. Les niveaux de précision varient selon les métriques et changent en fonction des intervalles de confiance. Consultez les croquis HLL++ pour connaître les niveaux de précision à différents intervalles de confiance pour les 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++ est implémenté dans Google Analytics et comment répliquer cette fonctionnalité à l'aide de requêtes BigQuery.

Délai de collecte des données

Les tables d'exportation quotidiennes sont créées 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 de la table. Pour en savoir plus et voir des exemples, cliquez ici. Ce problème est davantage problématique si votre implémentation du SDK Firebase ou du protocole de mesure envoie des événements hors connexion ou retardés. Selon la date à laquelle la surface de création de rapports standard et BigQuery sont mis à jour au cours de ces 72 heures, vous pouvez constater des différences entre les deux. Pour une telle implémentation, des comparaisons doivent être effectuées sur les données datant de plus de 72 heures.

Rapports à cardinalité élevée

Supposons que vous consultiez un rapport par le biais de rapports standards ou de l'API Data. Le rapport affiche une grande quantité de données et comporte des dimensions à cardinalité élevée. Des dimensions à cardinalité élevée peuvent entraîner le dépassement de la limite de cardinalité du tableau sous-jacent. Dans ce cas, Google Analytics regroupe les valeurs moins fréquentes et les ajoute au libellé (other).

À l'aide d'un exemple simplifié à petite échelle, si la limite de cardinalité de la table sous-jacente 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, les valeurs moins fréquentes sont regroupées et vous ne pouvez pas réagréger le tableau en fonction d'une dimension (par exemple, vous ne pouvez pas prendre la table agrégée et obtenir le nombre total d'événements pour une ville spécifique avec une grande précision). L'exemple devient plus approfondi si vous filtrez les données agrégées en fonction de l'une des dimensions.

Ce regroupement de la ligne "(other)" n'est effectué que dans le module de reporting et dans l'API Data lorsque le rapport dépasse la limite de cardinalité. Si vous effectuez vos calculs à partir de BigQuery, vous obtiendrez toujours des données de vérité terrain, c'est-à-dire les lignes les plus précises. En savoir plus sur la ligne "(other)" et les bonnes pratiques pour l'éviter

Signaux Google

L'activation des signaux Google sur votre propriété GA4 présente plusieurs avantages, y compris la déduplication des utilisateurs sur les différentes plates-formes et appareils. En supposant que le User-ID et les signaux Google ne soient pas implémentés, si une personne consulte votre site Web sur trois navigateurs Web différents, Google Analytics comptabilisera trois utilisateurs différents et BigQuery Export aura trois user_pseudo_id distincts. Toutefois, une fois les signaux Google activés et la personne connectée à son seul compte Google dans les trois navigateurs, Google Analytics duplique un utilisateur et affiche ce nombre dans les rapports standards. Cependant, BigQuery affichera toujours trois valeurs user_pseudo_id distinctes. Aucun signal Google n'est disponible dans l'exportation BigQuery. Par conséquent, les rapports contenant des données de signaux Google présenteront probablement moins d'utilisateurs que BigQuery Export.

Le meilleur moyen de réduire cet effet consiste à implémenter les User-ID dans votre propriété GA4 en activant les signaux Google. Ainsi, la déduplication sera effectuée en premier en fonction de user_id. Pour les utilisateurs connectés, le champ 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 tout de même utilisés pour la déduplication.

Notez également que certains rapports des surfaces de reporting standards peuvent être appliqués à un seuil et ne pas renvoyer certaines données. La plupart des informations pouvant être soumises à un seuil ne sont généralement pas disponibles 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 à Google l'état du consentement de vos utilisateurs concernant les cookies ou les identifiants d'applications. Lorsque les visiteurs refusent de donner leur consentement, GA4 comble les lacunes de la collecte des données à l'aide de la modélisation des conversions et de la modélisation du comportement. Aucune des données modélisées n'est disponible dans l'exportation des événements BigQuery. Lorsque le mode Consentement est implémenté, l'ensemble de données BigQuery contient des pings sans cookie collectés par GA et chaque session a un user_pseudo_id différent. En raison de la modélisation, il y aura des différences entre les surfaces de reporting standards et les données précises de BigQuery. Par exemple, en raison de la modélisation du comportement, il est possible que vous constatiez un nombre d'utilisateurs actifs moins élevé qu'avec l'exportation BigQuery. En effet, la modélisation peut tenter de prédire les différentes sessions provenant d'utilisateurs individuels n'ayant pas donné leur consentement.

Là encore, pour réduire l'effet de ce phénomène, vous devez implémenter le User-ID dans votre propriété GA4. user_id et les dimensions personnalisées sont exportées vers BigQuery, quel que soit l'état de consentement de vos utilisateurs.

Données d'attribution du trafic

Dans BigQuery, les données d'attribution du trafic sont disponibles au niveau de l'utilisateur (première visite) et de l'événement. Il s'agit des données collectées. Toutefois, comme Google Analytics implémente son propre modèle d'attribution au niveau de la session, ces informations ne sont ni directement disponibles dans BigQuery Export, ni calculées avec une précision totale à partir des données disponibles. En fonction de votre cas d'utilisation, vous pouvez envisager de joindre l'ensemble de données BigQuery aux données first party pertinentes et de créer votre propre modèle d'attribution. À l'avenir, d'autres données collectées pour l'attribution du trafic pourront être disponibles via l'exportation des é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 méthodologie appropriée. Exemple :
  • La méthode standard de comptabilisation des sessions pour les propriétés Google Analytics 4 consiste à comptabiliser les combinaisons uniques de user_pseudo_id/user_id et ga_session_id quelle que soit la période. Dans Universal Analytics, les sessions étaient réinitialisées à minuit. Si vous suivez le modèle UA, que vous calculez les sessions chaque jour et que vous les additionnez pour obtenir un nombre total de sessions, vous comptabiliseriez deux fois les sessions qui s'étendent sur plusieurs jours.
  • En fonction de l'identité de reporting sélectionnée, la méthode de calcul du nombre d'utilisateurs devra être mise à jour.
• Champ d'application des dimensions et des métriques: assurez-vous que vos calculs utilisent le bon champ d'application au niveau de l'utilisateur, de la session, de l'élément ou de l'événement.
• Fuseau horaire: dans l'exportation BigQuery, event_date correspond au fuseau horaire du rapport, tandis que event_timestamp est un horodatage UTC exprimé en microsecondes. Idéalement, si vous utilisez event_timestamp dans une requête, vous devez l'ajuster en fonction du fuseau horaire du rapport en cas de comparaison avec les numéros d'interface utilisateur.
• Filtrage des données et limites d'exportation: si vous avez configuré le filtrage des données pour exporter vos événements BigQuery ou si votre volume d'exportation d'événements quotidien dépasse la limite, les données d'exportation des événements BigQuery ne correspondront pas aux surfaces de reporting standards.

Avec tout cela, il y a quelque chose à dire sur UNNEST dans cet article. J'espère que vous pourrez SÉLECTIONNER les bonnes solutions pour votre projet DISTINCT FROM les directives ici. Si vous avez des questions, effectuez une jointure sur le serveur Discord GA WHERE les requêtes sont les bienvenues.