PostHog on your landing pages
Most PostHog projects start at signup, which means the ad that brought the user in is a guess. LanderLab's webhook moves the start line back to the ad. Each lead is posted to PostHog's capture endpoint as an event, with the form's answers, the page, the UTMs and the visitor's IP as properties, and the person's email and name set on their profile.
It's for product-led teams that buy traffic: SaaS trials, apps with a waitlist, marketplaces recruiting supply. When the lead and the product usage share a person in PostHog, the funnel from ad to activation is one report, not a spreadsheet.
Landing page leads as PostHog events
Each submit becomes a "Lead submitted" event in PostHog with the form's fields and quiz answers as properties. PostHog's own properties are filled too: the page as $current_url and the visitor's IP as $ip, so location comes from the person, not from LanderLab's server.
PostHog's capture endpoints are public and write-only, and its project token is meant to be shared, so posting from a webhook needs no secret key at all.
Person properties from the form
Inside the event, $set writes the email and the name to the person's profile, and $set_once keeps the first landing page they converted on, even if they submit again later. If your app identifies users by the same email, the lead and everything the user does in the product belong to one person.
Funnels that start at the ad
With utm_source, utm_campaign and the A/B variant on the lead event, a PostHog funnel can begin at the landing page and end at the action that matters to you: first project created, first invoice sent, plan upgraded. Break it down by campaign and you see which ad sets bring users who activate, not just users who sign up.
That's the test LanderLab can't run on its own: its reports judge a variant on leads, and PostHog extends the judgment to what those leads do next.
Only the leads worth tracking, with Workflows
Not every submit belongs in product analytics. A Workflow can sit between the page and PostHog: a Filter that passes only completed quizzes, an If that keeps test leads out, then an HTTP Request node that posts the event. The Runs view shows each lead's path, so a send that failed is visible instead of silently missing from a funnel.
