GA4 → BigQuery : le pipeline data, pas à pas

GA4 dans l’interface, c’est bien pour explorer. Mais dès que tu veux croiser des sources, garder l’historique au-delà des limites de rétention, ou répondre à des questions business précises, tu as besoin de la donnée brute. C’est là qu’intervient l’export BigQuery — gratuit, natif, et puissant.

Quand en as-tu vraiment besoin ?

Trois déclencheurs typiques :

• Tu butes sur les limites de rétention GA4 (2 ou 14 mois) et tu veux garder ton historique.
• Tu dois croiser GA4 avec d’autres sources (CRM, coûts média, marges, stock).
• L’interface GA4 ne sait pas répondre à ta question (échantillonnage, dimensions custom complexes, funnels sur mesure).

Si rien de tout ça ne te concerne, l’interface suffit. Sinon, le pipeline BigQuery devient vite indispensable.

1. Activer l’export

Dans GA4 → Admin → BigQuery Links. Tu choisis un projet GCP, la fréquence (daily, et streaming si besoin), et les events à exporter. Dès le lendemain, tes données arrivent dans un dataset analytics_XXXXXX.

2. Comprendre le schéma des events

Chaque ligne = un event, avec une structure imbriquée :

• event_name, event_timestamp
• event_params (tableau clé/valeur)
• user_pseudo_id, user_id
• device, geo, traffic_source…

La principale difficulté, c’est le unnesting des event_params. Une fois ce réflexe acquis, tout devient accessible.

3. Le réflexe UNNEST

Pour récupérer un paramètre, on déplie le tableau event_params et on lit la bonne key. Exemple : compter les page_view par jour avec leur page_location.

SELECT
  PARSE_DATE('%Y%m%d', event_date) AS jour,
  (SELECT value.string_value
     FROM UNNEST(event_params)
    WHERE key = 'page_location') AS page,
  COUNT(*) AS vues
FROM `projet.analytics_XXXXXX.events_*`
WHERE event_name = 'page_view'
  AND _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
GROUP BY jour, page
ORDER BY vues DESC;

Le _TABLE_SUFFIX filtre les tables quotidiennes (events_YYYYMMDD) avant lecture : c’est ce qui maîtrise les coûts. Une fois le (SELECT … FROM UNNEST(event_params) WHERE key = …) acquis, tu peux extraire n’importe quel paramètre.

4. Quelques requêtes utiles

• Sessions et utilisateurs par jour
• Funnel de conversion event par event
• Attribution first/last touch à partir de traffic_source
• Revenu par canal en croisant avec les données e-commerce

5. La modélisation

Plutôt que de réécrire les mêmes UNNEST partout, on construit des tables intermédiaires propres (sessions, utilisateurs, commandes) — idéalement versionnées et documentées. C’est ce qui transforme un dataset brut en socle analytique fiable et réutilisable. À ce stade, un outil comme dbt devient vite rentable pour orchestrer et tester ces modèles.

6. Brancher Looker Studio

Looker Studio se connecte directement à BigQuery. La bonne pratique : pointer Looker sur tes tables modélisées (pas sur l’export brut), pour des dashboards rapides et des coûts maîtrisés.

7. Coûts & bonnes pratiques

• Partitionner par date et clusteriser les grandes tables.
• Éviter le SELECT * sur l’export brut.
• Toujours filtrer sur _TABLE_SUFFIX (ou la colonne de partition) pour ne scanner que la période utile.
• Matérialiser les agrégats lourds plutôt que de les recalculer à chaque ouverture du dashboard.
• Surveiller le volume scanné (la facturation BigQuery est au volume lu, pas au nombre de requêtes).

Au bout du pipeline : des events bruts transformés en décisions — avec l’historique complet, les croisements que l’interface GA4 ne permet pas, et des coûts qui restent négligeables pour la plupart des sites.