Web Analytics · Measurement Strategy
Measurement Strategy & Tracking Plan
One written definition per event, agreed before a developer has to invent one mid-sprint.
Tracking becomes inconsistent when implementation starts before the team agrees on what to measure. We begin with the business questions, then turn the agreed actions into an event taxonomy shared by marketing, product, and engineering. You end up with a written tracking plan that developers, GTM, and GA4 specialists can implement without reinterpreting the definitions.
Some of the 500+ brands we've worked with
See all references
How we run it
The draft becomes a plan once product, marketing, and engineering agree.
The questions determine which events belong in the plan and which do not. Four steps end in a document engineering can actually build from.
How we hold ourselves to it
- Begin with business questions — We identify the decisions the tracking must inform, then work backward to the events required to answer those questions.
- Apply one naming convention — We define and apply a shared convention so an event such as "purchase" has the same meaning wherever it appears.
- Specify identity and consent behavior — We document how users should be identified across sessions and devices, along with what each consent state permits.
- Define acceptance criteria for every event — Each event includes a written description of correct behavior, giving future testing an agreed standard.
Gather business questions
We interview stakeholders about the decisions they make and the user actions relevant to their part of the business. The stakeholder confirms the question matters to them.
Question list
Draft the event taxonomy
We translate the agreed business actions into proposed events, properties, and naming conventions. The analyst checks the draft against the naming convention.
Draft taxonomy
Resolve definitions with stakeholders
Marketing, product, and engineering review the draft together and settle conflicting interpretations. Stakeholders agree on one definition per event.
Reviewed taxonomy
Finalize the tracking plan
We document the approved taxonomy and add acceptance criteria for the team that will implement it. Engineering lead confirms the plan is buildable as written.
Tracking plan
Begin with the business question, not every available click.
Automation clusters the interview notes into candidate business questions, drafts event and property names, flags where teams gave conflicting definitions, and writes acceptance criteria from what was agreed. The agreements are the human work: which question matters, one meaning per event, and an engineering confirmation that the plan can actually be built.
What you get
A tracking plan should remain useful after today's implementation team changes
The plan records the event model, naming rules, identity choices, and consent behavior in one place.
Working document
Tracking plan
A developer-ready record of every event, its properties, meaning, and acceptance criteria.
Reference document
Naming convention
Rules for naming future events and properties so the taxonomy remains consistent as the implementation grows.
Reference document
Identity and consent notes
Documentation of how users are identified and what behavior each consent state permits.
We call it done when: an engineering lead confirms the plan is buildable as written, and each event carries acceptance criteria a tester can run.
Fit and readiness
Two teams may use "signup" for two different actions.
Ask two people on different teams what "signup" means. If the answers differ, this is where you start.
A good fit when
- You are building a new site, app, or feature and want tracking defined before development begins.
- Marketing and product use "signup" or "conversion" for different actions, so engineering cannot implement one stable event definition.
- You need documentation that remains useful after the person who built the current tracking leaves.
Better handled as other work when
- The business actions are agreed and you need the technical dataLayer built. That is Web dataLayer Implementation.
- You need to decide which metrics matter strategically rather than which events to collect. That is KPI & Goal Architecture.
If one of these is closer to your situation, start here instead: All Measurement Strategy & Analytics Governance tasks
We call it done when: marketing, product, and engineering have agreed on one definition per event, so no event name carries two meanings when a developer builds from the plan.
People who build your measurement system
Zeo designs measurement systems that connect a business decision to governed collection and reporting you can check. The people shown here work on the part of that system this page covers.
Yiğit Konur
Founder & Chief Strategy Officer
Zafer Yıldız
Web Analytics Manager
Abdullah Tanıdır
Performance Marketing Team Lead
Sevda Yurtvermez
Performance Marketing Team Lead
Deniz Çağın Demirci
Frontend Developer
Serap Yurtvermez
Performance Marketing Team Lead
İlker Emir
Senior Performance Marketing Executive
İpek Ezer
Performance Marketing Executive
Onur Durdağı
Performance Marketing Executive
Mirzamin Aghazada
UI/UX Designer
Metehan Urhan
New Business & Partnership Manager
Tools we use
Tools behind this work
Notionthe shared taxonomy document three teams argue against, instead of carrying three separate definitions in their heads
Google Tag Managerchecked while drafting, so a proposed event name isn't secretly a duplicate of one that already fires
Where this fits
Keep going
Same capability
Analytics Audit & Measurement Roadmap
A plan drafted from business questions assumes you already know which platform is wrong. If marketing and finance still cite different totals, the stack assessment comes first.
Same capability
KPI & Goal Architecture
An agreed event name still leaves open which number leadership is judged on. That decision, plus each metric's formula and owner, is settled in the KPI tree.
Elsewhere in analytics
Data Enrichment & Transformation
Transformation can normalize a campaign label three sources spell differently, but it cannot add a property this plan never asked anyone to collect.
Next step
Write the tracking plan before implementation begins
Before we start
Questions teams ask before booking
Do you build the actual tracking too?
Not in this task. This work produces the plan. Once approved, Web dataLayer Implementation covers the technical contract, while GA4 Event & Conversion Tracking covers GA4-side naming and key events.
What if teams disagree about what a metric means?
That's exactly what this task resolves. We surface the disagreement explicitly and get one agreed definition in writing that both teams sign off on.
How detailed does the plan get?
It is detailed enough to remove guesswork for developers. Every event has a name, its properties, and a written acceptance test for what "correct" looks like when it fires. The naming convention travels with it, so anything added later still fits the same pattern. What the plan does not do is replace code review.
Who do you need to talk to?
We need access to stakeholders who can speak to the business questions and a clear view of what you are building, such as a new site, app, or feature, so the plan reflects the real scope.