Connecter PostHog à n8n : alerter automatiquement sur une baisse de conversion

Un tableau de bord PostHog ne prévient personne quand il change : un taux de conversion qui décroche un vendredi soir peut passer inaperçu tout le week-end si personne ne pense à rouvrir le funnel. Ce guide montre comment interroger l'API Query (HogQL) de PostHog depuis n8n, comparer un taux de conversion à sa tendance récente, et déclencher une alerte Slack enrichie par un LLM dès qu'un décrochage réel apparaît — sur le même principe que la détection de déclin de trafic SEO déjà décrite sur ce blog, appliquée cette fois à un funnel produit plutôt qu'au trafic organique.

Deux façons de brancher PostHog sur n8n

n8n propose un node PostHog natif, mais il sert essentiellement à capturer des évènements vers PostHog depuis un autre outil — enregistrer une conversion Stripe, un signup Supabase, ou toute action métier qui n'a pas de tracking front-end natif. Ce n'est pas le bon outil pour lire des données agrégées.

Pour interroger un funnel ou exécuter une requête HogQL, il faut passer par un node HTTP Request qui appelle directement l'API Query de PostHog — le même contournement déjà nécessaire pour le prompt caching Anthropic ou les API Batch OpenAI/Anthropic : les fonctionnalités les plus fines d'une plateforme passent rarement par un node dédié tout fait.

Créer et sécuriser la clé API personnelle

L'authentification se fait via une clé API personnelle, créée dans les paramètres utilisateur PostHog, avec la permission « Query Read » — inutile d'accorder des droits d'écriture ou d'administration pour ce workflow. Stockez-la dans un credential n8n de type « Header Auth » (Authorization: Bearer <clé>) plutôt que dans le corps d'une requête en clair ; notre guide sur la sécurisation des credentials API détaille cette bonne pratique, valable pour n'importe quel service tiers appelé en HTTP Request. Vérifiez aussi le sous-domaine de votre instance (us.posthog.com, eu.posthog.com, ou l'URL de votre instance self-hosted) : une clé valide sur la mauvaise région renvoie une erreur 401 qui ressemble à tort à un problème de credential.

Construire la requête HogQL

L'endpoint POST /api/projects/:project_id/query/ accepte une requête HogQL, un dialecte SQL propre à PostHog qui interroge directement la table events. Pour suivre un funnel de checkout jour par jour :

{
  "query": {
    "kind": "HogQLQuery",
    "query": "SELECT toDate(timestamp) AS day, countIf(event = 'checkout_started') AS started, countIf(event = 'checkout_completed') AS completed FROM events WHERE timestamp >= now() - INTERVAL 8 DAY GROUP BY day ORDER BY day"
  }
}

Par défaut, l'API limite la réponse à 100 lignes — largement suffisant ici, mais pensez à ajouter un LIMIT explicite dès qu'une requête peut renvoyer davantage, pour éviter une pagination surprise sur un autre usage du même endpoint.

Construire le workflow n8n

Le pipeline reprend une structure déjà éprouvée sur ce blog pour le monitoring planifié :

1. Schedule Trigger — une exécution quotidienne, tôt le matin pour couvrir la journée complète de la veille ; voir le guide sur le node Schedule Trigger et les fuseaux horaires pour caler l'heure sur le fuseau de votre équipe plutôt que sur l'UTC par défaut de PostHog.
2. HTTP Request — l'appel HogQL ci-dessus, avec retry configuré ; consultez le guide sur les retries et timeouts du node HTTP Request en cas de latence sur des projets à fort volume d'évènements.
3. Node Code — calcul du taux de conversion par jour (completed / started), puis comparaison du dernier jour complet à la moyenne mobile des 7 jours précédents, exactement la logique déjà utilisée pour détecter une chute de trafic SEO plutôt qu'un simple mauvais chiffre isolé.
4. IF — déclenchement de l'alerte uniquement si l'écart dépasse un seuil relatif (par exemple −20 % par rapport à la moyenne mobile), pour filtrer le bruit naturel d'un funnel à faible volume.

Générer une alerte contextualisée avec un LLM

Une alerte brute (« conversion checkout : −27 % vs moyenne 7 jours ») laisse à l'équipe tout le travail d'interprétation. Un node IA en aval, branché sur Claude ou GPT selon la méthode décrite dans notre guide de connexion Claude/GPT à n8n, peut transformer les chiffres bruts en message exploitable et l'envoyer sur le modèle déjà documenté pour l'approbation humaine via Slack :

« Le taux de conversion checkout est passé de 4,1 % à 3,0 % hier (−27 % vs moyenne mobile 7 jours), sur un volume de trafic stable. La baisse touche uniquement les visiteurs mobiles. Vérifier en priorité : un changement récent sur le formulaire de paiement mobile ou une régression de performance sur cette étape. »

Ce niveau de synthèse transforme une alerte de dashboard en ticket actionnable, sans que personne n'ait besoin de rouvrir PostHog pour comprendre l'ampleur du problème.

L'alternative temps réel : les destinations webhook de PostHog

PostHog propose aussi des destinations webhook natives (dans Data pipelines), qui poussent chaque évènement correspondant à un filtre directement vers un endpoint HTTP — un Webhook Trigger n8n dans ce cas. C'est pertinent pour réagir en temps réel à un évènement individuel précis, par exemple chaque payment_failed avec un code d'erreur donné. Mais un évènement isolé ne dit rien d'une tendance : la requête HogQL planifiée reste le seul moyen de détecter qu'un taux a décroché sur une fenêtre de temps, ce qui est l'objet de ce guide. En pratique, les deux approches se combinent bien : webhook pour les incidents individuels critiques, HogQL planifié pour la surveillance de tendance.

Cas d'usage concrets

• E-commerce : funnel panier → paiement, alerte dès qu'une baisse touche une étape précise (pas seulement le taux global, en répétant la même requête par étape).
• SaaS : funnel signup → activation, avec un découpage par canal d'acquisition pour isoler une baisse liée à une seule campagne plutôt qu'à un problème produit général.
• Agence gérant plusieurs comptes clients : une variante du workflow ci-dessus, exécutée par client avec un project_id différent à chaque itération, alimente un rapport de synthèse hebdomadaire plutôt qu'une alerte immédiate — la même architecture, un seuil et une fréquence différents.

Pièges à éviter

• Comparer un jour à un autre jour isolé plutôt qu'à une moyenne mobile : la variance naturelle d'un funnel à volume modeste (week-ends, jours fériés) génère sinon des faux positifs en continu et finit par faire ignorer les vraies alertes.
• Confondre le fuseau horaire du projet PostHog et celui de l'équipe : toDate(timestamp) regroupe par défaut en UTC ; voir notre guide Luxon sur les dates et heures dans n8n pour convertir correctement avant de grouper par jour.
• Sur-accorder les permissions de la clé API : une clé « Query Read » suffit à ce workflow ; ne créez jamais de clé avec des droits d'écriture pour un simple monitoring.
• Oublier que le dernier jour est incomplet : comparer un jour en cours (partiellement écoulé) à une moyenne calculée sur des jours complets fausse systématiquement le résultat vers une fausse baisse ; excluez toujours le jour en cours de la fenêtre de comparaison.

Une pratique documentée, pas un raccourci artisanal

Automatiser cette surveillance plutôt que de compter sur une vérification manuelle régulière n'est pas qu'une question de confort : une étude de cas d'Ahmed Raza Amir et Syed Muhammad Atif, « Evaluating Workflow Automation Efficiency Using n8n: A Small-Scale Business Case Study » (2026), mesure sur un workflow de notification comparable un temps d'exécution divisé par plus de 150 par rapport au traitement manuel équivalent, avec un taux d'erreur observé nul contre 5 % en manuel — exactement le type de tâche répétitive et sensible au délai qu'est une vérification quotidienne de funnel. Brancher un LLM en aval d'un déclencheur de données, comme le fait l'étape de synthèse ci-dessus, correspond par ailleurs à un schéma déjà largement répandu dans l'écosystème n8n : Yutian Tang, Yuming Zhou et Huaming Chen, dans « Characterizing Large Language Model Agentic Workflows: A Study on N8n Ecosystem » (2026), montrent sur plus de 6 000 workflows publics que les LLM y sont très majoritairement intégrés dans une structure de contrôle plus large — logique conditionnelle, outils externes, services de communication — plutôt qu'utilisés seuls en simple chatbot, ce qui correspond exactement à l'architecture décrite ici.

Pour aller plus loin

Ce pipeline — appel API planifié, comparaison à une moyenne mobile, alerte IA contextualisée — reprend l'architecture déjà livrée dans le Pack Conformité & Audit (149 €), dont le workflow de rapport de synthèse IA s'adapte sans réécriture pour résumer une baisse de conversion plutôt qu'un audit de conformité. Si votre priorité immédiate est plutôt de fiabiliser le tri de vos communications entrantes avant de vous pencher sur le monitoring produit, le Pack Inbox IA (79 €) reste le point d'entrée le plus rapide, et le Bundle FlowKit Complet (269 € au lieu de 347 €) réunit les trois packs pour qui veut couvrir les deux besoins d'un coup.