PostHog conversion tracking: a practical website setup

Conversion tracking becomes useful when the events describe customer progress. It becomes expensive noise when every button, field and scroll depth gets a name before anyone decides what question the data should answer.

This is a compact PostHog setup for a service or product marketing website. It gives the team a reliable journey from landing page to qualified enquiry, with enough context to find problems without rebuilding the entire implementation every month.

Start with one journey

Choose the journey that matters most. For a consultancy site it may be service page to contact start to qualified enquiry. For a software product it may be landing page to sign-up to first useful action. Write the steps in plain English before creating an event.

1. A relevant visitor arrives on a page.
2. They show intent by opening the contact route or booking flow.
3. They start the form.
4. They submit successfully.
5. The lead is accepted as a useful opportunity.

PostHog can measure the first four steps in the browser or application. The fifth normally needs CRM or server-side data. Without that final connection, the team can optimise form volume while lead quality gets worse.

A small event model

Name events after meaning

A name such as button clicked describes the interface. A name such as contact form started describes customer progress. The second survives a redesign and makes the dashboard readable to people who did not implement it. PostHog recommends an object-and-verb naming pattern, so use one pattern consistently across the project.

Keep property names stable and low-cardinality where possible. Use a controlled service value such as website-development instead of copying the visible button label. Do not send form messages, email addresses or other personal information into behavioural analytics.

Capture first-touch context once

Store the first landing path, a cleaned referrer and explicit UTM values for the session. Add them to the successful enquiry event and the contact notification. This keeps the source connected to the result even when the visitor reads several pages before making contact.

Avoid storing an entire query string. It can contain personal or accidental data. Record only the fields you expect, such as source, medium, campaign, content and term.

Build two views, not twenty dashboards

Journey funnel

Landing or service page, contact intent, form start and successful submission. Break it down by page group, device and source group. Use a sensible conversion window so a considered purchase is not treated like an instant checkout.

Quality table

Compare submitted enquiries with qualified leads by landing page and source. This view stops the team from celebrating a conversion increase that only created more unsuitable enquiries.

Release checklist

• Confirm every event fires once on the intended action.
• Check that a failed submission never fires the success event.
• Verify property names and values in a test environment.
• Check mobile, keyboard and embedded booking journeys.
• Exclude internal and staging traffic from reporting.
• Confirm no personal data enters event properties or recordings.
• Annotate the release so changes in the funnel have context.
• Retest the journey after form, CRM or consent changes.

What to investigate first

A funnel is a prompt for investigation, not an answer. If contact intent is healthy but form starts are weak, review the promise, friction and expectation on the contact page. If starts are healthy but submissions fail, inspect validation, mobile behaviour and delivery errors. If enquiries rise but qualified leads do not, revisit targeting and the handoff into sales.

Good instrumentation makes the next question clearer. It does not replace watching real behaviour, speaking to customers or using judgement about what is worth building.

Official references

• PostHog: capturing events and event properties
• PostHog: building and analysing funnels
• PostHog: session replay documentation