La paralysie GA4 et les événements zombies
GA4 est un entrepôt de données brutes. Il stocke tout. Il n’est pas conçu pour les décisions du quotidien. Vous l’ouvrez, vous faites face à des centaines de rapports, et vous ne savez toujours pas répondre à une question simple : combien me coûte un nouveau client ?
Le désordre vient souvent du passé. Les agences précédentes ont laissé une dette de tracking :
- Les événements zombies. Des événements que personne n’utilise, dont personne n’est responsable, et que personne n’ose supprimer.
- Les balises GTM redondantes. Deux ou trois balises se déclenchent pour la même action. Les conversions sont comptées deux fois, et vos chiffres paraissent meilleurs qu’ils ne le sont.
- Un thread principal saturé. Chaque balise en plus exécute du JavaScript dans le navigateur du visiteur. Votre score INP en souffre et le site paraît lent.
Ma réponse : la stratégie avant le code. Je commence par un audit sans pitié. Je supprime la dette. Ensuite, avec vous, je définis une courte liste de KPI business stricts. Je n’écris du nouveau code de tracking qu’après. Si un événement ne sert pas un KPI, il n’est pas livré.
Ingénierie native vs. scraping du DOM fragile
La plupart des configurations GTM suivent la page en la scrapant. Un marketeur choisit une classe CSS et déclenche une balise quand quelqu’un clique dessus. Ça marche le premier jour. Puis un développeur met à jour le design, la classe change, et le tracking casse. Personne ne reçoit d’erreur. Les chiffres baissent, c’est tout.
Le scraping compte aussi des faux positifs. Un visiteur clique sur « Envoyer », le formulaire renvoie une erreur de validation d’e-mail, et GTM enregistre quand même un lead. Vous payez pour acquérir des leads qui n’ont jamais existé.
La solution : des événements liés à de vrais résultats
Je suis développeur full stack, donc je corrige cela dans le code. J’envoie des événementsgtag.js natifs depuis l’application elle-même. Ils ne dépendent pas de l’interface. Une refonte ne peut pas les casser. Et ils se déclenchent uniquement quand le backend confirme le succès par une réponse HTTP.
Voici un événement de lead qui ne part qu’après le « oui » du serveur :
async function submitLeadForm(formElement) {
const formData = new FormData(formElement);
try {
const response = await fetch('/api/v1/leads', { method: 'POST', body: formData });
if (!response.ok) throw new Error('API Error');
const payload = await response.json();
if (typeof window.gtag === 'function') {
window.gtag('event', 'generate_lead', {
form_id: formElement.id,
lead_type: payload.lead_tier,
value: payload.estimated_value
});
}
} catch (error) {
console.error('Lead submission failed');
}
}Lisez-le de haut en bas. Les données du formulaire partent vers l’API. Si la réponse n’est pas OK, le code lève une erreur et aucun événement n’est envoyé. Si elle est OK, l’événement transporte de vraies valeurs venues du serveur : le niveau du lead et sa valeur estimée. Le testtypeof window.gtag protège la page quand un visiteur refuse le consentement ou qu’un bloqueur de publicité supprime le script. Pas de lead, pas d’événement. Des données propres en entrée, de bonnes décisions en sortie.
Contourner les quotas GA4 avec BigQuery
Connecter Looker Studio directement à GA4 paraît simple. C’est un piège. Deux limites vont vous pénaliser :
- Les quotas d’API. GA4 plafonne le nombre de requêtes qu’il accepte. Quand plusieurs personnes ouvrent le dashboard en même temps, il plante avec « Exhausted concurrent requests ». La réunion commence et les graphiques sont vides.
- La rétention des données. GA4 supprime les données d’événements détaillées au bout de 14 mois. Vous ne pouvez pas comparer cette année avec celle d’il y a deux ans.
La solution est une question d’architecture. J’exporte d’abord vos données GA4 brutes vers Google BigQuery. Ensuite, je connecte Looker Studio à des tables SQL propres, pas à l’API GA4. Le résultat : des dashboards qui se chargent instantanément, quel que soit le nombre de personnes qui les ouvrent, et un historique conservé pour toujours.
Le dashboard Looker Studio pour dirigeants
Un dirigeant n’a pas besoin de 50 camemberts. Trop de chiffres ralentissent les décisions. Je conçois chaque dashboard pour répondre à une question en moins d’une minute : l’entreprise est-elle en bonne santé, et où placer le prochain euro ?
J’applique une hiérarchie visuelle stricte, de haut en bas :
- Ligne du haut : les KPI macro. Chiffre d’affaires net et CAC global, chacun comparé à l’année précédente. Vous voyez la santé de l’entreprise d’un coup d’œil.
- Ligne du milieu : l’efficacité des canaux. Dépenses, ROAS et CAC par canal. Vous voyez quoi renforcer et quoi couper.
- Ligne du bas : les diagnostics opérationnels. Étapes du tunnel, pages de destination et contrôles de qualité des données. Votre équipe creuse ici quand un chiffre du haut bouge.
Un seul écran. Peu de chiffres. Chacun lié à une décision. Vous arrêtez d’interpréter les données et vous commencez à agir.