ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Intégration du skill GA4 dans OpenClaw

Comment utiliser les skills GA4 communautaires de ClawHub pour extraire des métriques analytics dans OpenClaw — les deux principales options, ce que chacune extrait, et comment alimenter la sortie dans un reporting planifié.

Planté
ga4analyticsautomationai

Deux skills GA4 construits par la communauté sur ClawHub couvrent les besoins de reporting GA4 les plus courants pour les workflows planifiés. Les deux sont maintenus par la communauté et comportent les compromis associés aux skills communautaires non vérifiés.

Les deux options

jdrhyne/ga4

Jonathan Rhyne a construit ce skill “en environ 20 minutes”. Il couvre les endpoints principaux de l’API de données GA4 : pages vues, sessions, utilisateurs, sources de trafic, et événements de conversion. Les plages de dates et le filtrage basique sont supportés.

Pour l’installer :

Terminal window
openclaw skill add jdrhyne/ga4

Prérequis : Python 3, identifiants OAuth pour l’API de données GA4, et une variable d’environnement GA4_PROPERTY_ID. Si vous avez déjà travaillé avec l’API GA4, la configuration des identifiants est le même processus d’écran de consentement OAuth que vous avez déjà vu. Si ce n’est pas le cas, comptez 20 à 30 minutes de configuration dans la Google Cloud Console — création de compte de service, activation de l’API, configuration de l’écran de consentement OAuth, téléchargement des identifiants.

Ce skill couvre les bases correctement. Pour un reporting hebdomadaire simple qui nécessite des comptages de sessions, des taux de conversion, et des répartitions par source de trafic, il fait l’affaire.

adamkristopher/ga4-analytics

Une version plus complète qui regroupe GA4 avec Search Console et l’API d’indexation. Elle expose 30+ fonctions API, sauvegarde automatiquement les résultats JSON horodatés localement, et génère des résumés Markdown avec des tableaux, des tendances, et des recommandations.

Les résumés Markdown générés automatiquement incluent des tableaux pour les pages les plus visitées, des colonnes de variation en pourcentage pour les tendances semaine sur semaine, et une interprétation des évolutions notables. La sortie JSON fournit des données structurées pour le formatage en aval quand le Markdown ne correspond pas à un template spécifique. L’archive JSON locale crée un enregistrement des chiffres de chaque semaine pour des recherches historiques.

Ce qu’une tâche cron de reporting GA4 extrait

Avec l’un ou l’autre skill, l’extraction hebdomadaire couvre :

Tendances de sessions — total des sessions cette semaine vs. la semaine dernière avec une variation en pourcentage. C’est le chiffre principal qui intéresse la plupart des clients en premier.

Pages principales — les 10 pages avec le plus de trafic et leurs variations semaine sur semaine. Les changements directionnels (en hausse, en baisse, stables) sont généralement plus utiles que les chiffres absolus.

Répartition des sources de trafic — organique, payant, direct, et referral, avec des évolutions semaine sur semaine. Pour les clients qui gèrent des campagnes, la distinction payant vs. organique raconte souvent l’histoire la plus importante.

Taux de conversion — complétions d’objectifs, transactions e-commerce, ou quels que soient les événements de conversion que le client a configurés. L’API de données GA4 retourne les événements de conversion marqués dans la propriété ; votre message cron doit préciser lesquels faire remonter.

Ces quatre points de données couvrent le bilan hebdomadaire pour la plupart des clients sans nécessiter de configuration d’événements personnalisée ou de logique de requête complexe.

Le pattern de configuration

Une tâche cron GA4 fonctionnelle nécessite trois choses au-delà de l’installation du skill :

Identifiants OAuth dans l’environnement. L’API de données GA4 utilise OAuth, pas une simple clé API. Vous avez besoin de GOOGLE_APPLICATION_CREDENTIALS pointant vers un fichier JSON de compte de service (pour une utilisation côté serveur) ou d’un token OAuth valide pour un compte utilisateur. Les comptes de service sont plus propres pour les tâches planifiées — ils n’expirent pas, et vous pouvez les gérer par programme.

ID de propriété comme variable d’environnement. Chaque propriété GA4 a un ID numérique (pas le measurement ID — l’ID de propriété visible dans l’interface admin GA4 sous “Paramètres de la propriété”). Définissez GA4_PROPERTY_ID par client, ou passez-le dans le message cron si vous gérez plusieurs propriétés.

Une instruction de plage de dates claire. Le skill utilise des plages raisonnables par défaut, mais pour le reporting hebdomadaire vous voulez des dates explicites. Soit instruisez le message cron à utiliser “les 7 derniers jours se terminant hier”, soit configurez le skill pour calculer la semaine complète précédente (lundi-dimanche).

Pour une configuration multi-client où chaque client a une propriété GA4 différente, l’approche la plus propre est des tâches cron séparées par client, chacune avec sa propre configuration d’environnement. Voir Architecture de reporting agent multi-client pour savoir comment structurer l’isolation des identifiants et des tâches cron par client.

La mise en garde sur la qualité ClawHub

Les deux skills sont maintenus par la communauté, ce qui signifie qu’ils n’ont pas de contrat de support officiel et peuvent ne pas être mis à jour si l’API GA4 change. L’API de données GA4 a été relativement stable, mais le bilan de Google en matière de stabilité des API — en particulier pour les produits analytics — justifie un scepticisme raisonnable.

Avant d’installer l’un ou l’autre skill dans une configuration qui gère de vraies données clients, lisez le dépôt du skill pour l’historique récent des commits. Un skill qui n’a pas été touché depuis un an est plus susceptible de rencontrer un changement d’API sans avertissement. L’estimation de l’Autorité néerlandaise de protection des données qu’environ 20% des skills ClawHub contiennent des logiciels malveillants est une préoccupation distincte — voir Risques de sécurité OpenClaw — Ce qui est documenté pour le tableau complet.

La règle opérationnelle résumée : examinez le code source du skill avant l’installation, installez depuis une version épinglée si le registre le supporte, et exécutez les skills communautaires dans un environnement sandbox avant de leur donner accès aux identifiants clients de production.

GA4 vs. export BigQuery pour le reporting

Pour les clients avec l’export GA4 BigQuery activé, extraire les données directement depuis BigQuery est souvent plus fiable que l’API de données GA4. L’export BigQuery donne accès aux tables d’événements bruts, ce qui signifie :

  • Pas d’échantillonnage (l’API GA4 échantillonne les grandes requêtes)
  • Des chiffres exacts qui correspondent à ce que vous calculeriez à partir des données brutes
  • Accès aux paramètres personnalisés non exposés via l’API standard

Le compromis est le SQL : vous devez écrire les requêtes qui calculent vos KPIs à partir des événements bruts, ce qui nécessite de connaître le schéma d’événements GA4 et les patterns de dénormalisation. L’API de données fait cela automatiquement. Pour les clients où les chiffres doivent correspondre exactement aux rapports générés manuellement, BigQuery est le bon choix. Pour les résumés hebdomadaires rapides où des chiffres approximatifs suffisent, le skill GA4 est plus rapide à configurer.