The measurement plan: a template developers and marketers read

Most tracking problems start before the first tag is built. A marketer asks for "conversion tracking", a developer adds a click listener to the button that looked right, and six months later nobody can say what a "lead" in GA4 actually counts. A measurement plan prevents this by writing down, in advance and in one place, what is measured, why, and exactly how. The trick is writing it so that both sides read it: marketers need the why, developers need the what.

What should a measurement plan contain?

Seven sections, in this order. The first three are for everyone; the last four are the build sheet.

1. Business objectives. Two to four sentences on what the site exists to do.
2. KPIs. The handful of numbers that show whether it does it, each with a definition and a target.
3. Key events and conversions. Which user actions count as success, and which of them feed ad platforms.
4. Event table. Every event with its trigger, parameters, destinations and owner.
5. Parameters and custom definitions. A dictionary of every parameter, its type and allowed values.
6. Consent and privacy. Which events and destinations need which consent, and what must never be sent.
7. QA and change log. How each event is tested, and a dated record of every change.

Keep it in one shared document or spreadsheet with a named owner. A plan spread over email threads and a slide deck is not a plan.

How do you go from goals to events?

Work top-down and do not skip levels. Each level answers a different question:

If an event does not support a KPI or a decision someone will make, leave it out. Plans fail more often from too many events than too few: each one has to be built, tested, consented, documented and monitored.

A useful rule for the KPI section: every KPI gets a definition precise enough to compute it twice and get the same answer. "Leads" is not a definition. "Successful submissions of the demo form, deduplicated by email per day, excluding internal traffic" is.

Also name the source of truth for each KPI. Revenue usually comes from the shop or the finance system, not from GA4, and qualified leads come from the CRM. GA4 and the ad platforms then explain and optimise against those numbers rather than compete with them. Writing this down early saves the monthly argument about which dashboard is right.

What does the event table look like?

This is the part developers build from. One row per event, with no free text where a value is expected.

The matching dataLayer push, written into the spec so the developer has nothing to guess:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "generate_lead",
  value: 150,
  currency: "EUR",
  form_id: "demo_request",
  lead_type: "demo"
});

generate_lead with value and currency follows GA4's recommended events; form_id and lead_type are custom parameters that need registering as custom dimensions to appear in reports. The full format for writing these, including how to hand them to developers, is in the dataLayer spec guide. For background on the dataLayer itself, see the glossary.

Tracking Whisper

Which GA4 limits should the plan respect?

Check the plan against these before development starts. They are the limits that most often force a late redesign.

Naming rules matter as much as limits. Event names are case sensitive, must start with a letter, and use only letters, numbers and underscores, so Generate_Lead and generate_lead are two different events. Parameter and user property names cannot start with an underscore, firebase_, ga_, google_ or gtag. Pick one convention (we recommend lowercase snake_case, as Google's own events use) and write it in the plan.

Data retention deserves a line of its own. A new GA4 property defaults to 2 months of retention for explorations. If the plan includes year-on-year analysis in explorations, the plan should say "set retention to 14 months" and someone should do it on day one, or plan for the BigQuery export.

Key events, conversions: which word means what?

GA4 now calls important actions key events, and reserves "conversion" for actions used to measure and optimise ad campaigns, in Google Ads and in GA4's advertising reports. The plan should use the same split, because it changes who cares:

• Key event: marked in GA4 Admin, under Data display, Events. Used for site analysis.
• Conversion: a conversion action in Google Ads (imported from GA4 or from the Google Ads tag) or a Meta standard event used for optimisation. Used for bidding.

Write down, for each key event, whether it is also a conversion and on which platforms, and which source is primary. This one column prevents most double counting later, a topic we cover in why GA4, Google Ads and Meta never agree.

Tracking Whisper

How do consent and privacy fit into the plan?

Every row in the event table needs a consent column, and the plan needs a short section on what is never collected. For EU sites:

• Consent signals. Map each destination to the consent mode types it depends on: analytics_storage for GA4, ad_storage, ad_user_data and ad_personalization for Google Ads, and the CMP category for non-Google tags such as Meta.
• Load order. The plan should state that consent defaults are set before any tag fires, which in GTM means the Consent Initialization - All Pages trigger.
• No personal data in parameters. Emails, phone numbers and names do not go into event parameters or URLs. If enhanced conversions are used, the plan says where hashed user data is collected and under which consent.

This section is also what you show a data protection officer, so write it in plain language.

How do you keep the plan and the implementation in sync?

A plan that does not match the live tracking is worse than none, because people trust it. Three habits keep it honest:

1. QA criteria per event. For each row, write how to test it: which page, which action, what should appear in Preview mode, in Tag Assistant and in GA4 DebugView. A developer who knows the test writes code that passes it.
2. A change log. Date, change, reason, who approved, and the GTM version number that shipped it. One line per change is enough.
3. A periodic check against reality. Once a quarter, compare the event table with what GA4 actually receives (Admin, Events) and with the GTM container. Events in GA4 that are not in the plan are either undocumented work or bugs.

Tracking Whisper

A copy-ready template

Paste this outline into a shared document and fill it in.

MEASUREMENT PLAN: <site or app>          Owner: <name>     Version: <n>, <date>

1. Objectives
   - <2-4 sentences>

2. KPIs
   | KPI | Definition | Source of truth | Target | Owner |

3. Key events and conversions
   | Event | Key event in GA4 | Conversion in (Ads/Meta) | Primary source | Value logic |

4. Event table
   | Event | Fires when | Pages | Parameters (name: type) | Destinations | Consent | Owner | QA test |

5. Parameter dictionary
   | Parameter | Type | Allowed values / format | Custom dimension (scope) | Example |

6. Consent and privacy
   - Consent defaults: <how and where>
   - Destination to consent type mapping
   - Never collected: <list>

7. QA and change log
   | Date | Change | Reason | Approved by | GTM version |

Key takeaways

• Write the plan top-down: objective, KPI, key event, supporting events, parameters.
• Give developers an event table with exact names, triggers, parameter types and a QA test for each row.
• Check names and volumes against GA4's limits, including 40-character names, 25 parameters per event and 30 key events.
• Record, per key event, whether it is a conversion, where, and which source is primary.
• Add a consent column to every event and a short "never collected" list.
• Keep a change log and compare the plan with live data every quarter.

Tracking Whisper can read an existing GTM container and GA4 property and list the events and parameters actually in use, which is a quick way to start the "check against reality" step. Our tracking setup page describes how it builds changes from a plan, with a person approving before anything is published.