Nine forms, one pipeline — and attribution that survives an audit
Every lead form across our own sites writes to the same backend. It reports what actually happened instead of a fixed "success" message, and it tracks where a lead really came from without conflating the page it landed on with its traffic source.
The operational problem
Every lead form across LATYNEX's own web properties — quote requests, assessments, contact forms, AI-consultant handoffs, video-editing intake, and more — used to risk becoming its own disconnected silo, each with its own idea of what "a lead" is and no shared way to tell where it actually came from.
Why existing tools were insufficient
A lead pipeline that reports success regardless of what actually happened erodes trust the moment something goes wrong behind the scenes — and most bolted-together form handlers do exactly that. Separately, most attribution setups conflate the page a lead landed on with where the visitor actually came from, which produces a dashboard that looks informative but answers the wrong question.
What LATYNEX built
A shared backend behind every lead form: persistence-first, idempotent (so a double-click or retry doesn't create duplicate rows), with a status model that reflects what actually happened rather than a fixed "success" message. Layered on top: a first-touch/last-touch attribution system that reads referrer, UTM parameters, and paid-click IDs server-side, normalizes them into a real traffic-source label (Google Ads, ChatGPT, LinkedIn, Direct, Unknown — Unknown is shown, never hidden), and keeps a visitor/session identifier only when the visitor has actually consented to analytics.
How it works
Each lead is persisted before delivery is attempted. If storage fails but delivery still succeeds (or vice versa), the record is flagged for manual recovery with a reference ID and a separate operational alert — it never silently reports success. PII redaction in logs is enforced by an automated test suite, including a dedicated no-PII-in-logs check. The admin dashboard aggregates by traffic source, form page, and lead quality entirely with server-side SQL — never by shipping raw rows to the browser.
How we use it internally
We found a real bug in our own process using this exact system: on 2026-08-04, the dashboard's first version treated "not yet anonymized" as equivalent to "real lead," which briefly surfaced 6 self-labeled test submissions (literally named "AUDIT TEST — DELETE ME" in their own fields, left over from an earlier QA round) as real commercial Digital leads. We caught it, audited every affected record by hand, and rebuilt the classification logic around an explicit, human-driven `confirmed_real` / `confirmed_test` / `uncertain` / `unreviewed` state — absence of anonymization no longer means "real." That fix is live now.
What is verified
Unifies 9 lead types behind one pipeline, covered by 30+ automated tests, verified in production in August 2026 — including a real incident where storage temporarily became unavailable and the pipeline correctly reported the degraded state instead of a false success. The manual real/test/uncertain classification system is live, audit-logged, and was exercised on a genuine data-quality incident, not just a hypothetical.
What is intentionally not claimed
We do not claim this attribution system tells us "which marketing channel works best" yet — current lead volume through the confirmed-real classification is too small (currently a single digit) for that conclusion to mean anything, and the dashboard explicitly shows "insufficient data" rather than a misleading percentage below a minimum sample size. We also don't claim zero bugs — the incident above is disclosed, not hidden, because the fix is the actual proof point.
How this architecture can be adapted
Any business running more than one lead-capture surface (a website form, a chat widget, a landing page for a campaign) faces the same two problems: reconciling them into one pipeline, and knowing where a lead genuinely came from without guessing. The unify-first, classify-explicitly, never-fake-success pattern generalizes directly to CRM integration and lead-operations work for other companies.
What is verified
- ✓9 lead types unified behind one pipeline, 30+ automated tests, production-verified Aug 2026
- ✓Real incident (degraded storage) correctly surfaced instead of a false success message
- ✓Manual real/test/uncertain classification shipped and used to fix a genuine data-quality bug the same week
What is intentionally not claimed
- –No 'best marketing channel' conclusion yet — sample size is too small, and the dashboard says so explicitly
- –Not a zero-bug system — the 2026-08-04 classification incident is disclosed, not hidden