La communauté open-source a produit plusieurs packages dbt pour GA4 avec une adoption significative. Cette note décrit l’approche et les compromis de chaque package, notamment les cas où une construction sur mesure est plus appropriée.
Velir/dbt-ga4 : le standard communautaire
Le package Velir/dbt-ga4 est l’option dominante avec 380+ étoiles GitHub et un développement actif. Son créateur l’a positionné comme un foyer pour la connaissance communautaire autour de GA4 et BigQuery — une accumulation organique de patterns qui fonctionnent réellement en production.
L’architecture suit un flux propre de la base aux marts :
models/├── base/│ ├── base__ga4__events│ ├── stg_ga4__events│ ├── stg_ga4__event_page_view│ └── stg_ga4__sessions_traffic_sources└── marts/ └── core/ ├── dim_ga4__sessions └── fct_ga4__sessionsTrois patterns de Velir méritent d’être empruntés indépendamment du fait que vous utilisiez le package lui-même :
Extraction de paramètres pilotée par variables. Plutôt que de coder en dur les paramètres d’événements à extraire, Velir utilise des variables dbt_project.yml :
vars: ga4: page_view_custom_parameters: - name: "clean_event" value_type: "string_value"Cela rend le package configurable sans modifier le code — un bon pattern pour tout projet GA4 où des propriétés différentes trackent des paramètres personnalisés différents.
Lookback incrémental statique. Au lieu de requêter dynamiquement la table de destination pour la dernière date (ce qui force BigQuery à scanner toutes les tables shardées), Velir retraite les N derniers jours à chaque exécution. Consultez Modèle de base shardé vers partitionné GA4 pour comprendre pourquoi les lookbacks dynamiques sont dangereux avec les tables date-shardées.
Clés de session composites. Les sessions sont identifiées par user_pseudo_id + ga_session_id, pas ga_session_id seul. Consultez Construction de la clé de session GA4 pour la mécanique des collisions.
La limitation principale : Les marts au grain session de Velir ne sont pas partitionnés. À des volumes de trafic élevés, cela rend les requêtes en aval coûteuses. La documentation recommande explicitement de désactiver certains modèles pour les sites à fort trafic — ce qui est un signe que vous pourriez avoir besoin d’une approche sur mesure.
Fivetran/dbt_ga4_export
Le package Fivetran cible les équipes qui ingèrent des données GA4 via Fivetran plutôt que l’export BigQuery natif. Il prend en charge plusieurs entrepôts (Snowflake, Redshift, Databricks, BigQuery) et gère la normalisation du schéma qu’applique Fivetran lors de l’ingestion.
Avec seulement 7 modèles au total, il est intentionnellement minimal. Fivetran aplatit event_params lors de l’ingestion, donc la complexité de l’UNNEST qui domine le travail sur l’export BigQuery brut est déjà gérée en amont. Si vous utilisez Fivetran, c’est probablement votre point de départ.
L’inconvénient : vous êtes lié aux décisions d’aplatissement de Fivetran. Les paramètres d’événements personnalisés que Fivetran ne connaît pas peuvent ne pas surfacer correctement.
Le package de MO Data Consulting
Ce package adopte une approche distinctive : il aplatit dynamiquement tous les event_params en colonnes individuelles au moment de la compilation. Jinja itère sur votre liste de paramètres d’événements et génère un SELECT avec une colonne par paramètre. Pas d’extraction par sous-requête, pas d’UNNEST au moment de la requête.
Pratique pour l’exploration lorsque vous voulez une vue tabulaire propre de tous les paramètres. Mais cela peut créer des tables trop larges — et si votre liste de paramètres change, vous devez recompiler plutôt qu’ajuster simplement votre logique d’extraction.
admindio/simple_ga4_dbt
Le plus opinioné des quatre. Conçu pour l’efficacité des coûts et la simplicité, avec des modèles d’attribution intégrés et des dépendances minimales de packages. Fonctionne bien pour les équipes qui veulent quelque chose d’opérationnel rapidement sans personnalisation extensive.
Le « simple » dans le nom est exact — il échange la configurabilité contre la facilité de mise en place.
Quand construire sur mesure
Les quatre packages s’orientent vers des marts au grain session : une ligne par session avec des métriques agrégées. C’est le pattern de reporting GA4 le plus courant, et il est logique d’en faire le choix par défaut.
La limitation se révèle lorsque vous avez besoin d’une analyse au niveau événement avec le contexte de session — analyse de funnel, questions de séquence d’événements, calculs de temps-jusqu’à-conversion. Les tables au grain session nécessitent de rejoindre les événements bruts pour ces requêtes, ajoutant de la complexité et des risques de cohérence.
L’architecture alternative — une table intermédiaire enrichie au grain événement où chaque ligne porte le contexte de session via des fonctions fenêtre — n’est bien servie par aucun des packages existants. Aucun d’eux ne construit ce type de table d’événements enrichis comme sortie principale.
Vous pourriez également vouloir construire sur mesure si :
- Votre propriété GA4 tracke de nombreux événements personnalisés avec des noms de paramètres non standard
- Vous avez besoin d’une logique de regroupement des canaux spécifique qui diffère des valeurs par défaut de Google
- Votre tracking e-commerce nécessite des modèles au grain item
- Vous souhaitez un contrôle plus étroit sur les événements matérialisés et à quel coût
Les packages sont des références utiles pour comprendre les patterns — notamment la stratégie incrémentale de Velir et la construction de la clé de session — même lorsque le package lui-même n’est pas utilisé directement.