Conversational Analytics BigQuery : un agent GA4 qui ne ment pas

Vous branchez Conversational Analytics sur votre export GA4, vous demandez “combien de sessions la semaine dernière”, et l’agent vous sort un chiffre. Il a l’air sûr de lui. Il est faux. Pas un peu faux : faux d’un facteur deux, parce qu’il a compté des lignes d’événements au lieu de sessions, et personne dans la pièce ne s’en rend compte. C’est exactement le piège que ce guide veut vous éviter.

Conversational Analytics est passé en disponibilité générale (GA) dans BigQuery début juillet 2026. Tout le monde publie le même tutoriel : “Agents, Create agent, posez une question.” Ce que personne ne dit, c’est que sur l’export brut de GA4, un agent naïf répond n’importe quoi, parce que le schéma est un champ de mines. Voici le protocole que j’utilise pour monter un agent de données GA4 qui donne des chiffres justes, le publier dans Data Studio pour un client, et savoir ce que ça coûtera vraiment après le 30 septembre 2026.

Conversational Analytics dans BigQuery : ce qui a changé, en trois dates

Trois choses se sont alignées cette année et rendent le sujet concret, pas théorique.

D’abord, Conversational Analytics est GA dans BigQuery depuis début juillet 2026. L’API Conversational Analytics est disponible en production pour BigQuery et Looker : on sort du stade démo, on peut livrer.

Ensuite, le rebranding de Looker Studio en Data Studio, annoncé le 10 avril 2026 et effectif le 16 avril, a fait de Data Studio le hub du Google Data Cloud. On y publie désormais les agents conversationnels BigQuery et les data apps Colab à côté des rapports classiques. C’est un nouveau chemin de distribution : votre client interroge ses données en langage naturel depuis un rapport, sans écrire une ligne de SQL.

Enfin, la gratuité s’arrête le 30 septembre 2026. Les Data Cloud Agents sont en essai gratuit jusqu’à cette date ; ensuite, la facturation démarre. Si vous testez maintenant, vous avez une fenêtre pour évaluer sans payer les tokens, à condition de savoir ce qui vous attend derrière. On y revient plus bas.

Pourquoi un agent branché sur l’export GA4 brut répond faux

Le coeur du problème n’est pas l’IA. C’est le schéma de l’export GA4 dans BigQuery, qui n’a rien d’une table analytique propre. Un agent qui traduit votre question en SQL directement sur events_* va se tromper pour quatre raisons précises.

1. event_params est un champ imbriqué et répété. Les paramètres d’événement vivent dans un RECORD de type REPEATED (event_params.key et event_params.value.string_value / int_value / etc.). Pour lire page_location ou ga_session_id, il faut un UNNEST avec un filtre sur la clé. Un agent qui ne connaît pas cette structure va soit ignorer le paramètre, soit compter les lignes après UNNEST (ce qui multiplie artificiellement vos totaux).

2. Il n’existe pas de table de session. GA4 n’exporte que des événements. La session n’est pas une ligne : c’est la combinaison user_pseudo_id plus le paramètre ga_session_id. Compter les sessions, c’est compter les couples distincts de ces deux valeurs. Un agent qui prend “sessions” au pied de la lettre et cherche une colonne sessions ne la trouvera pas, et improvisera.

3. Les sources de trafic vivent à quatre endroits. Selon la question, la source ou le medium peut venir de traffic_source (attribution first-touch au niveau utilisateur), des collected_traffic_source (au niveau événement), des paramètres de l’événement session_start, ou de session_traffic_source_last_click sur les exports récents. Ces quatre emplacements ne donnent pas le même résultat. Un agent qui pioche au hasard produira un tableau d’acquisition différent de celui de l’interface GA4, et le client le remarquera.

4. Les timestamps sont en microsecondes. event_timestamp est un entier en microsecondes depuis l’epoch, pas un TIMESTAMP. Toute question temporelle (“le matin”, “en juillet”, “par heure”) exige une conversion (TIMESTAMP_MICROS) et la gestion du fuseau. Sans instruction explicite, l’agent raisonne en UTC et décale vos journées.

Aucune de ces quatre difficultés n’est visible dans une démo sur un dataset propre. Toutes explosent sur un vrai export d’événements. C’est pour ça que la préparation compte plus que le prompt.

La vue aplatie à construire avant tout

La règle numéro un : l’agent ne voit jamais events_* en brut. Vous lui donnez une vue aplatie, une ligne par événement, avec les colonnes déjà extraites et nommées en clair. Vous déplacez la complexité du langage naturel vers le SQL, une fois, à un endroit que vous contrôlez.

Voici une vue de départ, à adapter à votre propriété :

CREATE OR REPLACE VIEW `projet.dataset.ga4_events_flat` AS
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS event_day,
  TIMESTAMP_MICROS(event_timestamp) AS event_ts,
  DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Europe/Paris') AS event_dt_paris,
  event_name,
  user_pseudo_id,
  (SELECT value.int_value FROM UNNEST(event_params)
     WHERE key = 'ga_session_id') AS ga_session_id,
  CONCAT(user_pseudo_id, '-', CAST(
    (SELECT value.int_value FROM UNNEST(event_params)
       WHERE key = 'ga_session_id') AS STRING)) AS session_id,
  (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'page_location') AS page_location,
  (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'source') AS event_source,
  (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'medium') AS event_medium,
  traffic_source.source AS user_first_source,
  traffic_source.medium AS user_first_medium,
  ecommerce.purchase_revenue AS purchase_revenue
FROM `projet.dataset.events_*`
WHERE _TABLE_SUFFIX >= FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY));

Trois décisions se lisent dans ce SQL. On construit un session_id explicite en concaténant user_pseudo_id et ga_session_id, pour que “compter les sessions” devienne COUNT(DISTINCT session_id). On convertit le timestamp et on matérialise une colonne au fuseau Europe/Paris, pour que les questions temporelles tombent juste. Et on fige une définition de source (ici la first-touch utilisateur et la source événement, clairement nommées), pour ne pas laisser l’agent choisir. Si vos volumes sont importants, remplacez la vue par une table matérialisée ou une vue avec partition sur event_day : vous verrez pourquoi dans la partie coût.

Pour la mécanique complète de l’export et des pièges de schéma, je renvoie au guide dédié : exploiter l’export GA4 dans BigQuery.

Créer l’agent : le contexte fait tout le travail

Dans BigQuery Studio, la création se fait via Agents, puis Create agent, en pointant l’agent sur votre vue aplatie et non sur le dataset brut. La partie qui change tout n’est pas le bouton : c’est le contexte métier que vous écrivez pour l’agent. C’est là que vous transformez un traducteur SQL générique en analyste qui connaît votre propriété.

Écrivez des instructions explicites, en langage clair, sur les définitions que l’agent doit appliquer : une session se compte avec COUNT(DISTINCT session_id) ; un “achat” est l’événement purchase et le revenu se lit dans purchase_revenue ; un “key event” (ancienne conversion) correspond à telle liste d’event_name ; le fuseau de référence est Europe/Paris et toute question temporelle utilise event_dt_paris ; la source par défaut est telle colonne. Donnez aussi des synonymes (“visite” égale session, “utilisateur” égale user_pseudo_id distinct) et des exemples de questions avec la requête attendue. Plus le contexte est précis, moins l’agent improvise.

Le protocole de vérification : savoir si l’agent ment

Personne ne publie de méthode pour vérifier un agent conversationnel. C’est pourtant le seul livrable qui compte avant de le mettre entre les mains d’un client. Le principe est simple : vous posez à l’agent une série de questions dont vous connaissez déjà la réponse, parce que vous avez la requête SQL de référence à côté, et vous mesurez l’écart.

Constituez une batterie de 8 à 10 questions de contrôle. Pour chacune, gardez la requête de référence et le chiffre attendu.

Lisez les écarts, pas seulement les valeurs. Un écart de quelques pour cent peut venir d’un arrondi ou d’un décalage de fuseau d’une heure : c’est corrigeable via le contexte. Un écart d’un facteur deux sur les sessions trahit un UNNEST mal géré ou un comptage de lignes : l’agent ne voit pas la bonne définition, retournez au contexte. Tant qu’une question de contrôle est fausse, l’agent n’est pas livrable. Ces requêtes de référence, vous les avez probablement déjà : réutilisez celles de l’article les 10 requêtes BigQuery indispensables.

Publier l’agent dans Data Studio pour le client

Une fois l’agent fiable, Data Studio devient le canal de livraison. Depuis le rebranding d’avril 2026, vous publiez l’agent conversationnel BigQuery directement dans un rapport, et le client pose ses questions en langage naturel sans jamais toucher à BigQuery.

Ce que ça permet : un accès self-service gouverné. Le client interroge la vue que vous avez préparée, avec les définitions que vous avez figées, dans un environnement que vous contrôlez. Ce que ça n’empêche pas : l’agent reste un moteur de langage. Il peut mal interpréter une question ambiguë, et il n’invente pas de gouvernance de données que vous n’avez pas mise en place. Cadrez les accès BigQuery en amont (l’agent hérite des permissions sur la vue), et prévenez le client que les réponses restent à recouper sur les indicateurs sensibles. C’est un assistant très rapide, pas une source de vérité auditée.

Ce que ça coûte vraiment

Voici le chiffre qui manque à tous les tutoriels. L’essai gratuit des Data Cloud Agents court jusqu’au 30 septembre 2026. Ensuite, la facturation IA démarre : 3 $ par million de tokens d’entrée et 20 $ par million de tokens de sortie. À cela s’ajoute, à chaque question, le coût de scan BigQuery de la requête générée par l’agent, facturé comme n’importe quelle requête à l’octet lu.

C’est ce second coût qui dérape en silence. Un agent lâché sur events_* sans partition rescanne des mois de données à chaque question, et la facture BigQuery grimpe bien plus vite que celle des tokens. Trois leviers le contiennent : partitionnez la vue sur event_day pour que le scan se limite à la plage demandée ; matérialisez la vue aplatie plutôt que de recalculer les UNNEST à chaque requête ; et bornez le périmètre de dates par défaut dans le contexte de l’agent. Bien réglé, l’agent devient prévisible côté facture. Mal réglé, c’est une passoire à budget.

Alors on prend quoi ?

Conversational Analytics dans BigQuery n’est pas le seul moyen d’interroger GA4 en langage naturel, et ce n’est pas toujours le bon. Voici comment je tranche.

En clair : Ask Advisor pour une question de couloir dans GA4 (voir Ask Advisor GA4) ; l’agent BigQuery publié dans Data Studio quand vous voulez donner un accès fiable et cadré à un client ; et Claude Code pour le data analyst ou le serveur MCP GA4 quand c’est vous qui creusez, sans contrainte de gouvernance.

Le fil rouge des trois : la qualité de la réponse ne dépend jamais de l’outil, mais de la donnée en dessous. Un agent brillant sur un export mal préparé reste un agent qui ment avec assurance. Construisez la vue aplatie, écrivez le contexte, passez le protocole de contrôle, et alors seulement livrez. Vous avez jusqu’au 30 septembre pour tout tester sans payer les tokens : c’est maintenant que ça se joue.