Aller au contenu principal
Veille

GA4 et LLM : des KPIs qui répondent au « et alors ? »

FB

Fabien Bourgois

Expert Data & IA

4 novembre 20264 min de lecture
GA4 et LLM : des KPIs qui répondent au « et alors ? »

Vos rapports GA4 disent « quoi », jamais « et alors ? » Votre tableau de bord indique que les sessions ont baissé de 12 %. Il ne dit ni pourquoi, ni ce que vous devez faire lundi matin. Les agents LLM comblent ce vide, à condition de leur fournir de bonnes questions et des KPIs qu’ils peuvent exploiter. … Lire la suite

Vos rapports GA4 disent « quoi », jamais « et alors ? »

Votre tableau de bord indique que les sessions ont baissé de 12 %. Il ne dit ni pourquoi, ni ce que vous devez faire lundi matin. Les agents LLM comblent ce vide, à condition de leur fournir de bonnes questions et des KPIs qu’ils peuvent exploiter.

Pourquoi vos KPIs actuels ne sont pas prêts pour l’IA

Branchez un LLM sur des métriques d’activité (sessions, pages vues, taux de rebond) et il produira des commentaires d’activité. Ils seront bien écrits et ne serviront à rien.

Avinash Kaushik défend depuis longtemps une grille simple : acquisition, comportement, résultats (outcomes). La plupart des rapports s’arrêtent au deuxième terme. Un KPI prêt pour l’IA vit dans le troisième : revenu, leads qualifiés, marge, réabonnement. Il doit aussi passer le test du « so what » de Kaushik. Si ce chiffre bouge, quelle décision change ? Si vous ne savez pas répondre après trois « et alors ? » successifs, ce n’est pas un KPI. C’est de la décoration.

Je vous conseille d’écrire pour chaque KPI une fiche de trois lignes : la définition exacte avec le nom API de la métrique, le seuil d’alerte, et la décision associée. Cette fiche deviendra le contexte permanent de votre agent.

Comment interroger GA4 par API sans que le modèle invente ?

Les hallucinations viennent presque toujours d’un modèle qui devine des noms de dimensions. Il faut donc le laisser découvrir le schéma lui-même.

Google propose un serveur MCP officiel et open source, qui tourne en local et relie GA4 à un LLM via les API Admin et Data. Les serveurs communautaires ajoutent du confort. L’un d’eux convertit automatiquement la demande « conversions » en « keyEvents », ce qui évite des requêtes en échec quand le modèle parle l’ancien vocabulaire.

Côté accès, restez en lecture seule. Un compte de service avec le rôle Viewer suffit, et votre agent ne pourra donc rien casser dans la propriété.

Un mot sur la conformité. L’API Data renvoie des données agrégées, ce qui limite l’exposition. Ne poussez pas en revanche des exports au niveau utilisateur issus de BigQuery vers un modèle externe sans avoir vérifié votre base légale et relu les recommandations de la CNIL.

Un prompt qui force la rigueur

Voici celui que j’utilise comme point de départ pour expliquer la variation d’un KPI :

Rôle : analyste GA4 senior, accès en lecture seule.
Contexte : fiche KPI jointe, propriété 123456789.
Tâche : expliquer la variation de "leads qualifiés" entre S-1 et S-2.
Règles : appelle d'abord get_metadata, n'invente aucun nom de dimension.
Maximum 3 requêtes, segmentées par canal, appareil et page de destination.
Donne l'écart en valeur absolue et en pourcentage, puis la contribution de chaque segment.
Signale tout seuil de confidentialité, échantillonnage ou donnée manquante.
Sortie : une cause probable, une hypothèse alternative, une action, un niveau de confiance (faible, moyen, élevé).

Trois choses font son efficacité. Le plafond de requêtes évite les explorations sans fin. L’obligation de signaler les données manquantes force le modèle à admettre ses limites. Et le format de sortie vous donne une action, pas un paragraphe de commentaires.

Pourquoi demander un niveau de confiance ?

Parce qu’un chiffre sans incertitude est trompeur. Si l’agent répond « confiance faible » sur une baisse portée par 40 leads, vous savez que le bruit statistique pèse lourd. Vous n’ouvrez pas de chantier pour si peu.

L’agent Python léger et sa mémoire

Pas besoin d’un framework lourd. Une boucle d’appel d’outils fait l’affaire : le modèle choisit entre run_report et get_metadata, votre code exécute l’appel, le résultat revient dans le contexte. OpenAI et Anthropic supportent tous deux le tool calling nativement. LangChain peut aider si vous voulez orchestrer plusieurs étapes, mais ce n’est pas obligatoire. Comptez environ 150 lignes de Python pour un premier prototype.

La mémoire sémantique est ce qui change la nature de l’outil. Après chaque analyse, vous stockez dans une base vectorielle locale (Chroma ou FAISS suffisent) l’insight, la date, le KPI concerné et l’action décidée. Avant chaque nouvelle question, l’agent récupère les trois notes les plus proches et les injecte dans son contexte.

L’effet est concret. L’agent sait que la chute de mars venait d’un tag cassé après un déploiement. Il ne vous la resservira pas comme une tendance de fond. Importez aussi vos annotations GA4 dans cette mémoire, car elles contiennent souvent l’explication que personne ne relit.

Une règle à graver : les chiffres viennent toujours de l’API, jamais de la mémoire. La mémoire sert à interpréter, pas à citer des valeurs. Sinon, vous obtiendrez un agent qui raconte avec aplomb des chiffres vieux de trois mois.

Ce que vous changez dès cette semaine

Ne commencez pas par le code. Prenez le KPI que vous consultez le plus souvent et écrivez sa fiche de trois lignes. Soumettez-le ensuite au test du « so what », trois fois de suite. S’il échoue, remplacez-le par une métrique de résultat avant d’installer quoi que ce soit.

Une fois ce travail fait, la connexion de l’agent prendra une demi-journée. Et la question deviendra alors plus intéressante : quelles décisions êtes-vous prêt à lui laisser préparer sans vous ?

Catégories

Non classé