Pourquoi ?

Si vous utilisez Google Analytics 4 pour collecter des données de vos sites web ou applications mobiles, il est judicieux de stocker une copie de ces données dans vos propres systèmes pour diverses raisons:

• Prendre le contrôle de vos données. Que se passera-t-il si vous désirez quitter Google Analytics ou si le produit disparaît ?
• Analyser toutes vos données marketing de manière holistique, comme par exemple réconcilier vos efforts et les performances que vous voyez dans GA.
• Pousser les cas d’utilisation au-delà de ce que l’interface propose.

Dans ce cas, il y a plusieurs façons de récupérer des données de GA4 dans un entrepôt ou un lac de données : intégrer la donnée brute, ou de la donnée agrégée de l’API. Voyons ensemble laquelle correspond à vos besoins ainsi que les méthodes disponibles pour les réintégrer.

La donnée brute des événements

La donnée brute contient les événements tels quels ingérés par GA4. Ils contiennent assez peu d’enrichissement que Google pourrait opérer dans GA4. La granularité du modèle est “une ligne par événement”. C’est cette donnée que l’on voudra ingérer si on cherche à réconcilier les actions d’un utilisateur avec son parcours d’achat et son lien avec la marque dans une “vue 360”.

Avantages :

• Le connecteur natif est facile à configurer et à utiliser.
• Il est intégré directement dans GA4, ce qui signifie que les données sont automatiquement transférées vers BigQuery en quelques clics.
• Il est gratuit pour les clients de GA4.
• C’est la seule manière de mettre en place des cas d’utilisation complexes qui nécessitent plusieurs actions consécutives du même utilisateur sur une période (par exemple).

Inconvénients :

• Les données sont stockées dans BigQuery, ce qui peut coûter cher si vous avez beaucoup de données.
• Vous ne pouvez pas personnaliser les données qui sont importées. Vous devrez effectuer les calculs des métriques vous-mêmes.
• Aucune modélisation de données. Les données des utilisateurs non consentis ne comportent aucun identifiant de session ou utilisateur.

Utiliser le connecteur natif GA4 - BigQuery

Le moyen le plus simple et le plus courant de récupérer des données de Google Analytics 4 dans un entrepôt de données est d'utiliser le connecteur natif GA4-BigQuery. Ce connecteur importe automatiquement les données de GA4 dans BigQuery, où vous pouvez les interroger et les analyser à l'aide de SQL.

On pourra configurer le connecteur de 2 manières:

• En streaming temps réel: dès qu’un événement est ingéré dans GA4, il est transmis à BQ
• En batch: chaque jour, on reçoit la liste des événements de la veille

Le connecteur se configure directement dans votre propriété GA4

Récupérer la donnée dans un autre entrepôt de données

Il arrive souvent que votre entreprise possède déjà un entrepôt de données dans lequel vous désirez centraliser la donnée de GA4. La première chose à savoir est que vous ne pouvez pas vous passer de BigQuery, que vous devrez alors utiliser comme une plateforme de passation de données. Le processus pour récupérer cette donnée dans un autre entrepôt sera alors différent selon les cas.

Dans Snowflake

Snowflake possède un connecteur natif pour aspirer la donnée de BigQuery dans son propre stockage, puis pour légèrement transformer les données pour les rendre adaptables au modèle de Snowflake. Pour plus d’information, je vous invite à lire mon article précédent sur la création d’une vue 360 dans Snowflake.

Dans un autre entrepôt (Databricks, Redshift, etc.)

Une excellente solution pour transférer la donnée dans un lac de données comme Databricks ou Redshift sera d’exporter chaque jour la table de données de la veille dans Google Cloud Storage. Il est alors généralement assez simple de copier des données dans votre stockage respectif (GCS vers S3 ou GCS vers Blob Storage). Tous les grands Cloud intègrent des services pour copier des données externes vers le cloud en question.

Exemple no-code de réplication de données de GCS vers S3 via AWS DataSync.

Comment en tirer des métriques et des statistiques ?

Une fois les cas d’usage définis, on utilisera un outil comme dbt ou Dataform pour transformer les données via des pipelines SQL et simplifier la vie des analystes.

dbt, par exemple, est l’outil le plus populaire du marché pour effectuer ce travail, et il existe déjà des paquets préconçus pour transformer la donnée de GA4 dans BigQuery. Veuillez noter que dbt est disponible aussi pour Snowflake, Databricks et Postgre, mais qu’il n’existe pas de code “pré-fait” à l’heure où j’écris ces lignes.

Les données agrégées de GA4

Il est également possible de récupérer via l’API de GA4 des données agrégées de type “Rapport”. La granularité sera modulable en fonction de nos cas d’usage. Cela peut être vu comme une méthode plus rapide et efficace pour récupérer vos données de rapports simples. Par contre, les cas d’usage seront très limités. On ne saura jamais quel utilisateur a fait quoi avec cette méthode.

On pourrait par exemple récupérer, par jour, le nombre de sessions et d’utilisateurs ayant visité votre site par canal d’acquisition, source, et medium. Vous pouvez vous référer à la liste des métriques et des dimensions pour identifier les cas d’usage possibles.

Avantages :

• Vous pouvez personnaliser le modèle des données qui sont récupérées.
• Les données modélisées par les algorithmes de Google sont incluses. Si l’interface affiche 100, l’API renvoie 100. Cela facilite le QA et la confiance des équipes métier.
• Time to value assez rapide pour des cas d’usage simples.

Inconvénients :

• Certaines limitations de cas d’usage sont à prévoir. En effet, l’API a (entre autres) des limites de nombre de dimensions.
• Si votre propriété est très sujette à l’échantillonnage, alors les totaux des lignes renvoyées par l’API peuvent différer des totaux affichés dans l’interface (jusqu’à 5%).
• L’API a des limites de quota qui pourraient vous limiter pour des cas d’usage complexes.

Pour récupérer de la donnée de l’API de GA4, on aura 2 grandes options:

Utiliser des scripts “personnalisés”

Cela nécessite des compétences de développement pour extraire les données de GA4 via l'API et les charger dans votre entrepôt de données. Cela peut être fait en utilisant des bibliothèques de développement comme celles disponibles pour Python et R qui existent sur internet, maintenues par Google, et qui sont généralement simples à utiliser pour un programmeur aguerri. Attention cependant, car comme tout projet technique, cela demandera de la maintenance au fil des mises à jour de l’API de GA4.

Nous ne conseillons pas à nos clients de développer leurs propres scripts, à part dans des cas très spécifiques.

Connecteurs externes tiers

Il existe également des connecteurs externes tiers, tels que Supermetrics, Airbyte ou Fivetran, qui peuvent être utilisés pour récupérer des données de GA4 dans un entrepôt de données. Ces connecteurs sont généralement payants et peuvent nécessiter une configuration supplémentaire.

L’avantage est que le time to value est extrêmement rapide si on ne prend pas en compte le temps pour souscrire un contrat. Si votre entreprise est parfois un peu statique dans l’intégration de nouvelles solutions tierces, cela pourrait prendre plusieurs semaines ou mois.

Nous conseillons toujours d’utiliser un intégrateur de ce type lorsque c’est possible pour nos clients. En effet, c’est bien plus sécuritaire pour la pérennité de votre projet sur le long terme.

Conclusion

Quel paradigme choisir ? Le choix de la méthode dépendra de vos besoins spécifiques et de vos compétences en matière de développement. Il faudra d’abord vous poser la question de vos cas d’utilisation. En réalité, sûrement un peu des deux. À l’heure où j’écris ces lignes, les rapports de type “acquisition” sont souvent plus faciles à intégrer via l’API, car les règles d’attribution de Google et la modélisation sont parfois complexes à reconstruire en SQL. Il est par contre beaucoup plus agréable de travailler avec la donnée brute pour tous les cas de connaissance client.

Nous accompagnons chaque jour nos clients pour définir leurs besoins d’intégration et de centralisation de données marketing; n’hésitez pas à nous contacter si vous avez des questions.