PostureVision · every page, every funnel.
The complete map of how users find PostureVision and move through it — rendered as a single architecture canvas. Prospect landing is the gateway; Today is the daily-product hub; a fat conversion arc connects them. Inbound channels feed in from the left, in-app cross-flows weave between surfaces, and email-triggered links thread across the canvas. Read by edge color, not by reading order. Below the canvas: skinned registration variants, tracking layer, and open decisions. Every pill is clickable — opens the page in a new tab.
System architecture Inbound · primary funnel · in-app cross-flow · email-driven · 1 unified view
Toggles: + Live data shows real PostHog visitor counts on each pill (click a metric chip → detail drawer). + Tracking overlay reveals PostHog events + GHL/Stripe write annotations on edges. + Workflows (purple diamonds) shows GHL / Resend / FCM automations that fire from each surface — hover for owner + action.
Skinned registration variants Per-campaign and per-partner co-branded landings
The skin model
Each major campaign and named partnership gets its own skinned registration page — same underlying form, but voice/photo/copy adapted to the source. Drives stronger conversion (audience sees their trusted creator's framing) and clean attribution. Typically branches off one of the 4 base templates below.
Base templates · live
Partner-skinned · proposed
Tracking & attribution layer CMP codes · promo codes · attribution IDs · ownership
The tracking spine
Every page in the funnel needs a clean attribution chain — from the first click on a creator's link all the way through paid signup and beyond. Decisions on this layer drive how many skin variants we actually need. One promo code with many landing pages? Or fewer pages with promo codes per audience? Locked here once decided.
CMP codes · per tactic + skin
Every tactic-page combination gets a unique CMP-{TACTIC}-{SKIN}-{N} code, threaded through UTM and stored in contact.first_touch_cmp.
Naming convention proposal: CMP-{CHANNEL}-{PARTNER|CAMPAIGN}-{VARIANT}-{REV}. E.g. CMP-IG-RIB-T14-V2.
Owner: TBD — most likely the lead-seg session (since they own CRM identity) with marketing reviewing per-campaign assignments.
Dedicated promo codes
Stripe coupon codes for first-month-free or % off. Each campaign gets its own (e.g. RIB10, HUBERMAN20) so attribution at checkout is clean.
Decision needed: fewer landing pages with one shared promo each, OR many pages each with a unique promo? The skin-variant explosion above implies the latter — confirm with marketing.
Owner: Stripe admin (Brian) creates the codes; lead-seg session attaches to email + landing.
Attribution IDs we need
Already implemented: utm_source, utm_medium, utm_campaign, utm_content, utm_term.
Need to add: cmp (campaign code), aff_id (affiliate partner ID for rev-share), fbclid/gclid/ttclid for paid platforms, posthog_distinct_id for cross-domain identity.
Owner: Frontend captures + persists in localStorage; backend reads on signup; lead-seg writes to GHL.
Identity chain · anonymous → identified → conversion
1. Anonymous: PostHog assigns distinct_id; UTM + first-touch CMP captured to localStorage.
2. Identified at signup: posthog.identify(ghl_contact_id); alias the anon id; first-touch CMP becomes a custom field on GHL.
3. Conversion at paid: Stripe customer.metadata gets the GHL contact ID + first-touch CMP; promo code attribution applied.
Open team decisions Lock these to simplify the funnel
Questions that shape the page count
Each decision below influences how many pages the team actually has to build, maintain, and update. Lock these before we go wide on partner-skinned variants.
Easy to commit to 8-10 partner skins. Reality: each one needs creative review, UTM/CMP wiring, ongoing maintenance. Proposal: only build skins for partners whose audience is >100K AND who commit to dedicated promo with us. Below that threshold, route to a base template with their UTM in the URL — no separate page.
Option A — one Stripe promo per skinned landing (clean attribution, more codes to manage). Option B — fewer codes, manual UTM-based attribution post-checkout (simpler ops, fuzzier attribution). Recommend Option A for partner-skins (rev-share clarity), Option B for paid social retargeting where Meta/Google have their own attribution.
Need a single source of truth — likely a spreadsheet or Notion table — listing every CMP code, when it was issued, the campaign + skin variant + promo code it ties to, and current status (active/expired). Recommend lead-seg session owns the registry; marketing requests new codes; frontend ensures landing pages capture them.
If a user clicks a Rib Eye Rach link in May, signs up free, and converts to Premium in November, does Rib still earn attribution? Industry standard: 30-day cookie + 90-day persistence on identified users. For affiliate rev-share, this directly affects partner payouts.
The email flow appendix references /verify-email, /household/claim, /household/consent, /feedback/cancellation, /forgot-password, /reset-password — most of these are React routes that haven't been built. Need an audit pass: which emails are scheduled to send before each route is live?
Easy to over-engineer here. Proposal: only A/B test the 3 highest-leverage pages (prospect landing, pricing, register-trial-choice). Other pages stay single-version until we have data. Adds complexity without proportional learning otherwise.
Complete page index Every page · alphabetical · click to open
screenshots/{filename}.png; build-team-handoff-zip.ps1 can extend to a screenshot capture step (chromedp / Playwright). Loom screen-recordings of full flows can also be embedded later for living documentation.