Data Layer & Measurement Plan

What's included

Discovery

• Business questions collected from marketing, sales, and product, since they rarely want the same numbers
• Current tracking inventory across GA4, GTM, PostHog, and ad platforms
• Gap analysis between the questions asked and what you can answer today
• Priority call on what to measure now and what to leave alone

The plan

• Event schema covering every event, when it fires, and why it exists
• Parameter and property definitions with types, allowed values, and required flags
• Naming conventions that hold up as the site grows
• User and session property definitions
• Identity model covering anonymous visitors, logged-in users, and account-level grouping
• Consent requirements per event
• Mapping from each event to the platforms it needs to reach

The specification

• dataLayer push examples written as code your developers can paste
• Matching trigger and variable structure in GTM
• Edge cases documented, including single page app route changes, async loads, and form errors
• QA checklist your team runs before each release
• Version control approach so the plan stays current

Deliverable

• Measurement plan in a format your team can maintain
• Developer-facing specification
• Implementation review once the first events ship

Why it matters

Most tracking problems are naming problems. Two developers ship the same action under three different event names, someone adds a parameter in a different case, and six months later nobody can build a funnel without a lookup table. The container works fine. The data underneath it is unusable.

Writing the plan first is boring and it's the cheapest insurance available. It also survives staff changes, which matters more than it sounds. When the person who built your tracking leaves, a documented schema is the difference between onboarding a new agency in a week and paying someone to reverse engineer a container for a month.