# QRMaster Tracking Spec

## Why this exists

QRMaster growth pages should not be judged by traffic alone.
Each page must support a measurable movement into signup or first product value.

## Core event set

Required marketing events:

- `landing_page_viewed`
- `cta_clicked`
- `signup_started`
- `signup_completed`
- `login_started`
- `login_completed`
- `qr_created_first`
- `tool_qr_generated` (optional, for free tools)

## Required properties

Use these whenever possible:

- `landing_page_slug`
- `page_type`
- `cluster`
- `use_case`
- `cta_label`
- `cta_location`
- `destination`
- `utm_source`
- `utm_medium`
- `utm_campaign`
- `utm_content`

## Page-type model

Recommended `page_type` values:

- `homepage`
- `commercial`
- `use_case_hub`
- `use_case`
- `blog_post`
- `learn_hub`
- `pillar`
- `tool`
- `auth`

## Funnel interpretation

The minimum useful path is:

`landing_page_viewed -> cta_clicked -> signup_started -> signup_completed -> qr_created_first`

Use this to answer:

- which pages bring qualified visitors
- which pages push users into signup
- which signups actually reach first QR creation

## Known repo findings from prior QRMaster review

- PostHog is the real custom-event system.
- GA is wired mainly for pageviews.
- Cookie consent is client-side via `localStorage['cookieConsent']`.
- CTA tracking was previously inconsistent.
- Prior analysis suggested likely duplicate pageviews from repeated PostHog/Facebook pixel mounts.

If you implement tracking later in the QRMaster repo, verify those points again before shipping changes.

## Decision rules

- do not create new events that do not support a decision
- do not track only clicks without tying them to page context
- do not judge SEO pages only by sessions; inspect signup and activation movement too