GA4 → BigQuery : le pipeline data, pas à pas

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

Quand en avez-vous vraiment besoin ?

Trois déclencheurs typiques :

• Vous butez sur les limites de rétention GA4 (2 ou 14 mois) et vous voulez garder votre historique.
• Vous devez croiser GA4 avec d’autres sources (CRM, coûts média, marges, stock).
• L’interface GA4 ne sait pas répondre à votre question (échantillonnage, dimensions custom complexes, funnels sur mesure).

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

1. Activer l’export

Dans GA4 → Admin → BigQuery Links. Vous choisissez un projet GCP, la fréquence (daily, et streaming si besoin), et les events à exporter. Dès le lendemain, vos 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, vous pouvez 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 vos 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.