Web Analytics with Google Analytics 4Measurement strategy before tools · Lesson 2 of 20
Designing a tracking plan and naming conventions
Video lecture
Designing a tracking plan and naming conventions
The narrated lecture is in production
Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.
Chapters
Transcript of the narration, chapter by chapter.
0:00 Tracking plans and naming
Open almost any inherited analytics property and you'll find the same thing: Signup, sign underscore up, signup complete, and form submit two, all describing the same action. Nobody trusts the reports, and nobody knows which one is right. In this lecture you'll learn to write a tracking plan, the contract between marketers, analysts and developers. You'll learn to use recommended events first, to name things so they scale, to decide what not to track, and to lint the plan automatically before a developer ever sees it.
0:37 Why a plan
Why does a plan matter? Because analytics is a team sport, and without a written contract every player invents their own rules. Marketers ask for things vaguely. Developers implement what they think was meant. Analysts discover the gaps months later. A tracking plan says exactly what data will be collected, when, with which details, and who implements it. It's the difference between building a house from blueprints and building it from a conversation you half remember.
1:10 A plan row
Here's the anatomy of a plan row. The event name: a stable machine name like generate lead. The trigger: precisely when it fires, for example when the server confirms the form succeeded. The parameters: context sent with it, like form id and service. Allowed values for each parameter. Whether it's a key event. Which KPI it supports. The owner and status. And where it's sent. Treat changes like code changes: proposed, reviewed, implemented, tested, then marked live.
1:43 Recommended events first
Next, use recommended events first. G A four has predefined names and parameters for common actions: login, sign up, generate lead, search, view item, add to cart, begin checkout and purchase. Using them matters. Some reports, notably e-commerce, expect those exact names. Future features are more likely to support them. And new team members recognize them instantly. Think of recommended events like standard electrical sockets. You could wire your own custom plug, but then nothing you buy will fit.
2:17 Naming conventions
Now naming conventions. Agree once and write them at the top of the plan. Event names in snake case, verb then object, like download brochure. Parameter names as nouns, like file name or plan tier. Values lowercase from controlled lists. And avoid personal data, free text, dates or version numbers in names. The classic anti-pattern is encoding context into the name, like click pricing button homepage and click pricing button blog. Instead, one event, select plan, with a parameter for location. Fewer names, richer analysis.
2:54 Collection limits (check current docs)
Design within G A four's limits, and check the current limits page because they can change. As documented, event and parameter names can be up to forty characters, parameter values up to a hundred characters on standard properties, and an event can carry up to twenty-five parameters. Names are case-sensitive, so capital S sign up and lowercase sign up are different events. And some prefixes, like G A underscore, google underscore and firebase underscore, are reserved. A plan that respects limits never surprises you in production.
3:31 Example 1: a SaaS trial funnel
First example, a simple one. A project management software company selling in the UK, the UAE and Saudi Arabia plans its trial funnel. View pricing, custom, with billing period. Select plan, custom, with plan tier, billing period and location. Sign up, recommended, fired when the account is created and confirmed by the server, and marked as a key event. Tutorial complete, recommended. And purchase, recommended, with transaction id, value, currency and items, also a key event. Five rows, and the team can build a funnel from pricing to purchase and compare markets.
4:11 Example 2: an agency with 20 properties
Second example, a business scaling problem. A Manchester agency manages twenty G A four properties with twenty naming styles. It publishes one house convention, a template plan with recommended events pre-filled for e-commerce, lead generation and software, and runs a lint script during every client onboarding. For the first time, cross-client benchmarks are possible, like comparing lead rates across similar clients, and new analysts ramp up in days instead of weeks. Consistency turned twenty messy properties into one learnable system.
4:46 Version the plan
One more habit: version the plan like software. Every row has a status: proposed, approved, implemented, verified, live, or retired. Every change gets a date and a reason. When you retire an event, you don't delete the row, you mark it retired with the date, so anyone reading old reports knows why the event disappeared. And link the plan from your dashboards. When a stakeholder asks what a number means, the answer is one click away, not in someone's memory.
5:21 Watch me do it, part 1
Watch me lint a plan. I export the tracking plan as a CSV with columns for event name, parameters, trigger, key event and owner. The lesson's Python script checks each row. Is the event name snake case, starting with a letter, forty characters or fewer? Does it start with a reserved prefix? Are there more than twenty-five parameters? Is each parameter name valid? Does any parameter name hint at personal data, like email, phone, or regional identifiers such as C N I C or iqama numbers? And does every row have an owner?
6:01 Watch me do it, part 2
I run it. It prints three problems. An event called Form Submit with capitals and a space. A parameter called user email, flagged as possible personal data. And a row with no owner. I fix the name to generate lead, delete the email parameter entirely, because G A four must never receive personal data, and assign the owner. I rerun, and it prints plan looks clean. That took two minutes, and it prevented three problems that would have taken weeks to discover in reports.
6:38 What not to track
And what not to track? Every event costs implementation time, testing, documentation and attention in reports. For each proposed event, ask three questions. Which KPI or decision does it inform? Would we act differently if this number doubled or halved? Does enhanced measurement or an existing event already capture it? If the answers are weak, leave it out. You can always add it later, but it's very hard to get teams to stop looking at a number once it exists.
7:13 Common mistakes
Common mistakes. Firing on the button click rather than on success, so failed validations count as leads. Inconsistent casing. Sending personal data in parameters or URLs, which breaks Google's policies and often privacy law. And no owner, so the plan rots as the site changes. Each of these shows up months later as numbers nobody trusts.
7:37 Recap
Recap. A tracking plan is the contract between marketing, analytics and development. Use recommended events first and custom events only when nothing fits. Name with one convention: snake case, verb then object, nouns for parameters, controlled values. Use one event with parameters rather than many near-duplicates. Respect G A four's limits, fire on confirmed success, never send personal data, and lint the plan automatically.
8:05 Try this now
Try this now. Draft a tracking plan with at least six rows for a site you know, using recommended events wherever possible and marking which are key events. Export it as a CSV, run the lint script from the lesson, and fix every problem it prints. Then ask a developer whether they could implement it without asking you a question.
From measurement plan to tracking plan
A measurement plan says what matters. A tracking plan (sometimes called an event specification or solution design) says exactly what data will be collected, when, with which details, and who implements it. It is the contract between marketers, analysts and developers.
Without one, you get Signup, sign_up, signup_complete and form-submit-2 all describing the same action — and reports nobody trusts.
The anatomy of a tracking plan row
Each row describes one event:
| Field | Purpose | Example |
|---|---|---|
| Event name | Stable machine name | generate_lead |
| Trigger | Precisely when it fires | Server confirms form submission succeeded |
| Parameters | Context sent with the event | form_id, service, value, currency |
| Parameter values | Allowed values or format | service: seo, paid_social, web_design |
| Key event? | Counts as success? | Yes |
| KPI supported | Link back to the measurement plan | Form submission rate |
| Owner / status | Accountability | Dev team — live in production |
| Platforms | Where it is sent | GA4, ad platforms via tag manager |
Keep the plan in a shared spreadsheet or documentation tool with version history. Treat changes like code changes: proposed, reviewed, implemented, tested, then marked live.
Use recommended events first
GA4 has recommended events with predefined names and parameters for common actions — for example login, sign_up, generate_lead, search, view_item, add_to_cart, begin_checkout and purchase. Using them has real benefits:
- Some reports and features (notably e-commerce reports) expect those exact names and parameters.
- Future features are more likely to support them.
- New team members recognize them instantly.
Only create a custom event when no recommended event fits. Check Google's current recommended-events documentation when planning, as the list evolves.
Naming conventions that scale
Agree conventions once and write them at the top of the plan:
Event names: snake_case, verb_object, lowercase e.g. download_brochure
Parameter names: snake_case, noun e.g. file_name, plan_tier
Values: lowercase, no spaces, controlled lists e.g. plan_tier = pro
Avoid: PII (emails, phone numbers, names), free text, dates in names,
version numbers in names (signup_v2), page names in event namesA classic anti-pattern is encoding context into the event name: click_pricing_button_homepage, click_pricing_button_blog. Instead, use one event with parameters: select_plan with location: homepage. Fewer names, richer analysis, and you stay well within GA4's limits on distinct event names and registered custom dimensions.
Worked example: a SaaS free trial
A project-management SaaS selling in the UK, UAE and Saudi Arabia plans its trial funnel:
| Event | Trigger | Key parameters | Key event |
|---|---|---|---|
view_pricing (custom) | Pricing page loads | billing_period | No |
select_plan (custom) | Plan button clicked | plan_tier, billing_period, location | No |
sign_up (recommended) | Account created (server confirmed) | method | Yes |
tutorial_complete (recommended) | Onboarding finished | steps_completed | No |
purchase (recommended) | Payment captured | transaction_id, value, currency, items | Yes |
With this in place, the team can build a funnel from pricing to purchase, segment by plan and billing period, and compare markets — without adding new event names each time.
Deciding what not to track
Every event has a cost: implementation time, QA, documentation and cognitive load in reports. Ask for each proposed event:
- Which KPI or decision does it inform?
- Would we act differently if this number doubled or halved?
- Does enhanced measurement or an existing event already capture it?
If the answers are weak, leave it out. You can always add it later.
GA4 collection limits worth knowing
Design names within GA4's documented limits (check the current "collection and configuration limits" page, as they can change): event names up to 40 characters, parameter names up to 40 characters, parameter values up to 100 characters for standard properties, and up to 25 event parameters per event. Names are case-sensitive, must start with a letter, and some prefixes (such as ga_, google_, firebase_) are reserved.
Hands-on: lint your tracking plan automatically
Export the plan as CSV (event_name,parameters,trigger,key_event,owner) and run a quick check before developers see it:
import csv, re
NAME = re.compile(r"^[a-z][a-z0-9_]{0,39}$") # snake_case, <= 40 chars
RESERVED = ("ga_", "google_", "firebase_")
PII_HINTS = ("email", "phone", "name", "address", "dob", "passport", "cnic", "iqama")
problems = []
with open("tracking_plan.csv", newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
ev = row["event_name"].strip()
if not NAME.match(ev) or ev.startswith(RESERVED):
problems.append(f"bad event name: {ev}")
params = [p.strip() for p in row["parameters"].split(";") if p.strip()]
if len(params) > 25:
problems.append(f"{ev}: more than 25 parameters")
for p in params:
if not NAME.match(p):
problems.append(f"{ev}: bad parameter name {p}")
if any(h in p.lower() for h in PII_HINTS):
problems.append(f"{ev}: possible PII parameter {p}")
if not row["owner"].strip():
problems.append(f"{ev}: no owner")
print("\n".join(problems) or "plan looks clean")The PII list includes regional identifiers (Pakistan's CNIC, Saudi Arabia's iqama numbers) because they leak into forms and URLs more often than people expect.
Second worked example: an agency standardizing across clients
A Manchester agency manages twenty GA4 properties with twenty naming styles. It publishes one house convention (verb_object events, noun parameters, controlled values), a template plan with recommended events pre-filled for e-commerce, lead-gen and SaaS, and runs the lint script in every onboarding. Cross-client benchmarks become possible for the first time, and new analysts ramp up in days rather than weeks.
Common mistakes
- Firing on the button click rather than on success. A
generate_leadthat fires when "Submit" is clicked counts failed validations. Fire on confirmed success. - Inconsistent casing. GA4 event names are case-sensitive;
Sign_Upandsign_upare different events. - Sending personal data. Email addresses in parameters or URLs breach Google's policies and often privacy law.
- No owner. Plans without owners rot as the site changes.
Tracking-plan quality checklist
Key takeaways
- A tracking plan is the contract between marketing, analytics and development.
- Prefer GA4 recommended events; create custom events only when nothing fits.
- Use one event with parameters instead of many near-duplicate event names.
- Fire success events on confirmed success, never on the attempt.
Check your understanding
Quick questions to lock in the lesson. They don’t count towards your certificate.
Put it into practice
Draft a tracking plan with at least six rows for a site you know, using recommended events where possible, and mark which events are key events.
Enrol for free to save your progress
Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.