Google Analytics propose plusieurs options d'exportation vers BigQuery, chacune conçue pour répondre à différents besoins en termes de cas d'usages et de budgets. Ces options d'exports diffèrent selon deux axes : la fraîcheur des données et la complétude des données. Aujourd'hui, nous allons vous présenter l'ensemble des options et les cas d'usage les plus adaptés pour chacun, ainsi que des conseils d'utilisations.

‍

Dans cet article, vous trouverez :

• Comparaison des différentes options d'exports
• Les conditions d'adoption de ce système
• Conseils pour votre onboarding ou votre transition à l'export GA
• Conclusion

‍

‍

Il existe aujourd'hui 3 options pour exporter les données de Google Analytics vers BigQuery : 

• L'export daily standard, accessible à tous. 
• L'export intraday, qui contient les données de navigation sur votre site quasiment en temps réel.
• L'export fresh, réservé aux propriétés 360, est une version améliorée de l'export standard avec un engagement de régularité et des données intraday.

Voici un tableau récapitulatif des opportunités de chaque option : 

‍

Pour les clients GA 360, un Service Level Agreement (SLA) prévu pour le quatrième trimestre de 2024, l'export Fresh offrira une livraison fiable et constante des données en début de journée.

Essentiellement, et si votre organisation répond aux conditions d'adoptions, vous pouvez retenir de ce tableau qu'avec GA360 vous utiliserez l'export Fresh, et dans le cas contraire l'export Daily.

‍

‍

Avant de passer à l'adoption de l'export Fresh, il est important d'évaluer si votre entreprise est un bon candidat pour cette option d'exportation. Cette fonctionnalité répond à 3 critères définis : 

• Coûts : Vous avez une architecture BigQuery en place et GA360, et vous avez anticipé les coûts de stockage et de requêtage de cette table. Nous avons un outil pour vous aider à calculer le coût de stockage : Calculette pour les coûts de stockage BigQuery avec Google Analytics
• Vitesse : Vous avez des enjeux d'analyse quotidien sur les performances de la veille, et l'imprévisibilité du timing de l'export standard vous bloquent parfois.
• Garantie : Avec l'arrivée d'un SLA en Q4 2024, l'export Fresh daily pour les propriétés 360 sera garanti versus l'export standard qui ne le sera pas.

Dans tous les cas, nous vous recommandons l'ouverture d'un export dans BigQuery, afin que vous puissiez vous familiariser avec cette fonctionnalité indispensable. Nous avons écrit un article en 2021 sur le potentiel de cette fonctionnalité : Pourquoi exporter ses données Google Analytics 4 vers Google BigQuery ?

En résumé, GA propose à tous ces utilisateurs l'équivalent d'un export API brut, sans contrainte et sans développement, dans votre architecture propriétaire. Cela signifie que vous pourrez garder ces données pour toujours, les envoyer dans votre Cloud de prédilection, les utiliser pour plus d'une centaine de cas d'usage, tout ça pour un coût de stockage faible.

‍

Avant toute chose, que vous soyez en phase d'onboarding ou de run avec l'export GA, voici notre meilleur conseil sur cette partie : 

• Les exports ne sont pas des tables de requête pour faire de la BI, ce sont des tables d'export. Google fournit dans les faits un raccourci vers leur API en format table SQL.
• La meilleure preuve technique est que les tables sont shardées avec des tableaux nestés ( optimisées pour les mouvements) et non partitionnées et labellisées ( optimisées pour le requêtage et la BI ). Avant usage, une phase de préparation des données est nécessaire.

Pour les reconnaître, voici respectivement les logos des tables simples, des tables "shardées" et des tables partitionnées :

‍

‍

‍

Si vous commencer à utiliser l'export GA, fresh ou daily : 

• Notre premier tips, et le plus important, est de faire attention à ne pas connecter l'export brut à votre outil de BI, sous peine d'avoir moins de flexibilité que l'API GA4, et de devoir payer des coûts de requêtes élevés. Nous vous recommandons de préparer les données à l'aide d'un outil comme Dataform ou dbt pour sublimer l'export avant de l'utiliser. Cela vous permettra de définir un data model qui vous est propre, et de capitaliser sur la puissance de Google Analytics comme moteur de collecte et de pré-processing de vos données 1st party.

• Notre second conseil est d'utiliser un système automatique pour déclencher votre pipeline de processing dès que les données sont disponibles. Pour ça, vous pouvez passer par les logs GCP et un Pub/Sub en utilisant une log query similaire à celle ci (pensez à remplacer les champs masqués par vos valeurs et à inverser "events" et "events_fresh" pour votre cas) :
  

resource.type="bigquery_resource"
protoPayload.methodName="jobservice.jobcompleted"
protoPayload.serviceData.jobCompletedEvent.eventName="load_job_completed"
protoPayload.authenticationInfo.principalEmail="firebase-measurement@system.gserviceaccount.com"
protoPayload.serviceData.jobCompletedEvent.job.jobConfiguration.load.destinationTable.projectId:"~~"
protoPayload.serviceData.jobCompletedEvent.job.jobConfiguration.load.destinationTable.datasetId:"~~"
protoPayload.serviceData.jobCompletedEvent.job.jobConfiguration.load.destinationTable.tableId:"events"
protoPayload.serviceData.jobCompletedEvent.job.jobStatus.state="DONE"
NOT protoPayload.serviceData.jobCompletedEvent.job.jobConfiguration.load.destinationTable.tableId:"events_fresh"

‍

Si vous utilisez l'export intraday : 

Comme indiqué dans le tableau récapitulatif, le processing de GA est très léger sur cet export. Ne vous conseillons de l'utiliser (après un processing léger de votre côté également) seulement pour des analyses de niveau évènements. Par exemple, avoir le nombre de pages vues par catégorie, ou le nombre de produits vus, etc. 

‍

Si vous utilisez déjà l'export daily : 

Vous effectuez déjà des traitements pour aplatir les paramètres d'événements, optimiser les tables, enrichir les donnés, faire de la modélisation et plus, voici deux tips pour votre transition :

• Assurez-vous de ne pas charger les données plusieurs fois dans vos table BI. Entre l'export quotidien de la daily, les exports à l'heure de la fresh et l'export final de la fresh, les paramètres d'événements sont rarement dans le même ordre, ce qui fausse les clés d'unicité que vous utilisez et ne permet pas de fonctionner en format incrémental. Le plus simple est de fonctionner en format incrémental à l'heure sur une journée, et d'effectuer un écrasement des 3 derniers jours une fois l'export fresh daily disponible pour profiter de la meilleure qualité de données disponibles tout au long de la journée.

• Pour garantir une transition en douceur vers l'export Fresh, il est recommandé de le faire fonctionner en parallèle avec l'exportation quotidienne, car ils fonctionnent sur des pipelines différents et peuvent montrer de légères divergences en raison de l'amélioration du filtrage et du traitement des données. La double implémentation assure qu'il n'y a pas de risque de perturbation avant la transition complète.

‍

Chaque export correspond à des cas d'usages ou des priorités différentes. Dans l'ensemble, l'export Fresh est la meilleure option selon les deux axes fraîcheur / complétude des données. L'export Daily correspond aux utilisateurs de GA pour lesquels la version 360 et la régularité de l'export ne sont pas des priorités. En fin, l'export intraday est pour tous, recommandé seulement pour des cas d'usage précis d'analyse.

‍