# LAS Survey Tracking — Review & Gap Analysis

*Reviewed 2026-07-09 · Sources: `KPI-Command-Center` repo (latest, commit 27b12a6) + live LAS quiz (`ethananchorworks/las` → `las.myanchorworks.com`)*

> **The question we were answering:** are we tracking **every question** a visitor answers on the LAS survey — even if they don't finish — plus completion? **Short answer: no, not today.** Everything fires once, at the very end. This doc says exactly what's happening, what's missing, and the plan to fix it.

---

## 1. What actually happens today (the mechanism)

The LAS quiz collects **name/contact info + all 16 answers + scores** and sends them to GHL in **one single webhook POST** — and that POST **only fires when the visitor reaches the results page** (i.e., finishes).

- Code path: everything happens inside one function, `buildResults()` in the quiz's `index.html`. It reads the contact fields (`f-fname`, `f-lname`, `f-email`, `f-phone`), builds the 16 answer fields, and fires the webhook — all at the end.
- Delivery: a hidden-iframe form POST to
  `https://services.leadconnectorhq.com/hooks/OwJn0vZV9wqqxHFqyC68/webhook-trigger/34421c83-74c5-4b7b-a9ea-a32a7760e71e`
- Payload sent (once): `firstName, lastName, email, phone, las_q01_trucks … las_q16_context, las_score, las_grade, las_stage, las_archetype, las_leads_score, las_sales_score, las_scaling_score, las_submitted_at, las_source="Local Authority Score"`.

### ⚠️ The lead leak
Because the contact info is read **at the end**, not when the first form is submitted, **a visitor who fills in their name/email/phone and then abandons during the questions sends us NOTHING** — we lose the lead *and* every answer they gave.

### What's missing
- ❌ No "quiz started" event
- ❌ No "question N answered" event — **nothing fires per question**
- ❌ No partial/abandonment capture (contact or answers)
- ✅ Only a de-facto "completed" signal (the single webhook = they finished)
- ❌ **Zero analytics on the quiz** — no GTM, no GA4, no Meta Pixel, no dataLayer (grepped the whole file — none present)

---

## 2. This is consistent with the KPI repo's own plan (it's designed, not built)

- `03-funnels/funnel-map.md` states plainly: **"zero tracking currently installed — clean slate."** Its "what to install" list already includes **"LAS per-question events (in the LAS repo)"** and "dataLayer step events" — planned, not implemented.
- `00-architecture/tracking-ids.md`: **GTM `GTM-PQZJXQW5`** and **GA4 `G-YBPMV5S1W4`** are *created but NOT installed*; **Meta Pixel is not created yet** (and is the time-sensitive blocker for banking retargeting audiences).
- No Supabase table models per-question/partial survey responses yet (migrations cover contacts/pipeline/departments/marketing).

So the whole chain that *would* capture per-question + partials — quiz instrumentation → GTM/GA4 → dashboard table — is a clean slate.

---

## 3. Naming / tags / forms / tracker-IDs review

**Tracker IDs** — `tracking-ids.md` is clean and well-maintained. Two reconciliation flags to close before real traffic:
- **GHL External Tracking ID `tk_d7ae9495801444d98e20c126b33df834`** is configured in GHL but **not deployed to the site**, and must be reconciled with GTM so page-views / form-fills don't **double-count**.
- **Meta business/asset ID `1006209442585145`** is unconfirmed; the **Pixel** must be created to start banking audiences (forward-only — visitors not tagged now are lost for retargeting).

**Forms** — 4 GHL form IDs registered: Market Report `xueC9A0MThX8O9JlmwEH`, Webinar `HKaO5PfqiO5b5DL5VINK`, Playbook `DlCc1XM8DAY8F3VEkdAv`, Do-Not-Sell `DAQO9ZtQzsJvMlrb3FoC`; calendar `strategy-session-round`. Playbook flagged "confirm keep or retire."

**Naming drift (doc vs. reality) — fix so dashboard labels match the data:**
- `funnel-map.md` says **"15-q survey"** → the live quiz is **16 questions** (`las_q01`…`las_q16`).
- Doc says the lead-quality layer is **"category 1–5, tier 1–5"** → the quiz + GHL actually use **`las_archetype`** (5 named archetypes), **`las_grade`**, and **`las_stage`**. Same concept, three vocabularies — unify on the real field names.

---

## 4. The naming convention to standardize on

GHL has **two naming namespaces that should NOT share a style:**
- **Tags** — the display-y labels I was cleaning up.
- **Field keys + event names** — `las_q01_trucks`, `las_score`, `las_archetype`, and GA4 events like `las_question_answered`. These are **`snake_case`**, which is the correct/standard style. **Never kebab-case these.**

**Recommendation (revises the earlier "kebab tags" idea):** standardize the **whole account on `snake_case`** — tags, field keys, and event names one style end-to-end (`las_stage_1`, `las_archetype_referral_contractor`, `booked_strategy_session`, `las_question_answered`). One system everywhere, and it already matches the tracking layer.

---

## 5. The fix plan (to capture every question + completion)

| # | Fix | Owner |
|---|-----|-------|
| 1 | **LAS quiz instrumentation** (the big one) — see `ETHAN-LAS-TRACKING-SPEC.md` | **Ethan** (LAS repo) |
| 2 | **Install GTM + GA4, create the Meta Pixel** on the site + `las.` subdomain | Tracking workstream (Chris + Ethan) |
| 3 | **GHL side:** add `las_completed` (bool) + `las_last_question_reached` (number) fields so partials are queryable; confirm webhook field mapping | Claude via **GHL MCP** (after Claude Code restart) |
| 4 | **Dashboard:** add Supabase `las_events` table (per-question + completion), ingested from GA4 | Ethan (dashboard) |

The heart of it is **#1 + #2** (front-end + tracking). #3 I can do through the new GoHighLevel API connection once Claude Code is restarted (the MCP tools aren't loaded in the current session).

---

*Companion doc: `ETHAN-LAS-TRACKING-SPEC.md` — the hand-off task list for the quiz instrumentation.*