Clean event tracking is the foundation of every dashboard and ad platform sync. This guide defines a taxonomy, client vs server collection, QA, and privacy practices for Build Me Web analytics.
Event taxonomy
Standardize names like lead_submitted, add_to_cart, and purchase. Use verbs and objects consistently. Document properties once — currency, value, item IDs — and reuse them everywhere.
Avoid synonyms (buy vs purchase). Version breaking changes deliberately; prefer additive properties over renaming events mid-quarter.
event: purchase
properties:
value: 129.00
currency: USD
order_id: ord_123
items: [{ sku, qty, price }]- List funnel stages from first visit to revenue.
- Name canonical events and required properties.
- Publish the taxonomy in your docs hub or Notion equivalent.
- Gate new events behind a light review so sprawl stays controlled.
Client vs server
Browser events power UX analysis and many marketing pixels. Server events catch purchases and leads that blockers miss. Deduplicate with a shared event ID when both fire for the same action.
Send server-side from trusted environments with secrets in the vault. Validate values against the order of record before advertisers see them.
Prefer server purchase events as the source of truth for revenue; keep client events for funnel diagnostics.
QA
Walk funnels on preview with debug mode on. Confirm property types, currencies, and that SPA route changes do not double-fire page views. Use a checklist per release that touches checkout or forms.
- Verify no PII in unexpected properties.
- Confirm consent state gating before tags load.
- Compare a test purchase’s value to analytics within minutes.
Privacy
Honor consent mode and regional rules. Minimize PII in event payloads — identify users in your CRM, not in every analytics hit. Hash or omit emails unless a specific integration requires them under policy.
- Taxonomy doc linked from engineering README
- Server purchase path verified
- Debug QA on preview before prod release
- Consent gating tested in EU and US profiles
Troubleshooting
Inflated page views: SPA double instrumentation — listen to one router event.
Missing purchases: ad blockers; rely on server events.
Broken funnels: event renamed without updating reports.
Prerequisites & preparation
Before changing production settings for event tracking, align the people who own content, DNS, analytics, and approvals. A fifteen-minute kickoff that names owners prevents multi-day Slack archaeology later. Capture decisions in the workspace notes so the next teammate inherits context instead of guesswork.
Gather credentials and access: workspace admin or editor role, DNS control when hostnames are involved, payment or API sandbox accounts when money paths are involved, and a shared checklist link. Confirm which environment you will rehearse in — preview first, production only after a green run.
Draft the taxonomy with marketing and engineering owners before writing code.
Detailed walkthrough
Work the happy path slowly the first time. Narrate what you expect to see after each click: a status badge, a DNS record, a webhook delivery, a Lighthouse metric. When reality diverges, stop and resolve the mismatch instead of clicking ahead — most outages begin as ignored yellow states.
- Publish canonical event names and required properties.
- Implement client events for UX and server events for revenue/leads.
- Deduplicate with shared event IDs where both fire.
- QA funnels on preview with debug mode and consent variants.
- Minimize PII; gate tags on consent where required.
Edge cases & failure modes
Plan for partial failure. Networks drop, registrars delay, providers rate-limit, and humans approve the wrong revision. Your runbook should say what “abort” looks like: leave preview up, roll back the release, or freeze campaigns until metrics recover.
- SPA double-firing page views on client routing.
- Ad blockers hiding client purchases — missing server path.
- Timezone mismatches when reconciling daily revenue.
QA checklist before you announce
- Happy path verified on mobile and desktop
- Failure path messaging reviewed
- Owners named for the first hour after launch
- Rollback or freeze path documented
Operating the change
After launch, watch the metrics that prove the change worked — not vanity charts. Pair quantitative signals with one qualitative check (support ticket themes, sales feedback). Schedule a follow-up within a week to remove temporary flags, raise DNS TTLs, or archive the experiment.
Light review for new events to prevent synonym sprawl.
Treat event tracking as a repeatable playbook. The second time your team runs it should be faster because the checklist and owners already exist.
Synonyms like buy vs purchase fracture funnels — ban them in review.
Server purchase events should be the budget source of truth; client events diagnose UX.
SPA router integration must be single-sourced to avoid inflated page views.
Document property types so currency and value do not arrive as strings one day and numbers the next.
Privacy is a design constraint: identify users in CRM, not in every analytics payload.
Release checklists for checkout should include a test purchase reconciliation within minutes.
Implementation checklist
Confirm canonical taxonomy without synonyms on preview before you promote. Name who approves the change, which environment is authoritative, and what “done” looks like in measurable terms.
Document server revenue events as source of truth where the team already looks — workspace notes or the engineering handbook — not only in a meeting memory.
Rehearse shared event IDs for dedupe against written acceptance checks. If you cannot name the verification event (order, DNS lookup, deploy health, or signed API call), you are not ready to announce.
Measure SPA page view single instrumentation with anonymized but realistic data, and keep logs, headers, or screenshots for at least one release cycle so regressions have a baseline.
Operating it with your team
Automate consent gating before tags load so the next teammate can repeat the path without tribal knowledge. Prefer vaulted secrets over chat paste, and archive temporary exceptions with an end date.
Review property type consistency when two tools disagree. Pick a source of truth in advance so incidents do not burn the rollback window debating dashboards.
Validate PII minimization in payloads before paid traffic or customer emails amplify mistakes. Capture request IDs or screenshots for support if anything looks off.
When you finish this guide, you should be able to explain the happy path, the abort path, and the metrics that prove success. If any of those are fuzzy, revisit the walkthrough with your teammates before you scale traffic, spend, or automation.