Visitor ID Tracking Server

The problem

The client ran an online-course launch on a ClickFunnels funnel — opt-in pages, a nurture sequence, a webinar, and a sales page feeding several different checkout and form providers. Nothing tied a single visitor together across those steps.

A lead who opted in with one email and bought with another looked like two unrelated contacts, making basic questions impossible to answer: do webinar attendees convert better? Which traffic source actually drives revenue? This server assigns every visitor a persistent first-party ID and stitches their whole journey into one profile.

Identity resolution

A lightweight (~5KB) tracker sets a first-party cookie scoped to the funnel's domain — resistant to ad blockers and Safari's tracking prevention in a way client-side pixels are not. From there the server merges each visitor's activity into a single identity.

• Persistent visitor IDs assigned server-side and carried through rewritten checkout links, along with affiliate codes and UTMs, to every payment provider
• Automatic profile merging when the same person reappears under a new email — events, emails, and purchases are reassigned to the surviving ID, and merge chains resolve to the current identity
• Phone number as a fallback match key when emails do not line up
• Cross-domain propagation so the visitor ID survives the jump from the funnel to a separate first-party portal

Purchase & webhook integrations

Six payment and form providers post into the system, each with its own payload quirks, all funneling through one idempotent purchase pipeline keyed on a namespaced transaction ID.

• Thrivecart, Xendit, PayPal, JotForm, Google Forms, and a first-party portal — each with signature or token verification appropriate to the provider
• Hardened against messy real-world payloads: multipart form bodies, dashboard-created payments, and deeply nested fields
• Enriched purchase events forwarded through Stape server-side GTM to Meta CAPI, GA4, Google Ads, and TikTok

Reporting & live dashboard

• A 23-endpoint reporting API covering funnel conversion and drop-off, source attribution, webinar impact, time-to-convert, and per-visitor event timelines
• An analytics export layer producing derived CSV tables: cleaned events, visitor journeys, funnel progression, touchpoints, and conversions bucketed by the pricing phase active at purchase
• A live KPI dashboard built for launch night — time-based phase cutovers, per-metric overrides, and a public read-only view

Engineering

• Node.js and Express (ES modules) over PostgreSQL on Railway, with raw parameterized SQL and no ORM
• Nine sequential SQL migrations; API-key-guarded reporting endpoints and shared-secret-verified webhooks
• Covered by 15 Jest and Supertest suites and load-tested with k6