> ## Documentation Index
> Fetch the complete documentation index at: https://docs.synscribe.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How to set up conversion attribution

> Wire attribution into the page — a user-journey trace on the lead form, a dual contact form, and pillar-level conversion tracking — so every conversion can be traced back to a pillar.

Set up conversion attribution by designing it into the page, not bolting it on: three primitives from the reference-repo template — a user-journey trace on the lead form, a dual contact form, and pillar-level conversion tracking — let every conversion trace back to the pillar that drove it. On a shared PostHog account, scope which events *you* own with Pi first (and record the boundary to `/memory/posthog.md`) before changing anything. Turn on the per-pillar funnels from the [PostHog dashboard setup](/platform/posthog-dashboard-setup). The goal is to answer one question per pillar — did it produce enquiries, sign-ups, or paid conversions ([Part 1 §1.10 Attribution](/theory/attribution)) — which you then validate in the [performance review](/platform/performance-review).

## The three primitives

All three come from the reference-repo template:

1. A user-journey trace on the lead form, which captures where the visitor came from (referrer or
   utm\_source, and the landing page) together with the form submission, so a lead carries its own
   provenance.
2. A dual contact form, offering both "contact" and "get free consultation," so you capture two
   intent levels rather than one.
3. Pillar-level conversion tracking, the per-pillar funnels from
   [2.6.1](/platform/posthog-dashboard-setup), so conversion is attributable to `/blog`, `/uses`,
   and `/features` separately, with AI-referred traffic tracked separately again.

## Step 1: Scope which events to own (don't touch events you didn't create)

On a PostHog account you already use, decide what you instrument before changing anything, and record
the ownership boundary so a later session doesn't clobber your existing setup:

```text theme={null}
Help me think through which events I should set up to get visibility into organic and AI
traffic — don't set anything up yet. Then let's do P1–P4 only. Do NOT override or change
existing ones. Save to memory what I own and what not to touch.
```

Pi proposes the event set, then, once you give the go-ahead, instruments only those and writes the
ownership boundary to `/memory/posthog.md`.

## Step 2: Wire the on-page primitives

The user-journey trace and the dual contact form live in the landing-page template, so a lead
arrives already tagged with its source and the pillar that produced it.

> ❓ \[needs Raymond: confirm exactly where the *user-journey trace* and the *dual contact form* are
> configured — are they shipped in the landing-page pillar template / reference repo automatically,
> or added per-site by hand? And is the trace captured as PostHog event properties, hidden form
> fields, or utm parameters?]

## Step 3: Turn on pillar-level conversion tracking

This is the per-pillar funnels from the dashboard setup. Provision them (or confirm they exist)
via [2.6.1 PostHog dashboard setup](/platform/posthog-dashboard-setup). With them in place, every
conversion is attributable to the pillar that drove it, and you can validate impact later in
[2.6.3 Performance review](/platform/performance-review).

> **Why bother:** attribution is what makes your performance review credible. It lets you back the
> review with proof rather than adjectives. Stand it up early so your first review has real
> conversion evidence, not just rankings.

> 🎥 **Video:** [Setting up attribution](https://www.loom.com/share/3e2d0ab899fc484fae95bdc400b687ee)

**Back to:** [2.6 Analytics & review](/platform/index#2-6-—-analytics-&-review) · **Depends on:** [2.6.1 PostHog dashboard setup](/platform/posthog-dashboard-setup) · **Next:** [2.6.3 Performance review](/platform/performance-review) · **Theory:** [1.10 Attribution](/theory/attribution)