24 lines
1.4 KiB
Markdown
24 lines
1.4 KiB
Markdown
# Telementry
|
|
|
|
Telemetry should happen on the server as much as possible so it cannot be blocked by Pi-hole or browser tracking protections. Prefer server-recorded events and server-derived journey analytics over client-only tracking.
|
|
|
|
## Todos
|
|
|
|
- [x] Instrument `Header.svelte` (logo, nav, contact pill, Instagram)
|
|
- [x] Instrument `Footer.svelte` (logo, nav links, contact, social)
|
|
- [x] Instrument `Home-2.svelte` (hero buttons, service cards, about CTA)
|
|
- [x] Instrument `PackWalks.svelte` CTAs
|
|
- [x] Instrument `PricingCards.svelte` Book Now button
|
|
- [x] Add `top_journeys` (page-flow) query to backend
|
|
- [x] Add Top Journeys section to analytics dashboard
|
|
|
|
## Notes
|
|
|
|
- There are currently untracked CTAs across header nav, footer links, and page buttons.
|
|
- A journey section is needed to show page-to-page flows.
|
|
- Telemetry should use a first-party endpoint and server-owned anonymous identity.
|
|
- Avoid browser storage for visitor IDs. Prefer an `HttpOnly` cookie issued by the backend.
|
|
- The browser should only send coarse event labels like page, element, destination, or variant.
|
|
- IP, referrer, UA, geo lookup, and journey stitching should be derived on the server.
|
|
- Fully static pages can never make interaction telemetry literally unblockable from the browser. To go further than this, page delivery itself would need to move behind a server/reverse-proxy layer that records requests directly.
|