PostHog sur vos landing pages
La plupart des projets PostHog commencent à l'inscription : la publicité qui a amené l'utilisateur reste une supposition. Le webhook de LanderLab recule la ligne de départ jusqu'à la publicité. Chaque lead est envoyé à l'endpoint capture de PostHog comme événement, avec en propriétés les réponses du formulaire, la page, les UTM et l'IP du visiteur, et l'e-mail et le nom de la personne renseignés sur son profil.
C'est pour les équipes product-led qui achètent du trafic : essais SaaS, apps avec liste d'attente, marketplaces qui recrutent côté offre. Quand le lead et l'usage du produit partagent une même personne dans PostHog, le funnel de la publicité à l'activation tient dans un seul rapport, pas dans un tableur.
Les leads de landing pages en événements PostHog
Chaque envoi devient un événement « Lead submitted » dans PostHog, avec les champs du formulaire et les réponses du quiz en propriétés. Les propriétés propres à PostHog sont aussi renseignées : la page en $current_url et l'IP du visiteur en $ip, pour que la localisation vienne de la personne et non du serveur de LanderLab.
Les endpoints capture de PostHog sont publics et en écriture seule, et son token de projet est fait pour être partagé : envoyer depuis un webhook ne demande aucune clé secrète.
Des propriétés de personne issues du formulaire
Dans l'événement, $set écrit l'e-mail et le nom sur le profil de la personne, et $set_once garde la première landing page sur laquelle elle a converti, même si elle renvoie un formulaire plus tard. Si votre app identifie les utilisateurs par le même e-mail, le lead et tout ce que l'utilisateur fait dans le produit appartiennent à une seule personne.
Des funnels qui partent de la publicité
Avec utm_source, utm_campaign et la variante A/B sur l'événement lead, un funnel PostHog peut commencer à la landing page et finir sur l'action qui compte pour vous : premier projet créé, première facture envoyée, passage à une offre supérieure. Découpez-le par campagne et vous voyez quels ad sets amènent des utilisateurs qui s'activent, pas seulement des utilisateurs qui s'inscrivent.
C'est le test que LanderLab ne peut pas faire seul : ses rapports jugent une variante sur les leads, et PostHog prolonge le jugement à ce que font ensuite ces leads.
Seulement les leads qui valent d'être suivis, avec les workflows
Tous les envois n'ont pas leur place dans l'analytics produit. Un workflow peut se placer entre la page et PostHog : un nœud Filtre qui ne laisse passer que les quiz terminés, un nœud Si qui écarte les leads de test, puis un nœud Requête HTTP qui envoie l'événement. La vue des exécutions montre le chemin de chaque lead : un envoi en échec se voit au lieu de manquer en silence dans un funnel.
