The measurement plan: the document every analytics project needs (but nobody writes)

A measurement plan is probably the most boring document in analytics. It’s a spreadsheet. It has columns and rows. There’s nothing flashy about it. And it is, without question, the most important document in any analytics implementation.

I say this because I’ve seen what happens without one. A company installs GA4. They set up some events because a blog post said to. They add e-commerce tracking because their platform supports it. Six months later, someone asks, “What’s our conversion rate for users who viewed a product comparison page?” Nobody knows. The data doesn’t exist. The event was never planned, never implemented, and now they need to wait another quarter to start collecting it.

That’s the cost of skipping the measurement plan. You track what’s easy instead of what matters.

Why analytics implementations fail

Most analytics projects don’t fail because of technical problems. GA4 works. GTM works. BigQuery works. The tools are fine.

They fail because nobody asked the right questions before opening the tools. Someone jumps straight into GTM, starts creating tags, and builds tracking around what the tool can do rather than what the business needs to know. An analytics audit will almost always reveal this pattern.

I worked with a SaaS company that had 47 custom events in GA4. Forty-seven. When I asked which ones they actually used for decisions, the answer was four. The rest were “nice to have” or “someone requested this once.” Meanwhile, they were missing funnel data for their onboarding flow, which was the single most important thing their product team needed.

A measurement plan prevents this. It forces you to start with business questions and work backward to implementation. It’s the difference between “what can we track?” and “what do we need to know?”

The measurement plan structure

The plan follows a top-down hierarchy. Each level feeds into the next.

Level 1: Business objectives

What is the business trying to achieve? Not in analytics terms. In business terms.

Examples:

• Increase online revenue by 20% in Q3
• Reduce customer acquisition cost below $45
• Improve trial-to-paid conversion rate from 8% to 12%
• Grow organic traffic to product pages by 30%

You typically have 3-5 business objectives. More than that and you’re trying to measure everything, which means you’re measuring nothing well.

Get these from the CEO, CMO, or whoever sets business strategy. Not from the analytics team. Not from marketing. The objectives need to reflect actual business priorities, not what’s convenient to measure.

Level 2: KPIs

For each business objective, define 1-3 KPIs that indicate progress.

Business Objective	KPI
Increase online revenue by 20%	Revenue per session, Average order value, Purchase conversion rate
Reduce CAC below $45	Cost per acquisition by channel, Lead-to-customer rate
Improve trial-to-paid conversion	Trial activation rate, Feature adoption rate, Trial-to-paid conversion

KPIs should be specific and measurable. “User engagement” is not a KPI. “Average session duration on product pages” is.

Level 3: Metrics and dimensions

Break each KPI into the specific metrics you need and the dimensions you’ll slice them by.

For “Revenue per session”:

• Metrics: Total revenue, session count, revenue per session
• Dimensions: Device category, traffic source/medium, landing page, new vs. returning user, country

For “Trial activation rate”:

• Metrics: Trial signups, activated trials (completed setup), activation rate
• Dimensions: Signup source, plan type, company size, onboarding step completed

This is where the plan gets detailed. Each metric-dimension combination tells you what data point you need and how you’ll analyze it.

Level 4: Events and parameters

Now translate metrics into actual GA4 events and parameters.

Metric	GA4 Event	Parameters	Trigger
Purchase revenue	purchase	transaction_id, value, currency, items[]	Order confirmation page
Add to cart	add_to_cart	item_id, item_name, value, quantity	Add to cart button click
Trial signup	sign_up	method, plan_type	Registration completion
Trial activation	tutorial_complete	steps_completed, time_to_complete	Onboarding last step

For each event, specify: the event name, all parameters, the trigger condition, and which platform receives it (GA4, Meta, both, etc.). The naming conventions and parameter strategy I outline in my GA4 event tracking strategy guide apply directly here.

Level 5: Implementation notes

Technical details for the developer or implementer:

• Where does the data come from? (Data layer, DOM scraping, API)
• Are there edge cases? (Guest checkout, multiple currencies, single-page app navigation)
• What consent category does this fall under?
• What’s the expected event volume?

This level is often skipped, and it shouldn’t be. The person implementing the tracking needs to know where to find the data and what to watch out for. If you’re building a team to own this process, I cover what to look for in hiring your first analytics person.

Running a measurement planning workshop

I do this as a facilitated session. It takes 90 minutes to 2 hours, depending on the complexity of the business. Trying to do it asynchronously over email or Slack takes weeks and produces a worse result.

Who to invite

• Business stakeholder (1-2 people). Someone who sets or understands business objectives. Usually VP-level or founder. They attend for the first 30 minutes to confirm objectives and KPIs.
• Marketing/Product lead (1-2 people). They define what questions they need answered and what reports they’ll use.
• Analytics implementer (1 person). You or your analytics engineer. Present throughout to reality-check what’s feasible and estimate effort.
• Developer (optional, 1 person). Helpful if the data layer needs significant work or if the product is technically complex.

Keep it to 4-6 people max. Larger groups slow everything down.

The agenda

Minutes 0-20: Business objectives. Ask the business stakeholder: “What are the top 3-5 things the business needs to achieve this year?” Write them on a whiteboard or shared doc. Get agreement. Don’t overthink this part.

Minutes 20-40: KPIs. For each objective, ask: “How would you know if we’re making progress?” Define 1-3 measurable KPIs per objective. The marketing/product lead usually drives this part.

Minutes 40-70: Metrics, dimensions, events. This is the core of the workshop. Work through each KPI and ask: “What data do we need to calculate this? How do we want to slice it?” Map KPIs to specific events and parameters. The analytics implementer flags anything that’s technically complex or requires data layer changes.

Minutes 70-90: Prioritization. Not everything can be implemented at once. Classify each event as P1 (must have for launch), P2 (important, implement within 30 days), or P3 (nice to have, backlog). Be honest about what P1 actually means. If everything is P1, nothing is.

Minutes 80-90: Next steps. Assign owners. Set a timeline. Schedule a follow-up to review the completed plan.

What to avoid

Don’t let the conversation drift into tool selection or technical implementation during the workshop. “Should we use Looker or Tableau?” is a different meeting. “How do we push this event through the data layer?” is a different meeting. Stay focused on what to measure and why.

The template

Here’s the structure I use. It’s a single spreadsheet with tabs.

Tab 1: Objectives and KPIs

#	Business Objective	KPI	Target	Current	Owner
1	Increase online revenue 20%	Revenue per session	$3.50	$2.90	CMO
1	Increase online revenue 20%	Purchase conversion rate	3.2%	2.6%	CMO
2	Reduce CAC below $45	Blended CAC	$45	$62	Growth Lead

Tab 2: Event Specifications

Priority	Event Name	Parameters	Trigger Condition	Data Source	Platform	Consent Category	Owner	Status
P1	purchase	transaction_id, value, currency, tax, shipping, items[]	Order confirmation page load	Data layer (e-commerce)	GA4, Meta CAPI	Analytics + Marketing	Artem	Implemented
P1	begin_checkout	value, currency, items[], coupon	Checkout step 1 load	Data layer	GA4	Analytics	Artem	In progress
P2	view_item	item_id, item_name, price, category	Product page view	Data layer	GA4, Meta Pixel	Analytics + Marketing	Agency	Backlog

Tab 3: Data Layer Specification

Page/Action	Data Layer Object	Example Value	Developer Notes
Product page	ecommerce.items[0]	{item_id: “SKU123”, item_name: “Widget”, price: 29.99}	Push on DOM ready
Add to cart	ecommerce.items[], ecommerce.value	items array + calculated total	Push on AJAX success callback

Tab 4: Dimension Mapping

Dimension	GA4 Scope	Custom Definition Required	Values
traffic_source	Session	No (built-in)	google, facebook, email, direct…
customer_type	User	Yes (user property)	new, returning, vip
plan_type	Event	Yes (event parameter)	free, starter, pro, enterprise

You don’t need a fancy tool for this. Google Sheets works perfectly. I’ve tried Notion databases and Airtable. They’re fine too, but Sheets is the lowest common denominator that everyone can access and edit.

From plan to implementation

The measurement plan is the “what.” Now you need the “how.”

I hand off Tab 2 (Event Specifications) and Tab 3 (Data Layer Specification) to the development team. These tabs contain everything they need: event names, parameters, trigger conditions, and data layer structure with examples.

Before the developer starts, I review the handoff in a 30-minute call. We walk through:

1. Data layer structure. Confirm the developer understands the object format and where each push should happen.
2. Edge cases. What happens on guest checkout? What if a product has no category? What about multi-currency?
3. Testing. How will we verify the implementation? I set up a test plan in a separate doc with specific scenarios to validate.
4. Timeline. Which events are P1 and need to ship first?

After the data layer is live, I implement the GTM tags and triggers based on the plan. Then we QA everything against the test plan. Every event. Every parameter. Every trigger condition.

This process sounds slow. It’s not. A well-documented handoff saves more time than it costs. When I’ve skipped this step, I’ve spent twice as long going back and forth with developers about data format issues and missing parameters.

Keeping the plan alive

A measurement plan that gets written once and filed away is useless by month three. Business changes. New campaigns launch. Product features ship. The tracking needs to keep up.

Here’s how I keep measurement plans current:

Quarterly review. Every quarter, pull up the plan alongside the actual GA4 configuration. Are they in sync? Are there events in GA4 that aren’t in the plan? Events in the plan that were never implemented? Fix the gaps.

Change requests. When someone asks for new tracking, they fill out the relevant row in Tab 2 first. Event name, parameters, trigger, priority. Then we implement. This takes two minutes and prevents “can you just add a quick event?” from turning into undocumented tracking that nobody maintains.

Version history. Keep the spreadsheet’s version history clean. When you make significant changes, add a comment explaining why. Six months from now, you’ll want to know why you removed that event or changed those parameters.

Ownership transfer. When someone leaves the team, transfer ownership of their events in the plan. Unowned events are the first to break and the last to get fixed.

The measurement plan is the single source of truth for what your analytics tracks and why. Every GA4 event should trace back to a business objective through this document. Every business question should trace forward to a specific metric that’s being collected.

It’s a spreadsheet. It’s not exciting. And it’s the foundation that everything else in your analytics stack rests on. Build it first. Build it right. Keep it updated. Your data will be better for it.