# Landing & Lead Capture (Main) **Portal:** Main (public) · **Routes:** `landing.funnel` (`/{slug}`), `landing.video` (`/{slug}/video`), `landing.slot` (`/{funnel}/{slot}`), `register`, `auth.magic` — the root `/` (`landing`) renders the **site home** (`Main\SiteController@home`), **not** a funnel ## What it does The public landing pages — the entry point for Facebook/Instagram ad traffic. Each [funnel/program](/docs/modules_handbook/manage/events/funnels/readMe.md) has its own landing at `/{slug}` (and each slot a single-CTA landing at `/{funnel}/{slot}` that registers the visitor for the **next upcoming session**); the root `/` is the **site home**, never a funnel. Visitors click a CTA button that opens a **modal registration form** (Name, Phone + country prefix, Email). On submit it: 1. Creates a **Non-Member** user account (random unknown password — sign-in is passwordless). 2. Records a **funnel registration** ([`lead_funnels`](/docs/modules_handbook/manage/leads/readMe.md)) for that person, always bucketed **source = Funnel** (2026-07 consolidation), with the ad attribution carried on the URL (utm_*, fbclid, `campaign_id`/`adset_id`/`ad_id`/`placement` — Meta URL dynamic parameters) — reusing the existing **[Lead](/docs/modules_handbook/manage/leads/readMe.md)** for a returning visitor, or creating one (auto-granted its free AI credits — see the [AI](/docs/modules_handbook/shared/ai/readMe.md) module). 3. Redirects to the shared **`/thank-you`** page (2026-07-25 — it replaced the in-place success modal): confirmed seat + confetti, the **session's date & time**, a **Join our VIP WhatsApp group** invite (the funnel's own `whatsapp_group_link` when it has one, else the shared `WHATSAPP_COMMUNITY_LINK` via `config('whatsapp.community_link')`), and a **"your bonus is on its way to `{phone}`"** panel with a **wrong-number correction** form and a contact-admin escape hatch. **Nothing is verified on this page** — the funnel's WhatsApp welcome carries the bonus *and* a `{{login_link}}` which both proves the phone and (when it is safe to) signs the person in. *History: that third card was a click-to-send **dual-OTP verify & sign in** step (shared `ContactVerification` against `auth/register/start` / `auth/register/verify`) until 2026-07-28 — it was replaced because the WhatsApp welcome already proves the number, so asking for two codes only bled conversions. The full dual-OTP flow still lives at `/register`.* Someone who never taps the welcome signs in from `/login` any time. Registration is **frictionless**: a returning person (matched **by email only** — see the security note below) **reuses** their account + lead and simply gets a **new funnel registration** + a fresh WhatsApp welcome — registering for another funnel, or the same one again, is never rejected. A sign-in credential only rides that welcome when **no email-holding account existed beforehand** (`RegisterLeadAction`'s `allowAutoLogin`) and it is going to that account's **own stored phone**, so reusing an account can never grant access to anyone else. A person is **one account + one lead, with many funnel registrations** (each with its own attribution — see the [Leads](/docs/modules_handbook/manage/leads/readMe.md) module). > **⚠️ SECURITY — register matches by EMAIL ONLY (never phone).** This is a public, unauthenticated endpoint that then hands out a **working sign-in credential** (today the welcome's `{{login_link}}`; until 2026-07-25 a mailed magic link), so the account is keyed on the email. It must **never** resolve or enrich an account via the **unverified typed phone**: doing so let an attacker type a *victim's* phone + their *own* email and be handed a link straight into the victim's account (account takeover). The system-wide tolerant phone-merge (see the [Leads › Identity resolution](/docs/modules_handbook/manage/leads/readMe.md) section) is deliberately NOT applied here — only on admin / background-ingestion paths. Do not re-add phone matching to `RegisterLeadAction::resolveAccount`. The lead then taps the WhatsApp welcome's link and lands signed-in in the user portal (or, when the account could be claimed by somebody else, proves its email at `/verify-email` first). ## How it works ### Per-funnel Vue landings (folder per funnel, resolved by slug) - Each funnel's landing is a **Vue component**, not a DB-driven template or an uploaded file. `LandingController@index($slug)` resolves the funnel by slug (404 if it isn't an active funnel) then delegates to a protected **`renderLanding()`** helper, which gathers up to **9** upcoming events for the funnel + the funnel's active **slots** (each with its nearest upcoming session, for the "jump to a class" links) + the URL tracking params (utm_*, fbclid, campaign/adset/ad ids, placement, landing_url) + the funnel uuid + **all active funnels** (`{name,slug,description}`, for the generic Default fallback's browse list), and renders the single Inertia page **`Pages/Landing.vue`**. - **`Pages/Landing.vue` is a thin wrapper**: it `import.meta.glob`s `./Landings/**/*.vue` and renders **`Landings/{slug}/Index.vue`** (one folder per funnel, resolved by the **exact slug**), falling back to **`Landings/Default.vue`** for any funnel without its own folder. So `bootcamp` → `Landings/bootcamp/Index.vue`, `sutera-klcc` → `Landings/sutera-klcc/Index.vue`. - **The root `/` is never a funnel** — it renders the **site home** (`SiteController@home`, a separate module). A funnel landing is only ever reached by its own slug (`/{slug}`), and a slot landing by `/{funnel}/{slot}`; there is no "one active funnel → redirect root to it" behaviour and no default funnel. - **`Landings/Default.vue` is the generic fallback design** for a specific funnel with no `Index.vue` of its own — a register CTA for that funnel plus the other active programs to browse (driven by the active-funnel list the controller passes). It is no longer served at the root as a directory. - **Scaffolding a funnel's design** (the design is source code → must be Vite-built): `php artisan funnel:landing {slug}` writes a starter `Landings/{slug}/Index.vue`. `FunnelsController@store` runs it **automatically in `local`** (`app()->isLocal()`) so creating a funnel locally drops a starter file (Vite HMR picks it up). In **production** it's skipped — a new funnel works via the `Landings/Default.vue` fallback until a dev commits a custom `Index.vue` + rebuilds. - Each design is hand-built markup (hero, sections, CTAs) that drops in the shared **``** behind its "Register" buttons (`v-model` to an `open` ref flipped from any CTA). ### Per-slot landings (`/{funnel}/{slot}` — one CTA, auto-picked session) - `LandingController@slot` resolves the active funnel + active slot by slug, then **auto-picks the single session** to register for: the **earliest** session of that slot whose derived **`live_status` is still Upcoming** (a Live or Past occurrence is skipped, bounded by `scheduled_date >= today` and eager-loading `webinar` so the status read is accurate). So a slot that repeats weekly always funnels the visitor into the **next** round; the visitor **never** picks a session and there is **no `?session=` deep-link**. - **Gating:** a slot with **no** upcoming session **404s** for the public URL — **unless** `?preview` is present (`$request->boolean('preview')`), which renders the design for an admin with the CTA disabled (so a dead/empty slot is never publicly indexed). The picked session's uuid is passed as **`tracking.event`**, which the modal posts to `/register` (the `event` branch → registers for exactly that session; see below). - **`Pages/SlotLanding.vue`** is the wrapper (mirrors `Landing.vue`): `import.meta.glob`s `./Landings/**/*.vue` and renders a bespoke **`Landings/{funnel}/{slot}/Index.vue`** if one exists, else the generic **`Landings/DefaultSlot.vue`**. It passes the single `session` + `preview` through. Creating a slot locally auto-scaffolds a starter design (`php artisan slot:landing`, mirroring `funnel:landing`). - **Empty-slug guard (open issue).** Both slugs default to `''` and an empty one is **logged + 404s**. `{funnel}/{slot}` is a catch-all that receives every two-segment URL on the site, and production was seen dispatching here with **zero route parameters bound** — an `ArgumentCountError` 500, ~9×/day on 2026-07-16, in a bot-scan-like pattern. Route definition, route cache and the controller signature were all verified correct, so the triggering URL is **still unidentified**; the guard logs `url` / `request_uri` / `user_agent` / `ip` under `landing.slot dispatched without route parameters` so the next occurrence identifies it. Grep that message before re-investigating. ### The post-registration VIDEO step (`/{slug}/video` — optional, per funnel) - A funnel whose offer is "register → watch the analysis → talk to us" can own a **third page after the thank-you**: `landing.video` → `LandingController@video`. It resolves the active funnel by slug (404 otherwise) and renders **`Pages/FunnelVideo.vue`**, which mirrors `Landing.vue`: it `import.meta.glob`s `./Landings/**/Video.vue` and renders **`Landings/{slug}/Video.vue`**. - **There is deliberately NO generic fallback design** (no `DefaultVideo.vue`). A video step only means anything if the funnel has a video; a shared "watch our video" page with no video is worse than not having the URL. Whether a design exists is a **build-time** fact the server cannot see, so `FunnelVideo.vue` `router.replace`s a design-less funnel back to `/{slug}` (replace, not visit — the back button must not walk into the dead URL again). - **Registered viewers only** (2026-08-12). The URL is guessable, and an unregistered direct visitor used to get the whole presentation while appearing in the VSL roster as an anonymous *未登记 · direct* row nobody can follow up with. The registration IS the price of the video, so `LandingController@video` bounces anyone without the session payload their own registration planted (`register()` → the `thank_you` key, **funnel-matched** — one funnel's registration never unlocks another funnel's video) back to `/{slug}` to pay it. Signed-in **admins pass** (they QA the page without polluting the lead list) — and `VideoProgressController` records **attributable viewers only** (2026-08-12, tightened same-day from an admin-only skip): a heartbeat whose `resolveLeadId()` comes back null — an admin QA'ing, a colleague not signed in as themself, or a real viewer whose **session expired mid-watch** (the tab left open past the session lifetime mints a fresh empty session + fresh visitor_key) — stores nothing and just echoes, so no anonymous *未登记* row can ever be minted and staff minutes never fold into the funnel's watched / unlocked cards. The player is unaffected (it records, it does not gate); a returning registrant whose session expired is now recognised by the `funnel_visitor` cookie below, and failing that simply re-registers — 30 seconds, and the identity gate merges them onto their own lead. Pinned by `test_the_video_page_is_for_registered_viewers_only`. - **THE 5-MINUTE WATCH GATE IS GONE (2026-08-12, product decision).** Booking is open from the first second, the player's scrubber is handed back to the viewer, and playback RESUMES where they stopped. Three consequences worth knowing before anyone "restores" the old behaviour: - **The bar is real, and it is the whole point.** A `` in the control bar, the played side painted gold via a `--played` custom property (`accent-color` cannot colour the two sides differently). Two things about it are load-bearing rather than styling: it commits on **`change`, not `input`**, so one drag is ONE seek instead of thirty; and a seek's ORIGIN cannot be read in either `seeking` or `seeked`, because the HTML seek algorithm fires a `timeupdate` first and the clock already holds the destination — so `prevPos` trails the position by one tick and is frozen while a seek is in flight. Get either wrong and the counters read zero (or thirty) while looking perfectly plausible. The resume seek is flagged and not counted: the player made it, not the viewer. - **Seeking is measured, not prevented.** The clamp that pinned playback to `furthest_seconds` is gone; instead every jump ≥1s is counted (`seek_forward_count` / `seek_back_count`) along with a per-rate `speed_changes` tally, so *did they study it or skim it* is answerable on the roster. Counters travel as **DELTAS since the last heartbeat** and are ADDED server-side — a client-sent total would let a refresh reset the tally or a replayed request inflate it. - **`last_position_seconds` is a NEW fact, not a rename of `furthest_seconds`.** With seeking, a viewer who jumps to minute 30 then drags back to 5 has a furthest of 30 and a position of 5; only the position can resume them. `resumeSeconds` on the video page reads the position, clamped short of the end so nobody resumes onto a finished video. ⚠️ It takes the **LATEST row, never `max()`** — the table is unique on (funnel, `visitor_key`), so one person holds a row per browser, and the deepest position across them is not where they last were (watch to minute 30 on the laptop, drag back to 5 on the phone, and `max()` sends the phone to 30). The client MAY OMIT the field, and the server then leaves the stored value alone — sending 0 for "I don't know yet" is how a tab closed before `loadedmetadata` erases the very resume point this exists for. - **`unlocked_at` survives with a new meaning, and is now DERIVED SERVER-SIDE** (`FunnelVideoView::ENGAGED_SECONDS`, stamped when `watched_seconds` first crosses 5 minutes). It used to be the gate, so the player owned the fact; it is now simply watch depth, which the server already holds — and a number the manage roster reports should not be one a browser can misstate. The roster's card is relabelled **看满 5 分钟 · Watched 5+ min**; the 已解锁 / 看完 row tags are gone. ⚠️ `completed_at` is a DIFFERENT fact (they reached the end) and feeds the funnels index's *finished* column — it was deliberately NOT removed with the gate. - **The heartbeat's validation lives in `Main\StoreVideoProgressRequest`** (GUIDELINES §8), not inline in the controller — and every rule in it is a CLAMP, because the endpoint is public and unauthenticated while what it writes is the admin roster's watch figures. `speed_delta`'s **keys** are allow-listed against `FunnelVideoView::SPEED_RATES` (the column is merged additively and never pruned, so one invented key lives in the row for good), and `last_position_seconds` is genuinely OPTIONAL so a client that cannot yet say where it is omits the key rather than sending 0. - **Remembering a device — `funnel_visitor`** (encrypted cookie, 30 days, `Concerns\ResolvesFunnelVisitor`). A 2-hour session cannot recognise someone returning tomorrow, so a returning registrant was being bounced back to the form and recorded as an anonymous viewer. ⚠️ **Its powers are deliberately tiny, and the reason is not obvious**: Laravel's cookie encryption stops FORGERY, but forgery is not the attack — the capture form resolves an account by EMAIL ALONE, so anyone who types `victim@example.com` can *ask the server* for a signed long-lived assertion that they are the victim. If that could rehydrate `thank_you`, the chain completes (updatePhone → welcome re-sent to the attacker's number → `{{login_link}}` → signed in). So the cookie may do exactly two things, both harmless to hand a stranger: **re-open the video page of a funnel that person actually registered for** (checked against `lead_funnels`, so one funnel's cookie never unlocks another's) and **attribute the watch heartbeat**. It must never prefill contact details, authorise an account write, or mint a login. Pinned by `test_a_remembered_device_resumes_the_video_and_records_interactions` and `test_the_video_page_is_for_registered_viewers_only`. - **A remembered visitor's CTA skips the form** (`startBooking()` in the cochrane landing; `knownVisitor` is a BOOLEAN prop and never carries contact details, for the disclosure reason above). It must not re-register: `lead_funnels` is unique per (lead, funnel) and holds FIRST-touch attribution, so a second submit adds nothing — while `Lead` / `CompleteRegistration` would fire again, and Meta's dedup window is only ~48h, so a return visit days later is counted as a SECOND conversion, inflating lead volume and deflating cost-per-lead. The decision is taken BEFORE the modal opens, because `LeadCaptureModal` fires a `ViewContent` the instant it becomes visible. - **The floating WhatsApp booking assistant** (2026-08-12, `Landings/cochrane/Partials/ChatBooking.vue`) — a chat-shaped second route to the same booking, in WhatsApp's own **dark-mode** palette (`#0B141A` / `#1F2C34` / `#005C4B` / `#25D366`: recognisably WhatsApp, yet part of this navy page rather than a white third-party widget pasted onto it, which is what a booking panel must never look like). Two states around the watch gate: - It opens ITSELF once, ~9s after playback starts — early enough to land while attention is high, late enough not to talk over the opening — and only while playing. There is no longer a *locked* state (the countdown ring, the live `mm:ss` and the FAB's countdown all went with the 5-minute gate on 2026-08-12): the panel opens straight into the conversation, because a booking channel that makes an interested viewer wait is just a slower way of losing them. - **The conversation** — the booking form asked as a chat: one question per turn with WhatsApp-style quick-reply buttons, each answer echoed back as an outgoing bubble, a typing beat between turns, identity CONFIRMED rather than re-asked (it is pre-filled from the registration), the optional note skippable, then a summary card and the hand-off button. - ⚠️ **It is a VIEW, never a second write path.** It receives the parent's `useForm` object and fills its fields (§14's fields-component pattern), then EMITS `submit` so the page's own `submit()` runs — the one that saves BEFORE pointing the claimed tab at `wa.me`. A chat bot with its own `window.open` would reintroduce exactly the bug that ordering exists to fix. It hides while the player is expanded (a panel floating over a full-viewport video is an obstruction), and the form modal remains as the alternative route. - **The booking form requires name + phone + EMAIL** (2026-08-12 — `StoreConsultationRequest`; the modal gained an Email input, pre-filled from the registration so the typical visitor never types it twice). The submit saves the enquiry to `consultation_requests` **before** the WhatsApp hand-off is attempted, so a blocked popup / an abandoned WhatsApp still leaves a complete, chaseable booking on the VSL Leads roster (the 没发 WhatsApp list). - It is **public and unauthenticated** — a lead is never signed in at this point in the funnel — but **`noindex`** (`Seo::noindex()`), because it is a step inside a flow rather than a page anyone should land on cold from search. - The controller passes a **`salesWaUrl`** prop: a `wa.me` deep link to `config('services.whatsapp.sales')` pre-filled with the funnel's name. This step's job is to book a human, and there is no in-app booking surface for it. - ⚠️ **`video` is a RESERVED slot slug.** The route is a two-segment literal declared *before* the `{funnel}/{slot}` catch-all, so it wins — a slot slugged `video` would resolve here and its own landing would be unreachable. `Manage\Events\Series\StoreRequest::RESERVED_SLUGS` rejects it at slot creation (and at edit, via `UpdateRequest`), which is the only place an admin ever sees the reason. Any future literal `/{slug}/…` route must be added to that list in the same commit. - Live consumer: **`cochrane`** (`Landings/cochrane/Video.vue` — the 40-minute Cochrane/Maluri project analysis, self-hosted at `/main/videos/zen-40mins.mp4` and set in the component's `VIDEO` block). It is a *different* file from the 1-minute teaser on the `/cochrane` landing (`cochrane-teaser.mp4`). - **Every `