38 lines
3.2 KiB
Markdown
38 lines
3.2 KiB
Markdown
|
# Marketing-site followups
|
||
|
|
|
||
|
|
Items that require edits to the **separate marketing-site repo** (port-nimara.com / portnimara.com), not the CRM. These can't ship from this codebase; they're parked here so they don't get lost when we drain the CRM audit doc.
|
||
|
|
|
||
|
|
Last updated: 2026-05-26.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Umami analytics — Phases 4a, 3, 5
|
||
|
|
|
||
|
|
**Source:** `docs/superpowers/audits/alpha-uat-master.md` — Umami follow-ups parked at end of the 2026-05-19 build session.
|
||
|
|
|
||
|
|
- **Phase 4a — Marketing-site instrumentation.** The CRM's Umami integration (Phase 4b — pixel + tracked-link events on outbound sales emails) is shipped. Phase 4a is the parallel work on the marketing site: add the Umami tracking script to every page, instrument the public berth inquiry form submission, instrument the "request more info" buttons, and confirm session-level attribution flows back to the same Umami workspace the CRM reads.
|
||
|
|
- **Phase 3 — Events tab.** Once 4a lands, the CRM's `/admin/website-analytics` page gets an Events tab that lists every named Umami event (inquiry-submitted, brochure-downloaded, berth-details-viewed, contact-clicked, …) with counts, top-source breakdown, and a 30-day trendline. Backend already proxies `/api/umami/events`; UI surface is the missing piece. Blocked on 4a sending real event data.
|
||
|
|
- **Phase 5 — Funnels.** Multi-step funnel widget on the dashboard ("landed on /berths → opened a berth → submitted inquiry → was created as a CRM interest → reached EOI stage"). Joins Umami sessionId with the CRM's `interests.umamiSessionId` snapshot we already write. Blocked on 4a so the first three steps have real data to consume.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Email-tracking end-to-end verification
|
||
|
|
|
||
|
|
**Source:** alpha-uat-master.md — Bucket 2 Umami follow-ups.
|
||
|
|
|
||
|
|
- **Verify the pixel + tracked-link with a real send** — flip `email_open_tracking_enabled = true` for port-nimara, send a real sales email to a personal inbox, open it in Mail.app + Gmail web, confirm: (a) a `document_send_opens` row appears, (b) `open_count` + `first_opened_at` increment on the parent row, (c) Umami records an `email-opened` event. Same drill for `/q/<slug>` short-links once the composer ships them. Cannot be automated — needs a real human inbox. This is a CRM-side manual UAT step but it depends on the marketing-site short-link redirector being live.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Public berth endpoint email recipient UI (parking note)
|
||
|
|
|
||
|
|
**Source:** memory — "Email ownership at cutover" (`project_email_ownership_at_cutover.md`).
|
||
|
|
|
||
|
|
When the marketing site cuts over and inquiry emails route through the CRM rather than the website's own SMTP, the public berth endpoint + the admin recipient UI need to be in place. Templates + settings keys exist on the CRM side; the marketing-site side needs the form submission target updated to hit `/api/public/website-inquiries` (or whichever the final endpoint is) instead of the legacy mailto. Coordinate as one rollout.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## How to triage when picking these up
|
||
|
|
|
||
|
|
Each item here has a CRM-side prerequisite or downstream consumer that's already in place. The work itself lives in the marketing-site repo. When you tackle one, link the marketing-site PR back into this file and tick the item off — keep this doc shrinking, not growing.
|