Aller au contenu principal
Dernière mise à jour le

Concepts de connecteur de données brutes Google analytique

Le connecteur Google Analytics Raw Data vous permet d'ingérer des données brutes au niveau des événements depuis Google Analytics 4 (GA4) en utilisant Databricks Lakeflow Connect et Google BigQuery.

Comment fonctionne l'ingestion GA4 ?​

Tout d'abord, vous devez exporter vos données GA4 vers BigQuery à l'aide des APIs ou des interfaces utilisateur fournies par Google. Ensuite, Databricks consomme les données de BigQuery en utilisant les APIs suivantes :

  • L'API BigQuery pour les opérations de métadonnées (par exemple, pour lister les tables et les schémas).
  • L'API BigQuery Storage pour l'ingestion de données
  • L'API Cloud Resource Manager pour l'exploration de schémas

Modèle de données de connecteur​

Le connecteur GA4 peut ingérer les tables suivantes à partir d'une propriété GA4 donnée :

  • events
  • events_intraday
  • users
  • pseudonymous_users

Pour chaque jour où les données arrivent dans GA4, une table partitionnée par date est automatiquement créée dans BigQuery. Le nom de la table BigQuery a le format <table_name>_YYYYMMDD (par exemple, events_20241024).

Lors de chaque mise à jour du pipeline Lakeflow Connect, le connecteur ingère automatiquement toutes les nouvelles tables depuis la dernière mise à jour. Il ingère également toutes les nouvelles lignes dans les tables existantes pendant 72 heures maximum.

Notions de base du connecteur​

  • Lors de l'exécution initiale du pipeline, le connecteur ingère toutes les données que vous avez exportées vers BigQuery pour les tables que vous avez sélectionnées.
  • Lors des exécutions de pipeline ultérieures, le connecteur ingère les lignes nouvellement insérées, avec les mises en garde décrites dans cet article.
  • Les mises à jour et les suppressions ne sont pas ingérées.
  • Le chargement initial récupère les données pour toutes les dates qui sont présentes dans votre projet GA4/BigQuery.
  • Le connecteur suppose que chaque ligne est unique. Databricks ne peut garantir un comportement correct en cas de doublons inattendus.

Mettre à jour les fenêtres et les plannings​

GA4 pourrait continuer à mettre à jour les tables existantes jusqu'à 72 heures après leur création (par exemple, pour tenir compte des événements arrivant en retard ou des ajustements d'attribution). Pendant la fenêtre de 72 heures, le connecteur réingère les lignes mises à jour à chaque exécution de pipeline. Une fois la fenêtre de 72 heures fermée, le connecteur cesse de suivre les mises à jour pour les tables et leurs données sont considérées comme définitives. Le connecteur ne détecte pas automatiquement les modifications apportées à une table après la fenêtre de 72 heures (par exemple, si GA4 retraite les données historiques).

Vous devez exécuter votre pipeline Lakeflow Connect au moins toutes les 72 heures, mais Databricks recommande d'exécuter le pipeline quotidiennement. La synchronisation moins fréquente augmente le risque que le connecteur doive récupérer les données à nouveau.

Databricks recommande également de maintenir la fenêtre de time travel par default de BigQuery de 7 jours. Cela peut aider à l'efficacité de l'ingestion.

Modèles de données au niveau de la table​

tables d'événements et d'événements intraday​

Pour la table events et la table events_intraday, une ligne dans Databricks correspond à une ligne dans BigQuery.

Pour la table events_intraday, il n'y a aucune garantie que les données existeront pour une date particulière après que les données pour la même date sont disponibles dans la table events. Ceci parce que la table events_intraday est uniquement destinée à une utilisation provisoire jusqu'à ce que la table events soit prête pour cette journée.

table des utilisateurs​

Pour l'ingestion à partir de la table users, le connecteur s'appuie sur user_id comme clé primaire et sur last_updated_date comme clé de curseur. En conséquence, il n'ingère qu'une seule ligne par ID utilisateur de chaque table users : l'entrée avec le last_updated_date le plus grand.

Pour conserver plus d’une ligne par ID utilisateur dans la table de destination, définissez le mode SCD sur le type 2 dans la configuration de la table.

table pseudonymous_users​

Pour ingérer à partir de la table pseudonymous_users, le connecteur s'appuie sur les pseudo_user_id et stream_id comme clés primaires. Il utilise le last_updated_date comme clé de curseur. Par conséquent, il n'ingère qu'une seule ligne par ID de pseudo-utilisateur de chaque table pseudonymous_users : l'entrée avec le last_updated_date le plus grand.

Pour conserver plus d’une ligne par ID utilisateur dans la table de destination, définissez le mode SCD sur le type 2 dans la configuration de la table.

Sur cette page