A measurement plan before a single tag

Sample entry (track P-B). Replaces with the real launch article from the Phase 1 content sprint (P-D).

Most tracking debt starts the same way: someone opens the tag manager before anyone has written down what a conversion actually is. This site went the other way — every event it measures existed in a table before a line of JavaScript did.

The event dictionary

The whole site is instrumented from one dictionary. Each row answers three questions: what happened, what context travels with it, and who consumes it downstream.

From dictionary to dataLayer

The dictionary compiles to a typed push helper, so an event that is not in the plan cannot ship:

type SiteEvent =
  | { event: 'page_view'; page_type: string; hub?: string }
  | { event: 'cta_click'; location: string; target: string };

export function track(payload: SiteEvent) {
  // v1: local only — nothing leaves the browser (see /colophon).
  console.debug('[instrumented]', payload);
}

Why this order matters

1. Naming arguments happen once, in a document — not forever, in production.
2. The plan is the QA checklist: every row is a testable assertion.
3. When a stakeholder asks “can we track X?”, the answer is a diff, not a dig.

Start with ten rows. You can always add an eleventh — deleting a shipped tag is the part that never happens.