QR-master/qrmaster-growth-system/references/tracking-spec.md

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